RE: [sv-ec] Re: [sv-bc] potential command line option

-- On Apr 21 2005 at 10:54, Clifford E. Cummings sent a message:
 > To: btf@boyd.com, etf@boyd.com, sv-ec@eda.org
 > Subject: "[sv-ec] Re: [sv-bc] potential command line option"
 > Hi, All -
 > 
 > Thanks for additional comments from Mac and Randy.
 > 
 > Can we all just agree that Cliff was an idiot?! 

 Only if the motion is seconded, and passes the required vote :-)

 > And that I apparently I made mistakes in the BNF?
 > 
 > Our SystemVerilog and Verilog updates to the BNF have removed some of the 
 > complexity because committee members deemed it more appropriate to explain 
 > semantics as opposed to trying to enforce them with the BNF. Brad has done 
 > a fine job of making these modifications.
 > 
 > I believe this is one of those cases. We wanted to allow configs into the 
 > Verilog input stream, but we did not want them to include all of the module 
 > syntax, so I semi-listed them separately and then attempted to explain it 
 > in the Configurations section. Face it, just call Cliff and idiot and be 
 > done with it.
 > 
 > There were other errors in the BNF (hard to believe that Cliff had other 
 > errors in the BNF, huh?) but we never forced those errors to be part of the 
 > language and we did not require vendors to compile it both ways when the 
 > BNF did not match the text. I really cringe at the thought that vendors are 
 > going to accept some of the config statements with an optional ";" just 
 > because I screwed up in the BNF. It was a mistake - let's fix it. Add the 
 > semicolons and require them.
 > 
 > Attached is the Draft-4 Annex section for the P1364-Y2K. This was the last 
 > time we had the keywords separated for Verilog, Configurations and 
 > Libraries. Note that config-endconfig and library were in the Verilog 
 > keywords since they were intended to be read in the Verilog input stream.
 > 
 > I did originally have three separate keyword lists, but it was vendors (and 
 > I thought specifically Steve Sharp) that told me it was a dumb idea to have 
 > separate keyword lists, so I re-combined them into a single keyword list 
 > for Draft 5 and Draft 6 was the ballot version for Verilog-2001.
 > 
 > I believe the ModelSim implementation is what was intended.
 > 
 > Steve Sharp also sent a proposal to deprecate config statements from the 
 > keyword list. That is a proposal that I respectfully oppose. I like having 
 > configs and libraries in the input stream. I think we should fix the 
 > library-calling-config problem and keep the rest as intended.
 > 
 > Just call Cliff an idiot and let's fix the appropriate config documentation.
 > 
 > Regards - Cliff

You make a fine argument; but still we need to follow the process.

Your arguments in my mind stand on their own today and would perhaps
pass as a proposed revision to the standard, with dully considered
amendments.  All things being equal, I would rather we go this route
and consider the input from Cisco and Model Technology on their
implementations and their experience with this; and input from Cadence
and Synopsys on their thoughts and ideas.

By instead arguing that what is there was an error, or is ambiguous,
you (and Randy) do specifically bring such a change within the
permitted work under the current PAR
<http://standards.ieee.org/board/nes/projects/1364.pdf>; perhaps this
is your intent.

However, this current PAR has already passed its balloting, correct? 

I believe at this point all we can do is respond to negative comments,
(again is this correct?)  Can we make such a change without requiring
a new ballot round?  I do not know.


All these process questions aside, I have expressed my reservations
previously with the large number of keywords removed from the purvue
of the user by P1800. 

I am very sympathetic to anything we can do to stop the thievery!
As the Arnold says, "Close the borders!"

If we can make the interior of the configuration section have its own
name space, thereby not take "design", "instance", "cell", "use"
"liblist" and "include" from the set of legal names to use for a
variable, module or net in the rest of the design, that would be in my
mind a good thing.


-- 
Michael McNamara
Vice President, Verification Division, Cadence
E: mcnamara@cadence.com    M: 408-348-7025