IMO it would be a bad idea to change how this stuff works without
considering the impact on mixed signal extensions. If you want to
propose different syntax/semantics for reg/wire, try including the use
of drivers (and receivers) of different types (other than logic) in the
same module and how resolution will work.
From the perspective of low-level gate and transistor modeling VHDL is
badly broken, I wouldn't like to see the same semantics turn up in Verilog.
Kev.
Clifford E. Cummings wrote:
> Hi, Kathy -
>
> Apologies for the late reply. I have been on the road 9 of the past 10
> weeks and most of those weeks I have had to listen to engineers
> complain about reg-wire declarations.
>
> At 08:22 PM 11/22/2004, Kathy McKinley wrote:
>
>> Hello Cliff,
>>
>> I found your last explanation to be very helpful. You are referring
>> to the fact that VHDL has both sequential signal assignment statements
>> and concurrent signal assignment statements. That is, in VHDL you can
>> update a signal from either a concurrent context or a behavioral block
>> (a process). Is this the enhancement that you seek in Verilog?
>
>
> Not quite. What I am requesting is a little different than what VHDL
> does. In VHDL. a concurrent signal assignment is just a shorthand for
> a process. In Verilog, a continuous assignment is a driver-assignment
> while an always block is a last-assignment-wins procedural assignment.
> I don't want the Verilog behavior to change. I just don't want to
> change the declaration every time I move assignments from procedural
> blocks to continuous assignments and back.
>
> I had a chance to ask Phil Moorby why he made the reg-wire distinction
> when he invented Verilog. Phil's response was when he invented
> Verilog, there were no synthesis tools and he really thought always
> blocks would be used to only build clocked logic. Phil put together a
> great language, but it is time to fix this mistake.
>
> What I (and most engineers want) is the ability to declare everything
> as a wire or wire bus and have first-usage determine if the behavior
> should follow existing procedural assignment rules or existing
> net-driver rules. I want absolutely no Verilog-behavior change, I only
> want declaration changes. Logic accomplishes this goal for unresolved
> types, I believe wire could solve the goal for resolved types. This is
> still fully backward compatible (you can declare the regs if you want
> to).
>
> Most of what RTL designers do with Verilog really does not include the
> need for the datatypes proposal. I am actually not completely against
> the proposal, if it would fix this major annoyance first.
>
>> I believe that the introduction of a VHDL-like sequential signal
>> assignment statement would be an enhancement to the execution
>> semantics of Verilog. I also believe that such an enhancement
>> is orthogonal to the data types on nets extension.
>
>
> Actually I do not want execution semantics changes. Just allow
> engineers to declare everything as net types and let the tool find
> first usage to determine semantics (and make the semantics equivalent
> to current Verilog behavior).
>
> I first addressed this proposal in Veirlog-2001 and was voted down (my
> proposal was not well formed). I later did a paper at HDLCON 2000 that
> did a better job of explaining the proposal, and some committee
> members said they understood the problem, but it was too late to make
> LRM changes. (See
> http://www.sunburst-design.com/papers/CummingsHDLCON2000_RegProposal_rev1_1.pdf
> )
>
>> The data types on nets extension is concerned with what values
>> a net can assume. For example, can a net take on values of an
>> enumeration data type or a packed struct data type? If so, how
>> does one specify that data type in the declaration of the net?
>> Are there any data types that are not allowed? For example, can
>> a net be declared to be of a class data type? These are the sort
>> of questions that the "data types on nets" proposal addresses.
>
>
> And all of this is good, if it would also fix the more glaring problem
> found by every RTL designer I teach.
>
>> As others observed earlier, the data types on nets extension does
>> not preclude an extension to the update semantics of Verilog.
>
>
> I am not convinced this is true. If we do not address this issue along
> with the datatypes proposal, we may find it impossible to make this
> change later; hence, my strong opposition to the datatypes proposal in
> its current form. I am also not convinced that power-2-state
> techniques, like those used by Lionel Bening of HP for the past ten
> years (described in our SNUG-Boston-2004 paper - also on my web sight)
> can be implemented if the 4-state proposals are not careful enough.
>
> If we don't address this problem at the same time as the datatypes
> proposal, I don't think committee members will take time to consider
> it in the future. I have been fighting this battle for some six years
> now, and unfortunately, most of the datatypes work was done on a day
> that frequently finds me teaching at a customer site.
>
> Karen Pieper expressed her objection to Stu's `verilog_1995
> `verilog_1995_off (exact compiler directive keywords are not accurate)
> proposal because nobody had implemented it. Stu's `on-`off compiler
> directives proposal pales in scope and comparison to the changes
> proposed by the unimplemented datatypes proposal.
>
>> In fact, the proposal explicitly states that the update semantics
>> are not modified. We tried very hard to adhere to the scope that
>> was endorsed at the p1800 working group level.
>
>
> I do not want modified semantics. Just relaxed and sane declarations.
>
>> It is worth noting that data type orthogonality is an important
>> language design principle for VHDL. The VHDL signal assignment
>> semantics are not based on the values that VHDL signals can have.
>> VHDL supports a richer set of data types for its signals, and we
>> are trying to do something similar for Verilog.
>
>
> A worthy goal. If it simultaneously fixes the biggest complaint that I
> hear from VHDL users (no value in changing net-variable declarations
> just because an assignment was moved to a different place in the
> code), and from Verilog users, then I could support it.
>
> I will still try to put together more examples that show the painful
> side effects of the reg-wire declaration distinctions by the P1800
> meeting for Wednesday.
>
>> Kathy
>>
>> >Date: Mon, 22 Nov 2004 18:23:32 -0800
>> >To: sv-bc@eda.org, btf-dtype@boyd.com
>> >From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>> >Subject: [sv-bc] 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
>
>
>
Received on Tue Dec 14 10:31:25 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 14 2004 - 10:31:28 PST