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

Yes.
ed


________________________________

	From: Bassam Tabbara 
	Sent: Thursday, July 20, 2006 3:30 PM
	To: Lisa Piper; Eduard Cerny; sv-ac@eda-stds.org
	Subject: RE: [sv-ac] SV-AC new errata - 1547
	
	
	Lisa, I think what Ed means by the "local XMR" term is clocking
block name the "dot" operator and declarated item's name, see 15.6 (15.7
has example) so it is within the module.
	 
	Thx.
	-Bassam.
	 

________________________________

	From: owner-sv-ac@eda-stds.org [mailto:owner-sv-ac@eda-stds.org]
On Behalf Of Lisa Piper
	Sent: Thursday, July 20, 2006 11:46 AM
	To: Eduard Cerny; sv-ac@eda-stds.org
	Subject: RE: [sv-ac] SV-AC new errata - 1547
	
	

	 

	 

	
________________________________


	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 think it would be allowed, though it is not
something that I would particularly recommend.  

	 

	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 of the clocking block as another scope,
the only difference being that it cannot be standalone.  I did not know
there was a concept of a "local XMR".  I thought it would always be full
path.  Is the "local XMR" described in the standard?

	 

	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 >>>] as a user, it seems like an unnecessary rule
that I will learn after I make the mistake and have the compiler tell me
several times. If I can put a property or sequence there, then I don't
see why I should not be able to put an assertion there.  And again, I
like to see them together for the purpose of debug.  

	 

	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