Subject: Re: Please vote yes - 1364.1 ballot
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Jun 12 2002 - 17:39:31 PDT
At 03:22 PM 6/12/02 -0700, Jim Lewis wrote:
>Cliff,
> One thing I would like to see change with the IEEE ballot process
>is to make ballot comments public so if other people agree, they can
>reinforce the comments the other balloters have made.
I don't even get to see the comments until after balloting is complete.
>Or after the
>initial ballot, the comments and responses become public and a person
>is permitted to change their ballot based on the comment and resolution
>of someone elses vote.
As a Verilog Synthesis standards group, we have to respond to all comments
and then send out for re-balloting. I don't remember if the IEEE requires
all received comments be sent or just the changes made. I think it is just
the latter. Considering how hard it is to address all comments from both
yes and no ballots, I'm really quite glad that we do not have to send the
comments to all balloters to try to explain what we did and why we did it,
rehashing what the committee spent a lot of time addressing. If we had to
please all non-participant balloters, it would take an even longer-forever
to get an IEEE document passed.
> I have the following issue with 1364.1. If there is one place
>that Verilog and VHDL should agree, it should be on the naming of
>the synthesis attributes (at least those are similar or overlapping
>in meaning). The benefit will be a large for those who use both
>languages in their design flow. To make this happen, a coordinated
>effort is required.
Understood, it would be nice, but considering other language points where
Verilog and VHDL disagree, I think a combined committee would spend more
time deadlocked than making progress. I know the first proposal called for
"rtl_synthesis" as part of the attribute, which I considered unnecessarily
verbose. We finally shortened the attribute name to "synthesis." We also
queried multiple synthesis vendors to find out what pragmas they were
currently using and we took a somewhat common subset to standardize. As you
know, creating a standard is just half the battle. Getting vendors to
implement it is the other two-thirds (new math ;-)
The new attributes take advantage of the new Verilog-2001 attribute syntax,
which removes the requirement to parse comments to find attributes. Some
attributes do not make sense for VHDL (full_case & parallel_case) and other
attributes were eliminated in favor of Verilog's ability to do conditional
compilation (`ifdef SYNTHESIS). Verilog has an initial block and a
$readmemb command that were considered when modeling ROMs. When we added
configurations to Verilog-2001, Cadence specifically requested that the new
keywords NOT match the VHDL configuration keywords to make it easier for
tools to identify which blocks of code were VHDL and which were Verilog.
When I do state machine designs, my next state identifier is called "next"
even though it is a VHDL keyword (I don't feel like putting the more
verbose next_state throughout my FSM designs).
In Janick's book on testbench writing, page 332, Janick argues that
identifiers should be chosen to avoid keywords of popular languages such as
"C, C++, Verilog, VHDL, PERL, VERA, and e." I think this is way
over-planning, methodology overkill, and a waste of time.
> Hence, I have voted no (with comments) and requested that both
>groups get together and find a common set of attributes. I am not
>saying one or the other group is right, I am just saying both groups
>should have a say in this.
I disagree. I do not want to start proposing Verilog enhancements only
after consulting with VHDL committees. VHDL committee members did
participate on the Verilog language and synthesis committees and their
participation proved valuable. The reason we changed "rtl_synthesis" to
just "synthesis" is because the attributes we defined would most likely be
needed in both RTL and behavioral synthesis. Asking users to included
multiples of the same attribute to indicate that RTL and behavioral
synthesis tools should do the same thing seemed ridiculous. We determined
that any synthesis attribute that was unique to behavioral synthesis could
be added later as a beh_synthesis attribute (or something like it).
The languages are already very different and I doubt the VHDL synthesis
group would favorably consider changing the attribute names that were
selected for the VHDL standard and I don't like the argument that "the VHDL
names were here first." The Verilog synthesis group spent a lot of time
with vendors to select the attribute names that we chose. Our primary goal
was to satisfy Verilog users and Verilog synthesis vendors.
>Cheers,
>Jim
I hope I can change your vote to a "YES" vote after the committee responds
to comments.
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, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Wed Jun 12 2002 - 17:49:50 PDT