KMLM List

["Alan Fitch" <alan.fitch@xxxxxxxxxx>]

> Subject: [Systemc-forum] SystemC timing doubt
> 
> 
> Hi,
> 
>    I have two functions which are sensitive to positive edge of clock.
> 
> void emif::update_foo()
> {
> 
>    if(foo_var > 0)
> 
>      foo_var--;
> 
> }
> 
>  
> 
> void emif::issue_foo()
> {
> 
>   if(foo_var  == 0)
> 
>     issue_command();
> 
>  
> 
> }
> 
> The implementation requirement is that update_foo should update in
> cycle X and issue_foo should see the change in cycle X+1. Since
> systemC has two phases of evaluation and update is it taken care of by
> itself normally or should I issue a dummy delay as follows.
> 
> void emif::update_foo()
> {
> 
>   wait(SC_ZERO_TIME);
> 
>    if(foo_var > 0)
> 
>      foo_var--;
> 
> }
> 
> this will delay the update of the foo till the end of cycle and so the
> issue_foo won't see the value until next cycle.
> 
> Cheers,
> 
> Sada
> 


This works fine as long as foo_var is declared as an sc_signal, e.g.

sc_signal<int> foo_var;

as a class member variable.

Then the assignment to foo_var will happen one delta after the rising
edge of clock, and will not be seen in update_foo() until the following
clock edge.

If foo_var is a plain C++ variable,

int foo_var;

then you have non-determinism as you don't know which process will run first.

You might want to have a look at the kernel behaviour descritption at 

http://www.doulos.com/knowhow/systemc/tutorial/primitive_channels/

regards

Alan

-- 
Alan Fitch
Consultant

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                          mail: alan.fitch@xxxxxxxxxx
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.