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

  

Well, this has certainly been an interesting discussion. I seem to have
really stirred something up.

There have been so many mails on this that I'm going to examine them one
by one. In responding to a few of them, I know I run the risk of
duplicating something which someone else already said, or saying
something that someone else has already refuted.

I was about to write the following:

"I now agree with Dave, at least partly. My reason is that if I have
variables in lower level modules which are wired together in a higher
level module, then there is a continuous assignment connecting each such
variable to the common wire. In that case, the wire and the variables
are separate entities, even though there are connections between them.
So it makes sense that the always_comb checks only within the module in
this case and there is no problem."

That's what I was about to write.

Then I got to thinking. The following is a little stream of
consciousness, and may not seem very coherent.  

Maybe the reg in the module is treated as a wire, which was largely the
intent of SV's allowing variables to be treated as wires. If so, can
port collapsing occur? Port collapsing is not mentioned at all in 1800.
What about if I really use the reg like a wire, e.g,. not in an
always_comb block, but rather in a continuous assignment? Is port
collapsing allowed? If not (since the LRM does not say it is allowed),
that could be an inefficiency relative to a port collapsed wire.

Another question I have goes back to the original example, "always @*
sig = cond1 ? in1 : 1'bz ;".

The LRM says that software tools can (probably should be "may") check
whether the process really represents combinational logic. The question
is, does such code represent combinational logic or not? It is clearly
not a flip-flop or a latch, but is it combinational?

Thanks for putting up with my meanderings.

Shalom

 

________________________________

From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Monday, December 05, 2005 8:52 AM
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