Subject: RE: [sv-ac] Re: [sv-ec] Re: [sv-bc] SystemVerilog 3.1 Scheduling Semantics
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Thu Feb 27 2003 - 09:29:35 PST
All,
There is an important difference with cbAfterDelay versus
cbAtStartOfSimTime. The cbAfterDelay--and it counterpart,
tf_setdelay()--callback allows a delay of 0, which to the user is like a #0
in the HDL. 1364-2001 Section 5.3 says "An explicit zero delay (#0)
requires that the process be suspended and added as an inactive event for
the current time so that the process is resumed in the next simulation
cycle in the current time.".
I suggest that the correct wording for cbAfterDelay and tf_setdelay()
callbacks is that they schedule a callback at the beginning of the inactive
event queue of the time slot specified. I underlined "at the beginning",
because the 1364 PLI task force has an open errata issue to resolve the
ambiguity of where cbAtStartOfSimTime events are scheduled relative to
cbAfterDelay. The proposed resolution is that cbAfterDelay events are
scheduled the same as blocking assignment events, meaning there is no
requirement to be before other events. This proposal has NOT yet been
discussed or accepted by the PLI task force.
Also note that Section 27.33.2 says specifying a delay of 0 for
cbAtStartOfSimTime is an error "when simulation has progressed into a time
slice, and the application is not currently within a cbAtStartOfSimTime
callback....Placing a callback for cbAtStartOfSimTime and a delay of zero
during a callback for reason cbAtStartOfSimTime will result in another
cbAtStartOfSimTime callback occurring during the same time slice.". This
infers that this callback needs a special queue, before any active events
are processed. It also requires that callbacks to that queue can be added
from within that queue.
I do not feel that there is an ambiguity in the 1364-2001 LRM regarding
where cbAtStartOfSimTime events are scheduled relative to
cbNextSimTime. These two types of callbacks are both scheduled before any
other events (meaning before any active events), in no particular
order. Since the LRM not explicitly define an order for the two callbacks,
it is inferred that there is no order.
Stu
At 10:13 PM 2/26/2003, Warmke, Doug wrote:
>Arturo, ss-wg,
>
>We agree with everything you and Francoise propose below.
>
>Here are some suggestions we hope will help
>generate the "clear definitions" you mentioned.
>
>1) As we understood it from the PLI task force,
> cbAtEndOfSimTime callbacks are allowed to schedule
> events at the current time. So even though the
> definition given by Francoise below is good,
> ("guaranteed to occur post NBA and after cbRWSynch"
> it should be further restricted to occuring before
> the postponed region.
>
>2) The cbAtStartOfSimTime, cbNextSimTime, and cbAfterDelay
> callbacks all run in the pre-active region. Are these
> three types of callbacks supposed to run in some
> particular order during this region? If there are
> no ordering requirements, how are cbAtStartOfSimTime
> and cbAfterDelay different?
>
> [NOTE: The following two suggestions would distinguish
> these three callbacks, possibly rendering the modeling
> system more useful and flexible for users.]
>
>3) How about putting cbAfterDelay into the active region?
>
>4) Would it make more sense for cbAtStartOfSimTime to be
> in the preponed region? (The current document specifies
> no callbacks in the preponed region.)
>
>5) If suggestions 3) and 4) are too controversial
> (i.e. different simulators are already doing things
> differently, and it would be too costly to move things
> around), then we should relax the region requirements
> for cbAtStartOfSimTime, cbNextSimTime, and cbAfterDelay
> to read "either preponed or pre-active, in no particular
> order".
>
>Thanks for considering these suggestions.
>We look forward to seeing a next rev of the document that
>addresses these issues and the ones Francoise raised.
>
>Best regards,
>Doug Warmke, MTI
>
>
>-----Original Message-----
>From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
>Sent: Wednesday, February 26, 2003 1:06 PM
>To: sv-ec@server.eda.org; sv-ac@server.eda.org; sv-cc@server.eda.org;
>sv-bc@server.eda.org
>Subject: [sv-ac] Re: [sv-ec] Re: [sv-bc] SystemVerilog 3.1 Scheduling
>Semantics
>
>
>Francoise is absolutely right. There are several ambiguously defined PLI
>calls, and at this point we cannot and should not attempt to define those
>calls. Only for the purpose of illustrating, we may want to show the
>various points at which implementations are calling tf_synchronize and
>cbRWsynch. But, those calls will continue to be ambiguous and different
>among implementations. However, as we move forward, we should very clearly
>define where the new callbacks occur so that users don't find themselves in
>the same quandary.
>
> Arturo
>----- Original Message -----
>From: Francoise Martinolle
>To: David W. Smith ; sv-ec@eda.org ; sv-ac@eda.org ; sv-cc@eda.org ;
>sv-bc@eda.org
>Sent: Tuesday, February 25, 2003 1:17 PM
>Subject: [sv-ec] Re: [sv-bc] SystemVerilog 3.1 Scheduling Semantics
>
>
>David,
>
>I don't know what is the reflector for the scheduling semantics committee so
>I am sending my
>comments to this reflector. Please forward to whom it should be sent to.
>
>
>I read the proposal and I noticed some errors in the PLI callback mappings.
>
>In the figure 5.1, the posponed region should be an oval to specify that
>only PLI callbacks
>are supposed to occur in that time slot, unless we are providing a new
>Verilog construct which creates postponed process (like VHDL) and which
>would execute just before the simulator moves to its next time queue.
>
>It is worth while to note that the time slots in which the tf_synchronize
>and cbRWsynch callbacks occur are not clearly defined in 1364, and is not
>implemented the same way between VXL, NC, VCS and modelsim simulators. This
>was the object of the paper at the last DVCON: "The facts and fallacies of
>Verilog event scheduling: is the IEEE 1364 Standard Right or Wrong?"
>This behaviour of these callbacks has been left as is and will not be
>modified so that
>applications will not break because of a change of behaviour. However two
>new callbacks
>were created for which the time slot occurrence is unambiguously defined:
> cbNBASynch
> is guaranteed to occur pre NBA and before any cbRWSynch callback
>
> (whenever they happen)
> cbAtEndOfSimTime
> is guaranteed to occur post NBA and after cbRWSynch (whenever
>they happen)
>
>I think we should leave tf_synchronize and cbRWSynch out of the mapping
>table since
>they can be mapped to different PLI regions, or mark the various
>interpretations of these
>callbacks.
>
>cbRoSynch and tf_rosynchronize should be mapped to the posponed PLI region.
>
>Are there any new callbacks defined for the post-observed region?
>
>For completion, you need to add the tf_(i)setdelay, tf_(i)setlongdelay and
>tf_(i)setrealdelay,
>vcl callbacks, tf_asynchon, etc...
>
>Francoise
> '
>
>
>
>
>At 04:55 PM 2/24/2003 -0800, David W. Smith wrote:
>
>The attached document was created and reviewed by the Scheduling Semantics
>Working Group. This group was formed from each of the SV committees to
>review the scheduling semantics required in SystemVerilog to support the
>enhancements being made by each of the committees. The members of the group
>are:
>
> Bassam Tabbara (Novas) (SV-AC)
> Dennis Brophy (Model Tech/Mentor) (SV-BC)
> Faisal Haque (Cisco) (SV-AC)
> Jay Lawrence (Cadence) (SV-EC)
> Joao Geada (SV-CC)
> Matt Maidment (Intel) (SV-BC)
> Michael Rohleder (Motorola) (SV-CC)
> Neil Korpusik (Sun) (SV-EC)
>
>and Phil Moorby, Arturo Salz, and Peter Flake from Synopsys representing the
>original definition. There were 9 votes in total (one for each committee
>representative and 1 for the trio representing the original definition).
>
>Cliff Cummings (Sunburst-Design), Tej Singh (Model Tech/Mentor), and Mehdi
>Mohtashemi (Synopsys) also attended some of the meetings and participated in
>the discussions.
>
>The result of this working group was the unanimous (one member abstained due
>to time conflicts with work limiting his ability to evaluate the work).
>
>In addition to the attached document there will be a presentation on Friday
>(being crafted by Arturo Salz and Jay Lawrence) that covers the technical
>content and rationale for the document.
>
>Regards
>David
>
>David W. Smith
>Synopsys Scientist
>
>Synopsys, Inc.
>Synopsys Technology Park
>2025 NW Cornelius Pass Road
>Hillsboro, OR 97124
>
>Voice: 503.547.6467
>Main: 503.547.6000
>FAX: 503.547.6906
>Email: david.smith@synopsys.com
>http://www.synopsys.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Feb 27 2003 - 09:30:41 PST