Re: DataTypes - Please vote no

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Nov 22 2004 - 18:23:32 PST

  • Next message: Kathy McKinley: "Re: DataTypes - Please vote no"

    Hi, Steve -

    Also good discussion by Wolfgang, Francoise and Alec. So far, I believe the
    discussion is very well reasoned and non-emotional. Differences of opinion
    will arise. More discussion below.

    At 03:50 PM 11/22/2004, Steven Sharp wrote:
    >Cliff,
    >
    >You have described an enhancement you would like to the language. This
    >proposal does not provide that enhancement, and was not intended to. You
    >are suggesting that is a reason to vote against this proposal.

    True.

    >None of the other proposals that have been made to the BC have provided
    >that enhancement either, and were not intended to. And yet you have never
    >suggested that as a reason for voting against them.

    Also true, but the other proposals were not as closely related to this
    proposal.

    >This proposal does not conflict in any way with your desired proposal. In
    >fact, it removes one of the differences between variables and nets in
    >SystemVerilog, which brings us one step closer to what you have said you
    >wanted. The fact that it is a smaller step than you wanted is not a good
    >reason to reject that advance.

    I disagree. The further we move in the direction of the datatypes proposal,
    the harder it becomes (or the less likely anyone will be interested in) to
    make the important changes that I, and other hardware engineers have been
    requesting for years.

    I will try to find time in the next few days to put together a number of
    annoying examples made necessary by the declaration distinction between
    nets and variables.

    My earlier statement was misinterpreted:
    "VHDL does not force net/variable distinctions. Verilog should not force
    them either."

    My statement should have been:
    "VHDL does not force Verilog-like-net/Verilog-like-variable distinctions."

    Having done ASIC design in both Verilog and VHDL, I was referring to the
    fact that VHDL engineers can declare a signal and make either process or
    concurrent signal assignments to the same signal (within the bounds
    resolved and unresolved rules) without any declaration change.

    I have found almost equally split recommendations regarding the use of VHDL
    variables in RTL coding among my VHDL colleagues. Some say to avoid them
    and only use signals, while others say to use them for
    simulation-efficiency reasons within a process. I was not trying to comment
    on VHDL variables. I was referring more to VHDL signals (resolved or
    unresolved).

    I find that new and self-taught Verilog users find two Verilog semantics to
    be confusing: (1) nets -vs- regs, and (2) blocking -vs- nonblocking
    assignments. We can fix the first issue very easily with what I have proposed.

    Whenever I teach a Verilog class to a group of strong VHDL coders, the VHDL
    engineers ask why they had to change the declaration when they moved the
    LHS continuous assignment variable into a procedural block LHS assignment.
    They ask what value was there in the language forced by the declaration
    change. I always answer, it is just a silly rule of the Verilog language.

    Alec pointed out that if tools could figure out which is which but that the
    semantics would have to be explained. Alec is right, but I have to do this
    anyway. Engineers have to understand that continuous assignments, etc. are
    all driver assignments, equivalent to VHDL std_logic. Procedural
    assignments are behavioral assignments and last assignment wins. For
    SystemVerilog, logic & bit-type assignments allow either one driver or one
    procedural-source assignment like VHDL std_ulogic. The point is, engineers
    already have to understand the driver-or-behavioral assignment nature to do
    good RTL coding. The added annoyance of changing declarations does not add
    value. I would disagree with Alec that reg/wire declarations make the code
    more readable. The only real beneficiary seems to be the EDA tool software
    engineers (they can determine object semantics before it is used).

    The other difference between VHDL and my proposal is that VHDL processes
    actually do create drivers onto std_logic signals and can be combined with
    other concurrent assignments to the same signal. Under my proposal, Verilog
    would not allow procedural blocks and continuous assignments, etc., to
    drive a common wire. I actually like this distinction better than the
    VHDL-way, but that is just personal preference.

    Occasionally, I find engineers that want the ulogic testing addressed by
    SystemVerilog and I believe further enhanced within the datatypes proposal,
    but in reality, most hardware engineers could care less. Why? Because there
    is no such thing as ulogic hardware. All real hardware-outputs resolve, but
    I acknowledge that having the datatype for checking for multiple drivers is
    useful.

    The reg/wire declaration requirements are completely foreign to hardware
    engineers, which is why they are so confusing to new and self-taught
    Verilog engineers. Every error message on this subject is rather foreign to
    hardware engineers: "illegal left-hand-side assignment," illegal assignment
    to wire," "illegal lvalue assignment." I tell engineers to get used to
    these messages because they going to see them a lot. I tell them the
    message should really say, "you made an illegal assignment to a Verilog
    net-type. Did you forget to declare a reg-variable for the variable xxx on
    line ##?"

    The point I want to make is that the datatypes proposal addresses
    interesting and sometimes useful datakind and datatype side-issues, while
    completely ignoring the larger issue. I compare this to choking on a peanut
    while swallowing an elephant without complaint.

    For this reason, I encourage a no-vote on the datatypes enhancements unless
    they incorporate the larger issue of silly declaration requirements.

    I personally think adapting the datatypes proposal to commonly declared
    net-types that are automatically recognized by tools as either driver-type
    or procedural-type variables would further simplify some of the exceptions
    that currently are in the datatypes proposal.

    I think there is a good reason to vote no to a partial and perhaps
    debilitating solution. Passing this proposal without addressing the net-reg
    issue could make the latter much more difficult to fix at a later date.

    >Steven Sharp
    >sharp@cadence.com

    As one of President Clinton's Impeachment Trial Lawyers so famously stated,
    "reasonable people can disagree!"

    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 2.1.4 : Mon Nov 22 2004 - 18:13:19 PST and
    sponsored by Boyd Technology, Inc.