From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Frank Ch. Eigler" To: Paul Miach Cc: sid@sources.redhat.com Subject: Re: best options for a wide bus? Date: Fri, 05 Jan 2001 05:22:00 -0000 Message-id: <20010105082219.B29055@redhat.com> References: <3A5549AA.6D7DFF4D@edion.com> X-SW-Source: 2001-q1/msg00005.html 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-----