From: Dennis Marsa (drm@xilinx.com)
Date: Fri Feb 01 2002 - 16:07:12 PST
Precedence: bulk
Paul Graham wrote:
>
> Funny how a construct designed to make things easier just causes more
> problems :-)
Funny till one tries to implement it. ;-)
> I got the impression that @* was intended as a quick and easy way to model
> combinational logic using an always block, without having to tediously
> verify that every signal in the block was included in the sensitivity list.
Yes. Except those signals can be bit/part/array selects, and nothing is
said about the semantics of @(*) in the presence of those kinds of signal
references.
> You might want @* to be able to represent anything which is representable by
> an explicit sensitivity list, but I think it is better to confine @* to
> simpler cases. For instance:
>
> always @(x+y)
> z = x+y;
>
> is perfectly legal verilog, but I'm sure we can agree that this can't be
> modeled using @*.
Absolutely. They way I read section 9.7.5 regarding @(*), it seems pretty
clear to me that always @(x+y) can't be modelled with @(*).
> So we could make some simplifying rules. For instance, @* cannot refer to a
> variable declared within the statement that it controls. Maybe @* should
> cause an error if used in this situation. Again, because of the concern
> over simulation efficiency, and other problems, @* cannot refer to an array.
Yes, in the absense of any concrete guidance from the standard, I am trying to
come up with reasonable rules for how to interpret @(*) in the presense of
bit/part/array select operations. I'm fairly comfortable with how to proceed
with bit/part selects, but array selects are still mystifying me.
I was hoping to get some guidance from the group, but there doesn't seem to be
a clear consensus of the best way to go.
Dennis
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:35 PDT
and
sponsored by Boyd Technology, Inc.