> 1. Recommendation 16.2.6.b combines the request stage and the data
> stage
> of the write. A target can't get an outstanding request in order to be
> able to prepare for the actual data (e.g. reading the appropriate block
> from a memory in order to change it with incoming data and write it
> back
> afterwards). This is a shortcoming for modeling timing.
>
> 2. Recommendation 16.2.6.b in combination with rule 16.2.6.e prevent a
> read request to pass while a write data is executing. Thus, even for an
> in-order protocol with shared rd/wr channel, a target can't get an
> outstanding request in order to be able to prepare the data. This the
> timing to be pessimistic (for many transactions during simulation).
One thing that strikes me here: why care separately for reads and writes? It would make more sense to allow any operation to bypass any other - read/write just happens to be a common one, but on multichannel buses like found in the old SunFire clusters, you could easily have reads racing each other... so just allow any interleaving of operations if you want to set up new rules.
/jakob
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 11 10:15:54 2011
This archive was generated by hypermail 2.1.8 : Tue Jan 11 2011 - 10:15:56 PST