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.