This is the mail archive of the sid@sources.redhat.com mailing list for the SID project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: best options for a wide bus?


Hi -

Welcome!


On Fri, Jan 05, 2001 at 03:12:26PM +1100, Paul Miach wrote:
: I am looking at getting SID to simulate a bus architecture with busses
: wider than 32 bits, ideally busses that are a little over 64 bits wide
: (256 bit would be nice, but I can hide this within components).  From
: looking at the code and the demos (should be demo?) I seem to have three
: options;
: 
: - Use multiple 32 bit busses to reach the required width

sid::bus includes 64-bit data read/write calls, so you could use a
smaller number of these.  By creating and using sidutil wrappers for
parallel buses, you could hide the use of multiple sid::bus objects &
connections.  This would allow us to defer upsizing the sid::bus API.

By the way, how important is it in your case to represent the >64 data bus
width at all (as opposed to representing it with a sequence of 64-bit
accesses across a single plain sid::bus)?


: - Use "memory" as a pseudo bus

I don't know what you mean by this.  Perhaps not exposing the wide 
data bus outside its component?


: - Extend the bus object/component to cope with more than 32 bits.

The problem with extending the sid::bus class is that it impacts
every component.  Using larger data types would imply adding support
for them into sidtypes.h, and we're already using the biggest
standard one (long long).  This is not the easiest implementation
avenue.

I forsee no significant performance differences between the first and
third approaches.

We have tried to enumerate the most common bus dimension combinations
within the low-level API, instead of relying on a generic
read/write-bytestring pair.  Maybe this is worth considering as an
extension, but then what about addresses?  Someone out there will
want huge physical address spaces too, but then again, adding back
sid::host_int_8 addresses could mitigate that matter for a long time.

While we ponder sid::bus changes, let me make a note that eventually,
I'd like to fit in representation of limited sorts of access latency
tracking into the sid::bus::status value.


- FChE

PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]