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
|
KMLM List