Re: [sv-ac] Minutes of SV-AC Meeting 6/14/2011 - clocking blocks

From: Daniel Mlynek <danielm@aldec.com.pl>
Date: Tue Jun 14 2011 - 23:08:10 PDT

http://www.verilog.org/mantis/view.php?id=3156
http://www.verilog.org/mantis/view.php?id=3562

On 6/14/2011 11:52 PM, Eduard Cerny wrote:
> Dave, look at
> on page 289, 14.10, it says:
> The clocking event of a clocking block is available directly by using the clocking block name, regardless of
> the actual clocking event used to declare the clocking block.
> For example:
> clocking dram @(posedge phi1);
> inout data;
> output negedge #1 address;
> endclocking
> The clocking event of the dram clocking block can be used to wait for that particular event:
> @( dram );
> The above statement is equivalent to @(posedge phi1).
>
> ed
>
>> -----Original Message-----
>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich,
>> Dave
>> Sent: Tuesday, June 14, 2011 5:48 PM
>> To: sv-ac@eda-stds.org
>> Subject: RE: [sv-ac] Minutes of SV-AC Meeting 6/14/2011 - clocking blocks
>>
>> I noticed this item at the end of the minutes
>>
>> - Opens
>> Clocking Blocks:
>> Ed: Confusion in LRM? Question about whether @(clocking_block) is really
>> equivalent to @(clocking_event_defined_in_clocking_block)
>>
>> The 1800-2009 LRM section 14.13 says "Upon processing its specified
>> clocking event, a clocking block shall update its sampled values before
>> triggering the event associated with the clocking block name. This event
>> shall be triggered in the Observed region. Thus, a process that waits for
>> the clocking block itself is guaranteed to read the updated sampled
>> values, regardless of the scheduling region in which either the waiting or
>> the triggering processes execute. "
>>
>> So they are not equivalent for simulation.
>>
>> Dave
>>
>>
>> --
>> 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 Tue Jun 14 23:08:23 2011

This archive was generated by hypermail 2.1.8 : Tue Jun 14 2011 - 23:08:28 PDT