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

  

That would not work for my synthesis tool. 

You can have two continuous assignments to a three-stated wire, but if
you use a variable, then you have to use a single always process.

That is one reason I did not choose that example.

Shalom

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Michael (Mac) McNamara
Sent: Monday, December 05, 2005 6:46 PM
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