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

At 01:32 PM 4/21/2005, Michael McNamara wrote:
>-- 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 :-)

Uh oh, I think my friend Mac is dangerously close to seconding my 
motion    ;-)   ;-)

... (more Cliff-dribble) ...

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

Agreed. We should follow the process. My admitting to where the problem 
originated and by providing historical background information, I hoped to 
show strong support for the original intent.

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

It is indeed part of the intent.

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

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.

We can respond to comments and propose other changes that promote further 
"consensus." Most of the configs clarification may not promote consensus 
and we may want to just fix the obvious typos (if we can agree to the 
typos) and leave the rest for future clarification. Anything we change in 
the LRMs is free-game for additional negative comment in the next vote, 
which is why we only want to consider changes that promote consensus within 
the ballot group (fortunately we can take a straw poll with the ballot 
group to see if anyone will complain with a negative vote if we add certain 
"clarifications").

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

A good point. Like I mentioned before, we previously had they keywords 
separated but it was implementers that scoffed at context-sensitive 
keywords. As a user, as long as config, endconfig and library are keywords 
in the Verilog input stream, and as long as I don't have to use switches to 
get to config files (and maybe library files), I don't mind 
context-sensitive keywords (the job is always easiest for the person who 
does not have to do it!)

Randy even suggested this compromise, even though it gets messy and it is 
not his first choice.

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

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