SystemVerilog: "logic" or "ulogic?"

[Cliff Cummings]

Hi, All -

Request for user feedback.

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).

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 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."

Unfortunately, the Accellera SystemVerilog committees are mostly
staffed by EDA vendors who do not want to change the keywords as they
are currently defined in the SystemVerilog 3.0 & 3.1 standards.

I have been given the chance to solicit user input one more time
before this issue is dismissed.

If you have an opinion one way or the other, please send an email
message to the:

SystemVerilog Design Committee ( (e-mail address removed) )
with the Subject: logic -vs- ulogic - user input

And voice your opinion that either "logic" and "bit" should keep the
current keywords, or
"logic" and "bit" should be changed to the more VHDL-compatible names
of "ulogic" and "ubit."

I really would like more user feedback before we cast this in stone in
SystemVerilog.

Thanks in advance to anyone who responds.

Regards - Cliff Cummings

 

[Egbert Molenkamp]

Hi, All -

Request for user feedback.

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).

I believe we would be doing the Verilog and VHDL communities a favor
by at least choosing the more VHDL-like keywords: ulogic & ubit.

But in VHDL type bit is an unresolved type!
So only need a change from 'logic' in 'ulogic' is sufficient from a VHDL
point of view.

Egbert Molenkamp

 

[Mike Treseler]

But in VHDL type bit is an unresolved type!
So only need a change from 'logic' in 'ulogic' is sufficient from a VHDL
point of view.

I agree.

The larger problem is that SystemVerilog "types"
cannot be applied to wires (signals).

-- Mike Treseler

 

[Jonathan Bromley]

(Posted to both comp.lang.vhdl and sv-bc mailing list)

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, 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: (e-mail address removed)
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.

 

[Cliff Cummings]

But in VHDL type bit is an unresolved type!
So only need a change from 'logic' in 'ulogic' is sufficient from a VHDL
point of view.

Egbert Molenkamp

Bummer! You're right!

I still like the idea of having ulogic and ubit to be new unresolved
types in SystemVerilog (I think it would break fewer existing Verilog
designs), but if you would prefer ulogic and bit, please email your
preference to:

SystemVerilog Design Committee ( (e-mail address removed) )
with the Subject: logic -vs- ulogic - user input

Again, I would like more user input passed to the Accellera
committees.

Side-note: My limited VHDL experience has been that most VHDL
designers do not use the bit-type. Is this true?

Regards - Cliff Cummings

 

[Mike Treseler]

Side-note: My limited VHDL experience has been that most VHDL
designers do not use the bit-type. Is this true?

I think so.
std_logic_vector and unsigned
are much more common.

-- Mike Treseler

 

[Cliff Cummings]

Hi, Jonathan -

Thanks for the feedback. All feedback pro and con is welcome.

(Posted to both comp.lang.vhdl and sv-bc mailing list)



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 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.



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: (e-mail address removed)
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

 

[cc0139808]

My 2c: if you use bit in a real chip, you will not propagate 'X', hence
you might have hard to debug mismatches between RTL and gates.
Yes, I know many people say "Silicon has only '0' or '1', does not have
'X'!", but you do your sign-off based on simulations, not on silicon.

Dan Ciobanu