best options for a wide bus?

best options for a wide bus?

[Paul Miach]

Hi,

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
- Use "memory" as a pseudo bus
- Extend the bus object/component to cope with more than 32 bits.

In terms of performance (simulator time) and ease of implementation,
what are the trade off in each of the above?

Cheers.

--
Paul Miach

Re: best options for a wide bus?

[Ben Elliston]

Hi Paul,

   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
   [...]
   - Use multiple 32 bit busses to reach the required width
   - Use "memory" as a pseudo bus
   - Extend the bus object/component to cope with more than 32 bits.

   In terms of performance (simulator time) and ease of implementation,
   what are the trade off in each of the above?

The first two options are easier to implement (since you can do it using
existing facilities).  Both of these options will require twice as many "bus
transactions" as a proper 64+ bit bus.  They also suffer from less obvious
behaviour and, in the case of option 1, will probably limit your component's
usefulness to anyone who doesn't have a similar interface to components they
may wish to connect to yours.

Implementing a proper 64-bit (or greater) bus requires careful
implementation on "smaller" hosts, but since it will be needed sooner or
later for many other components, I believe it's the right way to go.

If you'd like to take a crack at extending the bus class, I'd be glad to
offer any assistance.

Cheers, Ben

Re: best options for a wide bus?

[Frank Ch. Eigler]

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
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6VcqLVZbdDOm/ZT0RAvQQAKCFzkcWX1q5fbhZqMaSB9cotVfIbwCdH7uF
DeVa0IvQwLbUR3q0Zc67YyU=
=I1lP
-----END PGP SIGNATURE-----

Re: best options for a wide bus?

[Ben Elliston]

fche wrote:

   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 think it would be a mistake to defer support for wider buses.  If left
until later, the number of components that need to be upgraded will be much
larger.

Ben

re: best options for a wide bus?

[matthew green]

hi paul.

   
   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

when you say "256 bit" in reference to the bus architecture, do you mean
reading/writing that many bits as a single transaction, or truly as an
address?


i currently am having a similar problem where i need to handle 33 bit
addresses, but i am not worried about the size of the data accessed.  the
way i can to solve my problem is to extend the sidbusutil templace class
to also parameterise the address.  that should have the effect of not
affecting any other port, as it should only instantiate a host_int_4
version anyway, not a host_int_8 version, i believe.


.mrg.