Subject: [sv-bc] Re: SystemVerilog: "logic" or "ulogic?" - user input
From: Jonathan Bromley (jonathan.bromley@doulos.com)
Date: Wed Sep 17 2003 - 10:41:52 PDT
(Posted to both comp.lang.vhdl and sv-bc mailing list)
"Cliff Cummings" <cliffc@sunburst-design.com> wrote in
message news:7788812d.0309161048.4d0ca950@posting.google.com...
> Two data types have been added to the SystemVerilog language: "logic"
> and "bit."
> The new types are actually unresolved types (similar to the VHDL
> std_ulogic_type) and are called "logic" (4-state type) and "bit"
> (2-state type).
Hang on a minute there! _logic_ and _bit_ in SV are not in any
real sense "unresolved" types - they're variables! Just because
they can be used in a rather similar way in hardware designs
doesn't make them the same.
> I believe we would be doing the Verilog and VHDL communities a favor
> by at least choosing the more VHDL-like keywords: ulogic & ubit.
I disagree. Any attempt to align SV type names with VHDL could
sow the seeds of massive confusion. SV divides its data types
along an entirely different axis than does VHDL.
SV introduces the ability to use a variable as the target of
a continuous assignment (explicitly with _assign_ or implicitly
across a port). When used in this way, variables of any type
behave somewhat like VHDL unresolved signals. When NOT used
in this way, however, SV variables have the semantics of
traditional Verilog variables, which is entirely different.
Thus, SV variables gain or lose "VHDL unresolved" status
depending on how they're used. This is why I would be very
unhappy to see any attempt to make them into ersatz VHDL
types by choice of name.
> I am also guessing that "ulogic" will kill fewer existing designs than
> "logic" (same argument for "ubit" vs. "bit"). I also like the
> VHDL-like "u" to indicate "unresolved."
Once again I disagree. Compilers will have no trouble identifying
abuse of a keyword in existing designs. As a user switching from
Verilog to SV I would be prepared to accept, as a price of change,
the kind of "brokenness" that is easily and explicitly identified
by the first pass of a compiler, and won't compile at all. It's
far better than silent brokenness that compiles happily but delivers
silly results; and it's easy to fix.
There are so many new keywords in SV anyway, that this issue is
down in the noise. I'm sure someone will come up with a preprocessor
that will hunt down any SV keywords in existing Verilog designs
and flag them, so that they can be decorated somehow to avoid clashes.
-- Jonathan Bromley, ConsultantDOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
This archive was generated by hypermail 2b28 : Wed Sep 17 2003 - 10:46:39 PDT