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

  

Mac,

That would be even worse, because there is no resolution between the two
statements. (i.e. one statement could set the signal to 'z while the
other one was supposed to be driving it)

Dave

________________________________

From: Michael (Mac) McNamara [mailto:mcnamara@cadence.com] 
Sent: Monday, December 05, 2005 8:47 AM
To: Rich, Dave; Bresticker, Shalom; sv-bc@eda.org
Subject: RE: [sv-bc] @* vs. always_comb

 

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