Subject: RE: always_comb semantics
From: Steven Sharp (sharp@cadence.com)
Date: Wed Oct 02 2002 - 15:58:56 PDT
>Further, always_comb appears to be a simultaneous invention with
>1364-2001's always @(*) construct, and we (SV-BC) should consider
>dropping the System Verilog addition in favor of the existing always
>@(*) which is an IEEE standard.
Yep, I was planning on bringing up the same issue myself. This appears
to be parallel development of the same basic capability. The IEEE has
already standardized its solution. It's a little late for alternative
proposals.
>Note that always @(*) makes no restriction on other assignments to the
>lhs variables, as you seem to prefer.
This aspect of always_comb (and the other always_* constructs) is
effectively covered in IEEE 1364-2001 by the availability of attributes
for synthesis. This allows synthesis lint checking of this kind. It
also has the advantage of being more extensible and malleable as synthesis
tools and their restrictions change.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 16:07:00 PDT