RE: [sv-bc] Re: [sv-ac] Simulation semantics of continuous assignment

From: Kulshrestha, Manisha <Manisha_Kulshrestha@mentor.com>
Date: Wed Sep 22 2010 - 00:20:11 PDT

 
Hi,

Now this is clear that the continuous assignment schedules the process in the active region. Whenever anything on the right hand side of the continuous assignment changes (irrespective of the region in which it changes), a process is scheduled for the active region. When this active region comes, this process executes. Figure 4-1 in LRM (page 28) shows what all regions are there and ordering of regions.

Now, we come to the question of continuous assignments in checkers. The checkers would have design as well as checker variables on the right hand side of continuous assignment.

To understand how continuous assignment in checkers should behave, we need to look at current semantics for checkers. As per section 17.7.3 Scheduling Semantics, all the statements and constructs (i.e. always block) that are sensitive to changes are scheduled in reactive region (like programs). And non-blocking assignments of checker variables schedule their updates in Re-NBA region.

"These scheduling rules make possible assignment of sequence endpoint values to checker variables. For example:
checker my_check(...);
...
sequence s; ...; endsequence
always @clk a <= s.triggered;
endchecker
For every transition of signal clk, the simulator will update the variable a in the Re-NBA region with the
value of s.triggered captured in the Reactive region. Had the checker captured the value of s.triggered
in the Active region, a would always be assigned 1'b0, since s.triggered is evaluated in the
Observed region, and the above code would be meaningless."

Now, the question is how the variables on the left hand side of continuous assignments be used ? If we want to be consistent with the semantics of other processes in the checker, then it will be better to shedule continuous assginments in the checkers also in reactive region. If we do this, the concurrent assertions in the checker would see the previous value of the variable which is on the LHS of the continuous assignment. This is also the case curently where assertions see previous values of checkers variables which are assigned using nonblocking assignments as Re-NBA region is after Observed region.

Manisha

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Neil Korpusik
Sent: Wednesday, September 22, 2010 1:35 AM
To: J. M. Williams
Cc: sv-bc@eda.org; sv-ac@server.eda.org
Subject: Re: [sv-bc] Re: [sv-ac] Simulation semantics of continuous assignment

Hi Dmitry,

The best description of the relative ordering of event processing
in the program block and events outside of the program block is
described in sub-clause 24.3.2. In particular see the following
paragraph from that sub-clause.

    Sequential code declared in programs always executes in the reactive
    region set. Thus, variables on the other side of a program port
    connection are updated in the reactive region set. Similarly, the
    driving and resolution of nets on the other side of a program port
    connection also occurs in the reactive region set. Such driving and
    resolution occurs immediately after an event causes a change to a driver
    on a program net. Design processes sensitive to those cross-region
    variables and nets are scheduled for wake up in the active region set.

Section 24.3.2 is describing the case where a clocking block is not
used. I don't see any details in "14.16 Synchronous Drives" describing
when design processes sensitive to synchronous drives wake up, but it
is my understanding that it is consistent with the text in 24.3.2.

Note to John Michael Williams:

The program block is a new construct in SystemVerilog. This construct
does not exist in Verilog. Continuous assigns in SystemVerilog can be
to nets or variables.

The following is from 10.3

   Continuous assignments shall drive values onto nets or variables,
   both vector (packed) and scalar.

Neil

On 09/21/10 11:52, John Michael Williams wrote:
> Hi.
>
> If SV is consistent with verilog on this (and it
> should be), a continuous assignment would be
> executed only in the active region. It's a wire
> update, not a reg update.
>
> The evaluation of the RHS depends on the way the program block
> (I assume you mean a procedural assignment) was written.
> For example, a nonblocking assignment to a RHS variable would
> not be moved to the active region until the active region was
> emptied during the preceding cycle. Only after the nonblocking
> statement was executed would the RHS be updated and therefore
> the cts assignment (statement) be moved to the active region
> for execution.
>
> Variables can't be changed except in the active region -- assuming
> nothing inconsistent with the verilog event queue.
>
> On 09/21/2010 10:56 AM, Korchemny, Dmitry wrote:
>> Hi SV-BC,
>>
>> We would like to clarify the following question: If there is a
>> continuous assignment in a module, and its RHS was modified in a
>> program block, when will this continuous assignment be evaluated - in
>> the Active or in the Reactive region? Where is this described in the LRM?
>>
>> 4.9.1 "Continuous assignment" is not very clear about it. To me it
>> looks like that since the event is scheduled in the Reactive region,
>> it should be evaluated there. So if there is a continuous assignment
>> whose RHS depends both on design and TB elements, it can be evaluated
>> both in the Active and Reactive regions. Though I may be mistaken.
>>
>> Thanks,
>> Dmitry
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Sep 22 00:20:42 2010

This archive was generated by hypermail 2.1.8 : Wed Sep 22 2010 - 00:21:00 PDT