RE: [tlmwg] Revisit of the TLM2.0 phases rules

Hi Jacob,

I look at the BEGIN_REQ - END_REQ phase as the arbitration phase of the
protocol where the bus can stop an initiator until access is granted.
This is common to the majority of the protocols so this exclusion rule
seems natural. But your point makes sense and it is just a matter of
opinion what should be targeted with the BP.

Regards
Yossi

-----Original Message-----
From: Engblom, Jakob [mailto:Jakob.Engblom@windriver.com]
Sent: Tuesday, January 11, 2011 8:15 PM
To: Veller, Yossi; Aldis, James; Robert Guenzel
Cc: Marcelo Montoreano; Bart Vanthournout; john.aynsley@doulos.com;
P1666 Technical WG; tlmwg@lists.systemc.org
Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules

> 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.