Thanks, John, Neil, and Gord for your explanation.
Dmitry
-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, September 24, 2010 5:09 PM
To: neil.korpusik@oracle.com
Cc: sv-bc@eda.org; sv-ac@server.eda.org
Subject: Re: [sv-bc] Re: [sv-ac] Simulation semantics of continuous assignment
I agree with Neil's conclusion but I think the argument is
a bit more clear than just 24.3.2. If you look at the
end of 24.3.1 and the other descriptions of processes, it
is fairly clear that a process is always scheduled in the
region associated with it declaration -- reactive for
program text and active for anything else. The point at which
the update event occurs is immaterial. This is similar to
the situation in which the LHS of an NBA is updated in the
NBA region and causes the triggering of the related update
events for processes sensitive to the LHS. Those processes
don't get scheduled in the NBA queue; they get scheduled
in the queue associated with their declaration.
Gord.
On 9/21/2010 1:05 PM, Neil Korpusik wrote:
> 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.
>>>
>>
>
-- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- 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.Received on Sun Sep 26 00:21:40 2010
This archive was generated by hypermail 2.1.8 : Sun Sep 26 2010 - 00:23:23 PDT