[sv-ac] RE: Embedding concurrent assertions in procedural code

Hi guys--

I went ahead & submitted a proposal to fix this, for now striking just the last clause of that paragraph ("and the clocking
event, if specified otherwise, shall be identical to the contextually inferred clocking event") and correcting a related example below.
http://www.verilog.org/mantis/view.php?id=2516


Dmitry, Lisa, Gord-- please take a look, and if you agree this is the correct way to go I'll call  another vote, and we'll make this a ballot amendment as well.

________________________________
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Seligman, Erik
Sent: Wednesday, November 05, 2008 8:28 AM
To: Korchemny, Dmitry; Lisa Piper
Cc: sv-ac@server.eda.org; sv-sc@eda.org; stuart@sutherland-hdl.com
Subject: [sv-ac] RE: Embedding concurrent assertions in procedural code

Ugh.  This actually contradicts the changes in 2398, which explicitly allow such a case:  See the example with 'r1'.

So, I think we need another new proposal to strike the last sentence in the paragraph you quote below, to make an issue at balloting.   Before I write the proposal-- what does "The maximal property of such a concurrent assertion statement shall be singly clocked" mean exactly?  Do we still need it, or can we strike that part of the sentence too?  I thought we were allowing multi-clocked properties in general now.



________________________________
From: Korchemny, Dmitry
Sent: Wednesday, November 05, 2008 8:21 AM
To: Seligman, Erik; Lisa Piper
Cc: sv-ac@server.eda.org; sv-sc@eda.org; stuart@sutherland-hdl.com
Subject: RE: Embedding concurrent assertions in procedural code

Hi Erik,

Are you sure this limitation has been lifted?

16.17 Clock resolution reads:

c) A contextually inferred clocking event from a procedural block supersedes a default clocking event.
The contextually inferred clocking event is treated as though it had been written as the leading
clocking event of any concurrent assertion statement to which the inferred clock applies. The maximal
property of such a concurrent assertion statement shall be singly clocked, and the clocking
event, if specified otherwise, shall be identical to the contextually inferred clocking event.

Dmitry

From: Seligman, Erik
Sent: Wednesday, November 05, 2008 6:11 PM
To: Korchemny, Dmitry; Lisa Piper
Cc: sv-ac@server.eda.org; sv-sc@eda.org; stuart@sutherland-hdl.com
Subject: RE: Embedding concurrent assertions in procedural code

Actually, r2 is deleted explicitly in 2398 -- see the 8/13 proposal draft, p.5, near the top (http://www.verilog.org/mantis/file_download.php?file_id=3886&type=bug).  I think this was because it mentioned a restriction (If the clock is explicitly specified with a property, then it shall be identical to the inferred clock) which is no longer true.

Stu, can we treat the re-numeration and variable renaming as editorial issues?  Would you like me to add a bugnote?
________________________________
From: Korchemny, Dmitry
Sent: Wednesday, November 05, 2008 12:54 AM
To: Lisa Piper; Seligman, Erik
Cc: sv-ac@server.eda.org; sv-sc@eda.org; stuart@sutherland-hdl.com
Subject: Embedding concurrent assertions in procedural code
Hi Lisa, Erik,

It looks to me that the subclause 16.15.6 Embedding concurrent assertions in procedural code is broken. Here are the issues I found:

*         Example with property r2 has been deleted. I could not find the reason either in 1698 or in 2398

*         If r2 does need to be deleted (though I am not sure it does), the numeration of all other properties should be shifted: r3 should become r2, etc

*         Examples with r3 and r4 have assignments r1 <= reset ? 0 : r1 + 1; and r1 <= reset ? 0 : r2 + 1; which is confusing since r1 and r2 are property names in the previous examples. I think they should read: d1 <= reset ? 0 : d1 + 1; and d1 <= reset ? 0 : d2 + 1;

Could you, please, check?

Thanks,
Dmitry

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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