RE: [sv-ec] cycle delays in assignments

Doug,

 

If we want to go this way, we need a mechanism to associate the delay
wit the specific clocking block.

 

By changing the semantics as you propose, we would take away the ability
to use a specific clocking block. Note that before this change, users
could re-write the code to achieve either semantics, but now it's
impossible to use cycle delays with any clocking other than the default
clocking. I honestly believe that using the default clocking block for
an intra-assignment delay to a particular clocking block will be more
confusing. As I said before, we can make arguments either way, but we
need to be careful since users are already using these features.

 

            Arturo

 

________________________________

From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
Sent: Friday, February 02, 2007 7:41 PM
To: Arturo Salz; Rich, Dave; sv-ec@eda-stds.org
Subject: RE: [sv-ec] cycle delays in assignments

 

My opinion is different.

 

In Mantis #609, it is commented that

 

##n cb.v <= e;

##n; cb.v < = e;

 

have surprisingly different semantics.

At the face to face we decided that ##n would indicate

cycles of the default clocking in both these cases.

 

Similarly, I feel that

 

cb.v <= ##n e;

v <= ##n e;

 

would have surprisingly different semantics if we keep with

the existing P1800-2005 definition of intra-assignment cycle delays.

 

I think the language will be most intuitive if ##n is always associated

with the default clocking.  That way users won't have to remember,

"Well, if the ##n is on the left, it is associated with default
clocking. 

And if it is on the right, it is associate with the clocking block's
clocking."

 

Regards,

Doug

 

 

	 

	
________________________________


	From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of Arturo Salz
	Sent: Friday, February 02, 2007 4:15 PM
	To: Rich, Dave; Arturo Salz; sv-ec@server.eda-stds.org
	Subject: RE: [sv-ec] cycle delays in assignments

	With respect to using intra-assignment cycle delays, I recognize
that the BNF allows it, but that may not have been the intent. If we
want to ratify then I'm OK with it.

	 

	As to the question, I assume you mean (you have an extra
semicolon):

	cb.v <= ##n e;

	 

	I believe that an argument can be made for either semantics: Use
the default to keep it consistent with the other  cycle delays, or, Use
the cb because it is closely associated with it.

	I prefer to keep the existing semantics because (a) it's more
likely to match the user's intent, and (b) it's already specified as
much in the LRM - and in this case, it's not confusing.

	 

	            Arturo

	 

	
________________________________


	From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
	Sent: Friday, February 02, 2007 3:05 PM
	To: Arturo Salz; sv-ec@eda-stds.org
	Subject: RE: [sv-ec] cycle delays in assignments

	 

	Right now, the BNF has

	 

	procedural_timing_control ::=

	delay_control

	| event_control

	| cycle_delay

	 

	 

	So if this is legal

	 

	task1;

	##2

	task2;

	 

	this  is legal as well

	 

	v = ##m e;

	 

	are legal and nothing to do with clocking drives

	 

	But also answer whether you think

	 

	cb.v <= ##n; e;

	 

	##n is the default clocking or cb clocking

	 

	 

	Dave

	 

	 

	 

	
________________________________


	From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
	Sent: Friday, February 02, 2007 2:51 PM
	To: Rich, Dave; sv-ec@eda-stds.org
	Subject: RE: [sv-ec] cycle delays in assignments

	 

	Dave,

	 

	My recollection was that ## could not be used as an
intra-assignment delay, only for clocking block drives.

	 

	I'm not sure if we voted on a resolution, but we certainly
discussed the problem of how adding semicolon after the cycle delay
would change the semantics, that is:

	      ##k cb.v <= e;

	                vs

	      ##k ; cb.v <= e;

	That's the issue in favor of not making scheduling decisions
based on the target.

	 

	We also discussed, but didn't finalize, adding an extension that
allows users to associate a particular clocking block to the cycle delay
operator.

	 

	I hop this helps.

	 

	            Arturo

	 

	
________________________________


	From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf
Of Rich, Dave
	Sent: Friday, February 02, 2007 1:51 PM
	To: sv-ec@eda-stds.org
	Subject: [sv-ec] cycle delays in assignments

	 

	 

	I know we agreed in the face-to-face that

	 

	##k cb.v <= e;

	should use the default clocking. 

	 

	I don't remember if we touched upon the following: 

	 

	 

	v = ##l e; //blocking assignment with intra-assignment delay -
uses default clocking block

	v <= ##m e;//non-blocking assignment - uses default clocking
block

	cb.v <= ##n; e; //clocking drive - uses CB clock

	 

	From the 11/6 face to face, we had:

	Agreements reached: 
	      Don't make scheduling decisions based on the target.
	 
	Is this an exception? Or should all ## delays be based on the
default clocking.
	 
	We're trying to finish up 890.
	 
	Thanks,
	 
	Dave

	 

	David Rich
	Verification Technologist
	Design Verification & Test Division
	Mentor Graphics Corporation
	dave_rich@mentor.com
	Office:   408 487-7206
	Cell:     510 589-2625

	 

	
	-- 
	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 <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.