Subject: [sv-bc] Review notes about section 14 event scheduler from a PLI expert
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Apr 11 2003 - 18:28:57 PDT
Hi, All -
I asked Darren Jones of MIPS to take a look at the new event scheduler to
give me feedback with respect to PLI calls. Darren does a lot of PLI
testbench creation so I consider his comments to be both valuable and from
an expert PLI verification user.
Relevant comments below.
Regards - Cliff
>Date: Fri, 11 Apr 2003 18:22:50 -0700
>To: Darren Jones <dj@mips.com>
>From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>Subject: Re: SystemVerilog PLI review
>
>Hi, Darren -
>
>Thanks for the review. Comments below.
>
>At 04:49 PM 4/8/03 -0700, you wrote:
>>Hi Cliff,
>>Here are my comments-
>>
>>If I understand correctly, you have added the preponed, observed and
>>reactive event regions specifically for new featuralities in
>>SystemVerilog. You have not added any new PLI calls for SystemVerilog.
>>(ALthough it appears that new callback reasons have been added) You have
>>added the pre-active, pre-NBA, post-NBA, and post-observed event regions
>>specifically for PLI callbacks. Since you have not added new PLI calls,
>>I dont see why you need to add the new PLI-only event regions.
>
>The EDA vendors like the new regions for connecting to new tools. The
>names are pretty fixed at this time.
>
>>In fact, since the Verilog LRM specifically states that callback
>>routines get put into the inactive event region (See section 5.3 of the
>>LRM), your description in section 14.4 is non-compliant to the existing
>>Verilog LRM. I think this will create serious compatibility issues
>>between SystemVerilog and Verilog.
>
>I will look closer at this. Thanks.
Is this a problem with the SV algorithm?
>>* I recommend renaming the preponed event region to prepended, which
>>makes more sense. Is preponed a word?
>
>Preponed is actually a word (I forget which dictionary but it is
>contrasted with postponed).
>
>>* I recommend renaming postponed to monitor to match the Verilog LRM.
>
>I know and agree, but I may lose this battle.
>
>>* Your flowchart in 14.3.1 is inaccurate. The important distinction is
>>that events are only ever removed from the active event region.
>
>This was the description we added to the Verilog-1995 Standard as a
>conceptual model. In reality, I doubt if any simulator "promotes" events
>to the active events queue (despite my paper descriptions).
>
>>You
>>should reproduce the algorithm from the Verilog LRM and add the new
>>event regions accordingly. (Dont forget to add future preponed, future
>>observed, and future reactive event regions)
>
>For the most part, active events are executed, then an event pointer is
>moved to the inactive events region (if there are inactive events) and
>executing the inactive events may cause more active events to be
>scheduled. What is nice about the new diagram is that it shows iterative
>regions and the looping back at each point to pick up new active events.
>Phil Moorby (father of the Verilog language) did most of this diagramming
>with help from others, including myself. I actually like this diagram
>better and will start using a Verilog-2001 version of it soon myself, for
>training.
>
>I also like the new algorithmic description better, although I am not
>crazy about routine calling routine calling routine to show the pseudo
>algorithm in the LRM. I have voiced my disappointment. We will see what
>happens. The old algorithm was almost upside down - if there are no active
>events ... else (at the bottom) execute the active events. I point this
>out in my paper.
>
>I never like our Verilog-1995 and Verilog-2001 description of future event
>queues. Future events are really nothing more than scheduling nonblocking
>updates into the standard queue that is being built for a future time.
>
>>* Related to the above is the fact that I think there really is no
>>preponed event region; there can only be a future preponed event region.
>>This is due to the fact that an active event cannot add a new event to
>>the preponed event region of the current timestep. (It can add events to
>>the other event regions of the current timestep).
>
>I know, this is really sort of wacky, but the EDA vendors basically are
>trying to say that sampling o inputs can be done immediately before any
>active clock edge. I agree with you that preponed is really just prior to
>this time step and I have pointed out confusing verbiage from multiple
>sections that describe this condition. I am waiting to see what type of
>response I get. It also seems to go against cycle-based simulation, but I
>think vendors are going to use preponed as an excuse to sample inputs in
>the new time step before even sampling the clock (the clocking construct
>tells the simulator when the cloks are going to occur).
>
>>* The information that is missing from the Verilog LRM is which event
>>region the tf_putp, tf_strdelputp, vpi_put_value, etc put their update
>>events into. (I suspect it is the active event region or the future
>>inactive event region) It would be nice to have this clarified in the
>>SystemVerilog spec.
>
>I will pass this message on to the group. Thanks. As long as we are
>cleaning things up, let's clean this up too.
I am not a PLI expert. Could anybody comment on this?
>>To make the PLI more useful and to eliminate the loss of intra-timetick
>>information across the PLI, my wishlist includes:
>> * The ability to schedule callbacks for any event region.
>> * The ability to do the equivalent of vpi_put_value into any
>> current or
>>future event region.
>
>I will pass this on. I thought the new PLI regions basically accomplished
>your first goal (schedule HDL ... schedule PLI ... next HDL region ...
>next PLI region ... etc. then finally advance the time step - of course
>future PLI calls could also be scheduled).
Does SV 3.1 meet Darren's wish list?
>>This really requires new PLI/VPI calls, since the existing ones dont do
>>this, as far as I can tell. I suppose you could do the first half of
>>this by defining new generic callback reasons which force the simulator
>>to schedule the events in different regions. Actually, if this one thing
>>were done, I could generate the behavior of vpi_put_value with a
>>combination of callbacks and the existing vpi_put_value. Ugly, but
>>possible.
>
>I think we are trying to reduce the "ugly" piece.
>
>>Darren
>
>Thanks for your feedback.
>
>Regards - Cliff
>
>>--
>>Darren Jones Engineering Manager
>>MIPS Technologies Phone: (650)567-5103
>>1225 Charleston Rd. mailto:dj@mips.com
>>Mountain View, CA 94043 http://www.mips.com
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Fri Apr 11 2003 - 18:29:09 PDT