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

Indeed.  One would naturally do this with two assign statements, or
perhaps just one.  Many of these corner cases of closed issues make
one's head hurt thinking about them, especially when there is a clear
obvious way to do it right which 99% of good designers would choose.
The tough bit is that the standards committee is duty bound to describe
what happens when the less traveled way is taken.
 

// could be 'x if both cond1 and cond2 are true, and in1 = ! in2.

assign sig = cond1 ? in1 : 1'bz ;

assign sig = cond2 ? in2 : 1'bz ;

Or

assign sig = cond1 ? in1 : cond2 ? in2 : 1'bz; // priority to cond1

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 Mark Hartoog
	Sent: Monday, December 05, 2005 9:01 AM
	To: Bresticker, Shalom; sv-bc@eda.org
	Subject: RE: [sv-bc] @* vs. always_comb
	
	
	I really don't think that variables are the appropriate way of
modeling tri-state busses.
	Wires are much better for this. 
	 
	You wouldn't use a unresolved wire to model a tri-state bus, why
try to use a variable?


________________________________

		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