Jump to content
bobo.drugo

need of delta cycles for correct values

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×