[sv-ec] Latest Event Scheduling Proposal

From: Clifford E. Cummings <cliffc_at_.....>
Date: Sun Mar 04 2007 - 18:13:58 PST
Hi, All -

I believe I have captured all of the modifications recorded by Neil. 
There is a section 9.4 so I did not delete the PLI forward references 
to that section.

Talk to you all tomorrow.

Regards - Cliff

At 03:12 PM 3/2/2007, Neil Korpusik wrote:

>Hi Cliff,
>
>Here is the set of changes that we agreed to in the SVEC F2F on Feb. 20th.
>All of these are to be applied to the proposal that you put together for
>Clause 9.
>
>If you don't have time to get the updates made in time for the meeting on
>Monday, please send me the source file and I will try to make the changes
>before the meeting.
>
>The updated proposal needs to be added to mantis 890 (part 2). It should be
>named SV-890-7-part2.pdf. Stu agreed that it would not a problem for us to
>have two parts to one mantis proposal.
>
>
>1. 9.3 The stratified event scheduler
>
>    Add a new pli region (Pre-Observed).
>    This change came from the svcc. The svec is in agreement with it.
>
>    From
>       g) Post-NBA
>       h) Observed
>    To
>       g) Post-NBA
>       h) Pre-Observed
>       i) Observed
>
>    - Update figure 9.1 with this change
>      There is no loopback from this region (similar to Pre-Active).
>    - Create a new "9.3.3.5 Pre-Observed PLI region"
>
>      The Pre-Observed region provides for a PLI callback control point that
>      allows PLI application routines to read values after the active region
>      set has stabilized.
>    - There are other sections that also need to be updated with this change.
>      9.3.1, 9.3.4 at a minimum.
>
>    Second to last paragraph in this section (change word testbench to
>    verification).
>
>    From
>       ... to provide predictable interactions between the design and
>       testbench code.
>    To
>       ... to provide predictable interactions between the design and
>       verification code.
>
>    Last paragraph in this section (drop the work essentially).
>
>    From
>       The Pre-Active, Active, Inactive, Pre-NBA, NBA, Post-NBA, 
> Pre-Postponed
>       and Postponed regions essentially encompass the IEEE 
> 1364-2005 reference
>       model for simulation, with exactly the same level of determinism.
>    To
>       The Pre-Active, Active, Inactive, Pre-NBA, NBA, Post-NBA, 
> Pre-Postponed
>       and Postponed regions encompass the IEEE 1364-2005 reference
>       model for simulation, with exactly the same level of determinism.
>
>2. 9.3.2 Simulation regions
>
>    The Preponed region needs to be added to the list of simulation regions.
>
>    From
>       The simulation regions of a time slot are the Active, Inactive, NBA,
>       Observed, Reactive, Re-Inactive, Re-NBA and Postponed regions.
>    To
>       The simulation regions of a time slot are the Preponed, 
> Active, Inactive,
>       NBA, Observed, Reactive, Re-Inactive, Re-NBA and Postponed regions.
>
>3. 9.3.2.3 Inactive events region
>
>    Word-smithing (the words 'to', 'to be' and 'region' are being added)
>
>    From
>       If events are being executed in the active region set, an explicit #0
>       delay control requires that the process be suspended and an event
>       scheduled into the Inactive of the current time slot so that 
> the process
>       can be resumed in the next Inactive to Active iteration.
>    To
>       If events are being executed in the active region set, an explicit #0
>       delay control requires the process to be suspended and an event to be
>       scheduled into the Inactive region of the current time slot 
> so that the
>       process can be resumed in the next Inactive to Active iteration.
>
>4. 9.3.2.5 Observed events region
>
>    The second sentence needs to be removed. It was agreed that this should
>    be considered a tool feature and not part of the LRM.
>
>    From
>       The Observed region is for evaluation of property expressions 
> when they
>       are triggered.  Triggering an event that designates the clock of an
>       assertion or clocking block more than once in the same time slot shall
>       be an error. During property evaluation, pass/fail code shall be
>       scheduled in the Reactive region of the current time slot. 
> PLI callbacks
>       are not allowed in the Observed region.
>    To
>       The Observed region is for evaluation of property expressions 
> when they
>       are triggered. During property evaluation, pass/fail code shall be
>       scheduled in the Reactive region of the current time slot. 
> PLI callbacks
>       are not allowed in the Observed region.
>
>5. 9.3.2.6 Reactive events region
>
>    The reference number is off by one.
>
>    From
>       The Reactive region is the reactive region set dual of the 
> Active region
>       (see 9.3.2.1).
>    To
>       The Reactive region is the reactive region set dual of the 
> Active region
>       (see 9.3.2.2).
>
>6. 9.3.2.7 Re-Inactive region
>
>    Word-smithing (add the word 'be') and reference number off by one.
>
>    From
>       If events are being executed in the reactive region set, an 
> explicit #0
>       delay control requires that the process be suspended and an event
>       scheduled into the Re-Inactive region of the current time slot so that
>       the process can be resumed in the next Re-Inactive to 
> Reactive iteration.
>       The Re-Inactive region is the reactive region set dual of the Inactive
>       region (see 9.3.2.2).
>    To
>       If events are being executed in the reactive region set, an 
> explicit #0
>       delay control requires the process to be suspended and an event to be
>       scheduled into the Re-Inactive region of the current time slot so that
>       the process can be resumed in the next Re-Inactive to 
> Reactive iteration.
>       The Re-Inactive region is the reactive region set dual of the Inactive
>       region (see 9.3.2.3).
>
>7. 9.3.2.9 Postponed events region
>
>    We agreed that the first sentence needs to be re-worded. The part
>    about "monitoring of signals" is too general. Below is what I think
>    we agree to.
>
>    From
>       The Postponed region is where the monitoring of signals, and other
>       similar events, takes place.
>    To
>       $monitor, $strobe, cbReadOnlySynch and other similar events are
>       scheduled in the Postponed region.
>
>    Add the word "current".
>
>    From
>       No new value changes are allowed to happen in the time slot once the
>       Postponed region is reached.
>    To
>       No new value changes are allowed to happen in the current 
> time slot once
>       the Postponed region is reached.
>
>    Remove the reference since we deleted the section being referred to.
>
>    From
>       Postponed region PLI events are also scheduled in this region
>       (see 9.3.3.9).
>    To
>       Postponed region PLI events are also scheduled in this region.
>
>8. 9.3.3.2 Pre-Active PLI region
>
>    There is a reference to a section that doesn't exist.
>    I just now noticed that the section being referred to (9.4) is in the
>    LRM, but not shown in your proposal. It looks like this is ok.
>
>9. 9.3.3.5 Post-Observed PLI region
>
>    Word-smithing (the part in parentheses)
>
>    From
>       The Post-Observed region provides for a PLI callback control 
> point that
>       allows PLI application routines to read values after properties are
>       evaluated (in Observed or earlier region).
>    To
>       The Post-Observed region provides for a PLI callback control 
> point that
>       allows PLI application routines to read values after properties are
>       evaluated (in the Observed or an earlier region).
>
>10. 9.3.3.8 Pre-Postponed PLI region
>
>     I think you already had this change in mind. The last sentence should
>     be dropped.
>
>     From
>        The Pre-Postponed region provides a PLI callback control point that
>        allows PLI application routines to read and write values and create
>        events after processing all other regions except the 
> Postponed region.
>        The flow of execution of the event regions is specified in Figure 9-1.
>     To
>        The Pre-Postponed region provides a PLI callback control point that
>        allows PLI application routines to read and write values and create
>        events after processing all other regions except the 
> Postponed region.
>
>11. 9.3.3.9 Postponed PLI region
>
>     This whole section should be deleted. It is redundant.
>
>12. 9.3.4 The SystemVerilog simulation reference algorithm
>
>     Change two words in the first block of code (next future).
>
>     From
>       execute_simulation {
>         T = 0;
>         initialize the values of all nets and variables;
>         schedule all initialization events into time 0 slot;
>         while (some time slot is nonempty) {
>             move to the next future nonempty time slot and set T;
>             execute_time_slot (T);
>         }
>       }
>     To
>       execute_simulation {
>         T = 0;
>         initialize the values of all nets and variables;
>         schedule all initialization events into time 0 slot;
>         while (some time slot is nonempty) {
>             move to the first nonempty time slot and set T;
>             execute_time_slot (T);
>         }
>       }
>
>
>Neil

----------------------------------------------------
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, SystemVerilog, Synthesis and Verification Training

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Received on Sun Mar 4 18:14:50 2007

This archive was generated by hypermail 2.1.8 : Sun Mar 04 2007 - 18:15:16 PST