RE: [sv-bc] @* vs. always_comb

From: Michael \(Mac\) McNamara <mcnamara_at_.....>
Date: Mon Dec 05 2005 - 08:46:30 PST
OK, how about these statements occurring back to back in the same
module?  This would violate 11.2, there by making illegal the use of
always_comb (that name reminds me of being ten years old, and my mom
insisting I do something to make my hair look decent).
 
@* has no such restriction, making it the logical choice.
 
 
Michael McNamara

mcnamara@cadence.com

408-914-6808 work

408-348-7025 cell

 

 


________________________________

	From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf
Of Rich, Dave
	Sent: Sunday, December 04, 2005 10:52 PM
	To: Bresticker, Shalom; sv-bc@eda.org
	Subject: RE: [sv-bc] @* vs. always_comb
	
	
	  

	Shalom,

	I do not think outputs wired together at in a higher level
module constitute a violation of the rule in 11.2. They are separate
variables in each of the lower level modules where the procedural
statements are placed.

	And if you are trying to model a bi-directional tri-state bus,
then you will have to use an inout port, which requires wires on the
upper and lower module connections.

	Dave

	
________________________________


	From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf
Of Bresticker, Shalom
	Sent: Saturday, December 03, 2005 11:38 PM
	To: sv-bc@eda.org
	Subject: [sv-bc] @* vs. always_comb

	 

	I bet you though this issue was dead, didn't you?

	 

	I recently came across the claim that there is a standard
situation where neither always_comb nor always_latch is appropriate, but
@* does work. If this is really so, then we can't just deprecate @* and
say to use always_comb instead. We'll have to make sure that @* works
properly.

	 

	The situation is of modeling a three-state bus.

	In this case, we get statements like

	 

	always @* sig = cond1 ? in1 : 1'bz ;

	always @* sig = cond2 ? in2 : 1'bz ;

	etc.

	 

	The catch is that these statements will be found in different
modules and the three-state outputs are wired together at a higher level
in the hierarchy, thus violating the always_comb condition in 11.2 that
"the variables written on the left-hand side of assignments shall not be
written to by any other process."

	 

	Comments? I do not remember seeing this noted elsewhere. Maybe
it was and I just don't remember.

	 

	Thanks,

	Shalom

	 

	Shalom Bresticker

	Intel Jerusalem LAD DA

	+972 2 589-6852

	+972 54 721-1033

	I don't represent Intel 

	 



image001.gif
Received on Mon Dec 5 08:46:44 2005

This archive was generated by hypermail 2.1.8 : Mon Dec 05 2005 - 08:46:48 PST