Skip Nav
Home » Forums » SystemC Forum

Icon - KMLM List KMLM List

View email archives for the history of this mailing list.

List Home All Archives Dates Threads Authors Subjects
systemc-forum - RE: [Systemc-forum] Combinatorial logic across block boundaries Message Thread: Previous | Next
  • To: Silbermintz Michal-R53028 <Michal.Silbermintz@xxxxxxxxxxxx>, "'Martin Janssen'" <Martin.Janssen@xxxxxxxxxxxx>
  • From: Kanstein Andreas-r39733 <A.Kanstein@xxxxxxxxxxxx>
  • Date: Wed, 22 May 2002 00:02:44 -0700
  • Cc: "'Bernard Deadman'" <bdeadman@xxxxxxxxxx>, "'kshitiz.jain@xxxxxx'" <kshitiz.jain@xxxxxx>, "'jbhasker@xxxxxxxxxxx'" <jbhasker@xxxxxxxxxxx>, "'systemc-forum@xxxxxxxxxxxxxxxxxxx'" <systemc-forum@xxxxxxxxxxxxxxxxxxx>
Send Email to systemc-forum@osci.kavi.com:
Send new message
Reply to this message
Hello Michal,

it seems that your question has been answered already. Most simulators do 
execute this scenario in a random order, and resolve dependencies by cyclic 
evaluation with delta delays, until all signals settle. I hope that SystemC is 
following the same approach for executing the second, truly combinational model 
that Bernard proposed - because that is the desired behavior. Did anybody try 
this?

The other approach which possibly is applied in modern simulation engines is to 
analyze the model and remove most of those iterations by static scheduling. 

There are synchronous high-level specification languages like Esterel where 
such a static schedule always exists and replaces the need for a simulator. For 
not too large circuits the model can even be translated to a single boolean 
equation (without any scheduling), as long as no causal loop (zero-delay loop) 
exists. This approach is guaranteed to deliver the fastest possible model 
execution. 

I assume that your question came up when comparing the execution semantics of a 
model in Esterel with the same model in SystemC. I don't know whether static 
scheduling or even model translation can be achieved for unrestricted SystemC, 
while maintaining compatibility with the standard, the existing simulation 
kernel. It might be possible for fully deterministic models, though.

Best regards,

Andreas

-----Original Message-----
From: Silbermintz Michal-R53028 [mailto:Michal.Silbermintz@xxxxxxxxxxxx]
Sent: Sunday, May 19, 2002 9:57 AM
To: 'Martin Janssen'
Cc: Bernard Deadman; kshitiz.jain@xxxxxx; jbhasker@xxxxxxxxxxx;
Silbermintz Michal-R53028; systemc-forum@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Systemc-forum] Combinatorial logic across block boundaries


Hi,

I'll try to describe a simple theoretical scenario which will hopefully clarify 
 the problem.
Suppose I have two blocks : A and B.

Block A:
        Input clock: clk1
        Inputs : a, b, x, y
        Logic: c = a + b, z = x + y
        Outputs: c, z

Block B:
        Input clock: clk1
        Inputs: c, z (from block A)
        Logic: result = c + z
        Outputs: result

There are no flip flops along the paths from a, b, x, y to result.
Therefore,  suppose that at a given cycle, the inputs: a, b, x, y are each 
equal to 1, then
I would want the output 'result' to be 4 during that same cycle.

The question is: is there a way, in SystemC, to make sure that equations are 
resolved
in the proper order?  Or does the scheduler randomly pick an order for 
executing the
processes regardless of equation dependencies?

Michal.


-----Original Message-----
From: Martin Janssen [mailto:Martin.Janssen@xxxxxxxxxxxx]
Sent: Thursday, May 16, 2002 12:31 PM
To: Martin Janssen
Cc: Bernard Deadman; kshitiz.jain@xxxxxx; jbhasker@xxxxxxxxxxx; Michal 
Silbermintz; systemc-forum@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Systemc-forum] Combinatorial logic across block boundaries


 > I cannot comment on the case described by Michal because I do not fully
 > understand his problem.
              ^^^^^^^^^^^

This should be "her problem". My apologies.

Martin
-oo-


Martin Janssen wrote:

> Bernard Deadman wrote:
> 
>>
>> Hi Kshitiz,
>>
>> At 09:32 PM 5/15/2002 +0530, kshitiz.jain@xxxxxx wrote:
>>
>>> But the order of evaluation of processes sensitive on the same signal is
>>> not fixed ( which is correct ).
>>>
>>> Some verilog and VHDL simulators do specify the order
>>> of execution of processes active on same signal. Although wrong, people
>>> have modelled using this particular behaviour of simulator ( they get
>>> correct behaviour also on silicon by using cells with different delays
>>> during synthesis or using buffers. )
>>
>>
>>
>> I agree with that, but the point I'm trying to make is Michal 
>> shouldn't have a care about the evaluation order in the application he 
>> describes if *NONE* of the outputs have been updated until *ALL* of 
>> the modules have been evaluated.  In other words the modules will be 
>> evaluating based on the state of the signals immediately PRIOR to the 
>> edge of the clock.
>>
>> Again, can any of the development team comment on the detailed 
>> evaluate/update semantics for multiple modules that are sensitive to 
>> the same signal?
> 
> 
> 
> Kshitiz described the semantics correctly. Processes that are sensitive 
> to the
> same signal will all be scheduled in the evaluate phase of the same delta
> cycle, after which the (changed) signals will be updated in the update 
> phase
> of that delta cycle. Due to these updates other processes may become 
> runnable,
> which will then be scheduled in the evaluate phase of the next delta cycle.
> Etc. The order in which processes are run within the evaluate phase of a 
> delta
> cycle is unspecified.
> 
> I cannot comment on the case described by Michal because I do not fully
> understand his problem.
> 
> Martin
> -oo-
> 
> 
>>
>> Regards
>>
>> Bernard
>>
>> ====================================================================
>> SDV Inc.   9111 Jollyville Rd, Suite 102,  Austin,   TX 78759   USA
>> Phone:   (512) 231-9806 xt 101   FAX:   (512) 231-9807   Mobile:   
>> (512) 431-5126
>> Email:    bdeadman@xxxxxxxxxx   Website:   www.sdvinc.com
>>
>>
>> _______________________________________________
>> Systemc-forum mailing list
>> Systemc-forum@xxxxxxxxxxxxxxxxxxx
>> https://server2.systemc.org/mailman/listinfo/systemc-forum
>>
>>
> 
> 
> 
> _______________________________________________
> Systemc-forum mailing list
> Systemc-forum@xxxxxxxxxxxxxxxxxxx
> https://server2.systemc.org/mailman/listinfo/systemc-forum
> 
> 


_______________________________________________
Systemc-forum mailing list
Systemc-forum@xxxxxxxxxxxxxxxxxxx
https://server2.systemc.org/mailman/listinfo/systemc-forum



By Date: Previous | Next Current Thread By Thread: Previous | Next

  Mail converted by the most-excellent MHonArc 2.6.10