need of delta cycles for correct values

[bobo.drugo]

Hi everybody,

I have a question regarding wait(SC_ZERO_TIME) statements.

I am working on a virtual platform for embedded systems with

several ISSs, interconnections and memory modules.

The memory thread has to be triggered on the positive edge of the

request signal and keep on serving subsequent requests if the

signal is kept high by the initiator after the first request.

The code below shows the memory module implementation.

-----------------------------------------------------------------------------

void memory::working()

{

while (true)

{

wait(SC_ZERO_TIME);

wait(SC_ZERO_TIME);

if(!request.read())

wait(request.posedge_event());

data = IO_data.read();

/* ... */

}

}

-----------------------------------------------------------------------------

My problem is that without the 2 wait(SC_ZERO_TIME) statements,

a quick fix made some time ago, the data read is wrong (not current cycle).

Since I checked that every master is filling first the data field then

raising the request signal, I don't understand the need of two delta

cycles to avoid reading the old value.

Any idea/suggestion?

Ciao,

Daniele

[Philipp A Hartmann]

Without seeing any details, you most probably need the delta cycles to allow the request line to drop to zero again. You need at least one wait statement on each control path in your process loop, to yield back to the simulation kernel (SystemC uses a cooperative scheduling approach). Without seeing the master code (and the interconnect models, etcpp.), it's quite impossible to say why you need two delta cycles, though.

A minor question:

The memory thread has to be triggered on the positive edge of the

request signal and keep on serving subsequent requests if the

signal is kept high by the initiator after the first request.

How do you tell, if the signal "is kept high", when you only wait for two delta cycles between checking the request line? Your ISS runs without consuming any simulation time? You may want to rethink your synchronisation mechanism.

Greetings from Oldenburg,

Philipp

[bobo.drugo]

Hi Philipp,

thanks for your quick reply.

You need at least one wait statement on each control path in your process loop, to yield back to the simulation kernel (SystemC uses a cooperative scheduling approach).

I have a wait statement on each control path, it was not reported in the code snippet above.

How do you tell, if the signal "is kept high", when you only wait for two delta cycles between checking the request line? Your ISS runs without consuming any simulation time? You may want to rethink your synchronisation mechanism.

My ISS consumes simulation time, the pipeline model is stepped every clock cycle. When I say that the signal can be "kept high" I mean that the ISS can issue two or more consectuive memory accesses without setting the request signal to '0' in between (similar to a burst access). This is why I have this:

if(!request.read())

wait(request.posedge_event());

Let me put the question this way. Below a simple example of ISS-memory interaction:

--------------------------------------------------------------

void ISS::working() {

while(true) {

IO_data.write(_data);

request.write(true);

wait();

request.write(false);

...

}

}

void memory::working() {

while (true) {

wait(request.posedge_event());

data = IO_data.read();

...

}

}

--------------------------------------------------------------

Am I sure that the data read by the memory is _data written by the ISS?

Thanks,

Daniele

[Philipp A Hartmann]

Am I sure that the data read by the memory is _data written by the ISS?

Usually: yes. At least if you delay the request and data signals within your interconnect models by the same amount of delta cycles (e.g. by forwarding values via explicit processes instead of just port/signal bindings).

/Philipp