Subject: Re: [sv-bc] Re: SystemVerilog: "logic" or "ulogic?" - user input
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Sep 17 2003 - 11:34:04 PDT
Hi, Jonathan -
Thanks for the feedback. All feedback pro and con is welcome.
At 06:41 PM 9/17/03 +0100, Jonathan Bromley wrote:
>(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.
As you note later, we now have the ability to make single continuous or
instance-driven assignments to variables, including logic and bit.
This means that if you want to design with all unresolved signals and have
the compiler check to see if you have made a mistake, the logic (4-state)
and bit (2-state) types can be used as your near-universal data types. This
was very important to Intel, as they discussed in their DAC 2003 presentation.
I think you also allude to the fact that SV does not have equivalent
resolved types (one reason for objecting to tying SV and VHDL data types
together by comparison?). This is true. I would like to have equivalent
4-state and 2-state resolved types in SV, but unlike VHDL, I would like to
prohibit continuous (VHDL-concurrent signal assignments) and procedural
(VHDL-process assignments) assignments to the same resolved variable. If we
permitted procedural assignments to wires (I know - I have been out-voted
on this many times!) we would have the 4-state resolved type, and would
just be missing the 2-state resolved type.
Intel engineers have suggested that it would be useful to add the
capability to define 2-state Z and X conversions separately, so that
2-state simulations could be done with ZX=00, ZX=01, ZX=10 and ZX=11. This
would allow for some very good 2-state testing. I like the idea.
It would be so useful to do a resolved data type design (one that uses
tri-states) and quickly switch the typdefs to unresolved types to find all
of the tri-state busses and to do a quick lint-check to find any unintended
resolved assignments.
> > 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.
I was trying to realign the axes to be backward compatible with existing
Verilog designs while removing the all-too-confusing net-vs-variable issues
in Verilog.
>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.
Compared to logic and bit, I think most of the new SV keywords are not
going to be nearly as noisey!
Thanks for weighing in on this debate. I am interested in more user feedback.
>--
>Jonathan Bromley, Consultant
>
>DOULOS - 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.
Regards - Cliff
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Wed Sep 17 2003 - 11:37:24 PDT