Subject: Re: scheduling semantics for Verilog-AMS (issue 25)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Sep 18 2002 - 18:14:42 PDT
> From alec@fintronic.com Wed Sep 18 16:24:20 2002
>
> Hi Kevin,
>
> I think that we understand each other's statements with two
> exceptions.
>
> 1. Delta
>
> >> However, please note that if event A occurs in the n-th delta, it does
> >> not mean that event B that occurs in the (n+1)-th delta is dependent
> >> upon event A, nor that in the real circuit event B should occur after
> >> event A.
> >
> ......................
> >
> >I.e. events A and B are definitely ordered in time.
>
> Suppose event A is in fact event An which is in the n-th delta because
> of event A(n-1), end so on and B is in fact Bn similarly produced.
>
> Therefore, event A(n) is an event which is delayed with n "small
> delays A" from the beginning of the time point To (to take your view that
> deltas are small delays, view which I do not share) and event B(n+1)
> is an event which is delayed with n+1 "small delays B" from the
> beginning of the same time point To.
>
> In reality the delays "small delay A" and "small delay B" are not
> equal although both are represented by one delta in this modeling
> style and therefore it is possible that event B will occur before
> event A in the real circuit.
>
>
> Therefore A and B are not ordered in time.
I'm afraid that in practice there is an order that behavioral code
will depend on. It's akin to "logic depth", you can consider each
delta cycle as processing a layer of logic. If you collapse the
layers you introduce more potential race conditions. You shouldn't
communicate a depth-n result to another thread which has not reached
depth-n (and has more to do) - bad things happen (users bug you about
inconsistent results).
> In general I take the position that it is wrong to view deltas as
> small delays. Delta is an event driven simulation concept which should
> not be used for modeling as it can lead to wrong conclusions.
I agree entirely it's a bad idea to treat deltas that way deliberatly,
and if you have random ordering of process execution within a delta
or time slot results are variable.
> A description whose results are based on delta behavior may
> work, but in those cases the description may not be
> portable to another Verilog simulator conforming to the LRM and the
> corresponding synthesized circuit may not produce the same results.
Unfortunately that hasn't stopped people writing their code that way :-(
> 2. Semaphores/Tasks
>
> >> Given that tasks in Verilog are re-entrant and all invocations of a
> >> given task share the same local variables, it is extremely easy to
> >> code semaphores in Verilog using tasks. Indeed, semaphore-based
> >> synchronization will work even after the circuit is synthesized.
> >>
> >
> >Not within a delta cycle if you have real parallelism. Some things only
> >work in Verilog because most implementations are single threaded and only
> >execute one process at a time. Things that look like atomic operations in
> >Verilog are very non-atomic in the executed machine-code.
>
> If the code containing no delays and belonging to a task is executed
> atomically in the sense that the execution of this code cannot be
> interrupted by the execution of the same task (Super FinSim has this
> property) then it is very easy to code a semaphore with a task.
That's much the same as the rule "processes sharing data will not be
evaluated concurrently" - which forces single-threaded execution, but that
rule isn't actually part of the standard yet (you might want to suggest
it for the SV-EC). I havn't checked, but I don't think there is a good
statement of what operations are supposed to be atomic, psuedo-code/
interpreter implementations can swap context inside expressions fairly
easily (Verilog-XL?) so I think the standard allows that (for debugging
purposes).
The problem is that two concurrently active processes have a hard time
negotiating locks & keys without a proper semaphore mechanism, but there
aren't many implementations where that can actually happen. Adding
semaphores allows you to describe behavior in Verilog that will work
properly when executed in a parallel processing simulator - which makes
that kind of simulator usable.
Regards,
Kev.
> Best regards,
> Alec
This archive was generated by hypermail 2b28 : Wed Sep 18 2002 - 18:20:32 PDT