RE: [sv-ac] SV-AC new errata - 1547

 

 

________________________________

From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Thursday, July 27, 2006 2:52 PM
To: Lisa Piper; Eduard Cerny; sv-ac@eda-stds.org
Subject: RE: [sv-ac] SV-AC new errata - 1547

 

Hi Lisa,

 

I have no objection to allowing them in clocking blocks, its just that
the justification that it limits portability did not seem right. 

 

You may have a point regarding proximity of properyies and assertion, I
could see a case where the user has a clocking block for specifying
sampling and driving and wants to put assertions on the signals that are
marked as input, output, ... 

BUT, I hope that it will not confuse the user that the assertions sample
at 1step while the clocking block specifies some other sampling and
driving offset.

[Lisa Piper >>>] Interesting, but I think that defining properties in
the clocking block would cause that confusion too.   in other words I
would think it would be more consistent to then not allow either
property/sequence definitions or verification directives in the clocking
block. 

 

ed

 

	 

	
________________________________


	From: Lisa Piper [mailto:piper@cadence.com] 
	Sent: Thursday, July 27, 2006 2:36 PM
	To: Eduard Cerny; sv-ac@eda-stds.org
	Subject: RE: [sv-ac] SV-AC new errata - 1547

	Hi Ed,

	 

	I think I responded to part of this earlier but am responding to
the other part now.  I'd still like to hear from others what they think
about allowing assertion directives in clocking blocks.   It just seems
like an arbitrary rule that impacts a user's methodology.   

	 

	Lisa

	 

	
________________________________


	From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
	Sent: Thursday, July 20, 2006 2:06 PM
	To: Lisa Piper; sv-ac@eda-stds.org
	Subject: RE: [sv-ac] SV-AC new errata - 1547

	 

	Lisa, 

	 

	would you allow references to properties declared outside the
clocking block in concurrent_assertion_item which is placed in a
clocking block?

	[Lisa Piper >>>] I guess you could.  I would not recommend that
methodology personally, but if you want to assert properties that are
defined in a package then this might be one way to do it.

	 

	Also, the clocking block cannot exist on its own, i.e., it mus
be placed in a module, interface or program. Therefore, if the assertion
is outside the enclosure containing the clocking block, it will also
have to have an XMR. If it is inside, the XMR is local and I do not see
how it would affect portability.

	[Lisa Piper >>>]  I think it is pretty clear that I did not
understand this point.  I agree that portability is not an issue.

	 

	So... I am not that sure about necessity for the enhancement.
Can you give an example where the current situation is a hindrance?

	[Lisa Piper >>>] I still think it is good methodology to keep
the property definition and assertion of the property local.  It just
seems like an unnecessary rule that the user will run into when they
compile. 

	 

	Best regards,

	ed

	 

		 

		
________________________________


		From: owner-sv-ac@eda-stds.org
[mailto:owner-sv-ac@eda-stds.org] On Behalf Of Lisa Piper
		Sent: Thursday, July 20, 2006 1:58 PM
		To: sv-ac@verilog.org
		Subject: [sv-ac] SV-AC new errata - 1547

		I have just opened a new Mantis entry - #1547.  I had
asked for some feedback earlier and did not get much response (one was
for and one against).  Anyway, I think this is important from a
methodology perspective so would like to get more feedback. For
convenience the proposal is repeated below.

		 

		Lisa

		 

		=======================

		 

		Overview:

		 

		The way the standard is currently written, you cannot
associate a verification directive with properties that are defined
inside of a clocking block.  The only way to assert the property is to
use a hierarchical reference to the name of the property.  This is
undesirable for three reasons:

		1)      relying on hierarchical references affects code
portability

		2)      many methodologies recommend keeping the
property definition and its associated verification directive local for
ease of debug

		3)      the ability to instantiate properties from
packages in a clocking block

		 

		This proposes changes to allow for specifying
verification directives inside clocking blocks.

		 

		=======

		 

		 

		DETAILS:

		 

		Replace A.6.11 (and associated text in 15.2) 

		 

		clocking_declaration ::=

		[ default ] clocking [ clocking_identifier ]
clocking_event ;

		{ clocking_item }

		endclocking [ : clocking_identifier ]

		 

		clocking_event ::=

		@ identifier

		| @ ( event_expression )

		 

		clocking_item ::=

		default default_skew ;

		| clocking_direction list_of_clocking_decl_assign ;

		| { attribute_instance }
concurrent_assertion_item_declaration

		 

		 

		 

		WITH

		 

		 

		clocking_declaration ::=

		[ default ] clocking [ clocking_identifier ]
clocking_event ;

		{ clocking_item }

		endclocking [ : clocking_identifier ]

		 

		clocking_event ::=

		@ identifier

		| @ ( event_expression )

		 

		clocking_item ::=

		default default_skew ;

		| clocking_direction list_of_clocking_decl_assign ;

		| { attribute_instance }
concurrent_assertion_item_declaration

		| concurrent_assertion_item

		 

		 

		 

		 

		REPLACE (in 17.13)

		 

		A concurrent assertion statement can be specified in any
of the following:

		- An always block or initial block as a statement,
wherever these blocks can appear

		- A module

		- An interface

		- A program

		 

		WITH

		 

		A concurrent assertion statement can be specified in any
of the following:

		- An always block or initial block as a statement,
wherever these blocks can appear

		- A module

		- An interface

		- A program

		- A clocking block