Re: scheduling semantics for Verilog-AMS (issue 25)


Subject: Re: scheduling semantics for Verilog-AMS (issue 25)
From: Kevin Cameron (edaorg@v-ms.com)
Date: Tue Sep 17 2002 - 18:16:58 PDT


> From: Alec Stanculescu <alec@fintronic.com>
> To: Kevin.Cameron@nsc.com
>
> Kevin,
>
> > I presume the paragraphs before this are a copy of the standard Verilog queue processing?
> >
> > Is the last sentence of 9.3.3.5 complete? - looks like it's missing " are X" or something.
> >
> > > 9.3.3.6 analog macro-process event scheduling/processing
> > >
> > > When a D2A event occurs, then the analog macro-process which is to process this D2A is schedule
> > > for evaluation on the digital engine event queue. Note that if multiple analog macro-process events
> > > are scheduled for a particular analog macro-process for a particular time, then a single evaluation of
> > > the analog macro-process should consume all of these events from the queue.
> > >
> > > It also be note that the reason for processing analog macro-processes after other digital events is in
> > > order to minimize the number of times analog macro-processes are evaluated because such evaluations
> > > tend to be expensive.
> >
> > Does this work? If I have an "@(posedge clock)" in my analog block and an "@(posedge clock)" in my
> > digital, I don't think I want the analog processed after the non-blocking assigns of the digital.
> >
> Why not?
> > I think you may need to split it into explicit and implicit sensitivity - implicit would be done as you say,
> > and explicit (@ blocks) at the same time as the digital.
> >
> Counting on the order of evaluation is a dangerous thing to do. You
> can always use a #0 delay if you must use this modeling approach.
>

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.

[ I had problems with parallel processing digital Verilog with some designs
if the concurrent threads were not sync'd at the delta cycle level.]

>
> The same thing applies to the switch-level (bi-directional
> transistors). The way it is worded now it is consistent with the idea
> that one should not count on any particular order of evaluation of
> simultaneous processes.
>
> Regards,
> Alec

Maybe we'll get semaphores in SystemVerilog soon and the problem will start
going away :-)

Kev.

----- End Included Message -----



This archive was generated by hypermail 2b28 : Tue Sep 17 2002 - 18:17:56 PDT