Subject: Re: scheduling semantics for Verilog-AMS (issue 25)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Sep 18 2002 - 15:08:36 PDT
[Sorry if you duplicates of the previous message - my sendmail config.
got screwed up and it didn't appear to have gone]
> From: "Alec Stanculescu" <alec@fintronic.com>
>
> Kevin,
>
> First, I have Verilog-AMS 2.0 LRM, but what is says makes so much
> sense that I do not believe that it changed since:
>
> 8.3.6 Concurrency
>
> .........
>
> Any synchronization method can be employed, provided that the
> semantics <is> preserved. A typical synchronization algorithm is
> presented in 9.2.
>
> 8.6.3.2
>
> ...........
>
> When it is determined <that> the event has occurred in the digital
> domain, the statements under the event control shall be executed in
> the analog domain at the time corresponding to a real promotion of the
> digital time.
>
> --------------------------------------------------------------------
> I conclude that the analog part must be evaluated at the correct time
> but not necessarily at the same delta.
>
> ---------------------------------------------------------------------
>
> Your point seems to be that the analog part should be evaluated at the
> same "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.
This has partly to do with the fixed time-step of Verilog. If you had
infinite precision you would not need deltas, but Verilog has a deliberately
coarse time step, any delays that are below 1 time step have to be handled
by using delta delays. The difference between blocking and non-blocking
assigns is whether the assignment takes place in the current delta or
the next - the assumption being that real hardware will have a real delay
for the non blocking, and no significant delay for the blocking.
I.e. events A and B are definitely ordered in time.
> Therefore, one should use a modeling approach in which the results do
> not depend on the exact delta at which an event occurs. Such modeling
> style allows for faster simulation and does not hide timing problems
> that may produce difficulties later on.
That would be nice. As I mentioned before I had one design that had a
problem with delta-cycle synchronization between threads. The people
who wrote the design had followed a strict style guide to help make
the design run parallel - but it still didn't work reliably unless
the threads were synchronized at the delta-cycle level.
It's too much to ask users to design that way.
> > You can't count on the order within a delta cycle, but you do count on
> > the order of execution over delta cycles, a #0 pushes execution into the
> > next delta cycle. The implication (as I read it) was that any event crossing
> > the digital->analog boundary would be delayed until the last delta for a given
> > time which can put it out-of-sync.
> If deltas are important, then one can use #1, #2, etc. for delays in
> gates, latches, etc., but such approaches must be used based on a very
> well thought modeling discipline that is adequate for a given family
> of circuits. This will give you control over deltas (in a sense with
> #1 you make your own delta), but the delta approach may not lead to
> circuits that work once the description is synthesized.
My view is that a block gated with "@(posedge clock)" in analog should be
evaluated at the same delta as the statement in digital, anything else will
be too confusing for users.
> >
> > [ I had problems with parallel processing digital Verilog with some designs
> > if the concurrent threads were not sync'd at the delta cycle level.]
> >
> Such descriptions may not work well after being synthesized.
>
> > Maybe we'll get semaphores in SystemVerilog soon and the problem will start
> > going away :-)
> >
> Given that tasks in Verilog are re-entrant and all invocations of a
> given taks 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.
> > Kev.
> >
> Regards,
>
> Alec
BTW, the Verilog-A that I worked on at MetaSoftware evaluated analog processes
fairly independently. The evaluation of an @ block in a single analog process
would not require the re-evaluation of all the processes in the macro-process
until the end of the time slot. Also, by the end of the time-slot the @ condition
may not be true and some alternative path through the code will be executed - i.e.
you should probably evaluate more than once anyway.
Regards,
Kev.
.
This archive was generated by hypermail 2b28 : Wed Sep 18 2002 - 15:10:42 PDT