From: Stuart Sutherland (stuart@sutherland.com)
Date: Tue Jan 26 1999 - 10:01:07 PST
BAD MSG:
All,
-Lines: 186
Content-Type: text/plain; charset="us-ascii"
Content-Length: 9127
X-Status: $$$$
X-UID: 0000000826
Status: RO
Here's my $.02:
First and foremost, I think that configuration capability is essential in
the Verilog language. This enhancement needs to get done.
Most of the time, all I want for configurations is the equivalent of a
basic Honda Civic. I have no objects to also having a fully loaded Chevy
Suburban sitting in the driveway for occasional use. But the civic needs
to be readily available without having to move the Suburban out of the way
each time.
Tom says his proposal meets that need. I disagree. I cannot make heads or
tails out of ANY AND ALL examples that have been passed around the past few
months (I'm on the BTF reflector, and I do look at the messages). Perhaps
it is just the way the configuration descriptions and examples have been
presented. But to me, that &#^$(* Suburban is blocking my way. As the
proposals stand today, I would not use configurations, and I would not
recommend them to my consulting customers or training clients.
I am hoping to see, very soon, a clear description of how Tom's
configurations can be used in everyday use. Maybe, just maybe, a final
example of using configurations to solve the world's problems can also be
included at the end of the description. But I think anything beyond the
KISS (keep it simple stupid) level of examples in the proposed LRM chapter
will kill the proposal. Let the advanced user build from syntax and the
simple examples to solve his specific larger configuration needs.
I regards to the PLI, I do not think any type of configuration proposal
will impact the PLI routines for the 1999 standard. The PLI specifically
states it works with an "instantiated simulation data structure". Most of
what the PLI does, occurs after the compiler/elaborator has read in the
Verilog source code. Configurations is just controlling what source code
is read in.
Just my opinion...
Stu
<p>At 09:39 AM 1/26/99, Clifford E. Cummings wrote:
>I have copied Drew, Stu and Tom to this e-mail discussion about
>configurations. If you think anyone else on the VSG would contribute to
>this discussion, please feel free to forward these comments to them.
>
>>From: Adam Krolnik <adamk@cyrix.com>
>>Subject: Re: BTF - Cliff's Priorities for Configurations
>>To: cliffc@sunburst-design.com
>>
>>Hi Cliff, Stefen
>>
>>Could either of you describe the reception of the configuration stuff
>>by the committee?
>>
>>Cliff, Reading your 'priorities' for configurations it is unclear when you
>>don't like the proposal and when you do like it.
>>
>>E.g. #4 - maintaining -y, -v, etc.
>>
>>The proposal pretty much provides equivalent functionality for
>>these (except maybe +libext since it's provided with wildcard expansion.)
>>
>> Adam Krolnik
>
>Perhaps my e-mail was not very clear. From Tom's progressive example, I
>like most of what I see in the library section. I believe it does cover -v,
>-y and +libext much better than the current command line switches. Because
>of the use of wildcard expressions, I believe the "file" and "dir" keywords
>are not necessary. I like the wildcards!
>
>I do not like the complexity of configurations and I am still not crazy
>about views. My memory differs from Tom's as pertaining to objections to
>the term view. I believe people did not like the name. Tom believes people
>did not like the name because they thought "view" was already being used by
>Verilog-AMS. I would like to see views adopted only after users show their
>interest in the capability (which I think could happen). I would like to
>see engineers coding with views, not just Cadence schematics that compiled
>to view-based Verilog code. The latter suggests that we have modified the
>Verilog standard to accommodate Cadence design flows.
>
>I like the idea of inheritance (that was part of every configuration
>proposal we made), but I believe many of the other switches being proposed
>add unnecessary complexity to standard Verilog. I am sure that they are
>important to Cadence design flows, but I do not want to standardize Cadence
>design flows.
>
>I don't like the keyword "path" to indicate the path for an individual
>instance. I prefer "instance", but I could live with either.
>
>>Date: Mon, 25 Jan 1999 15:56:54 -0800
>>To: Adam Krolnik <adamk@cyrix.com>, cliffc@sunburst-design.com
>>From: Stefen Boyd <stefen@boyd.com>
>>Subject: Re: BTF - Cliff's Priorities for Configurations
>>
>>At 04:24 PM 1/25/99 -0600, Adam Krolnik wrote:
>>>Could either of you describe the reception of the configuration stuff
>>>by the committee?
>>
>>I would say that generally, the only ones who feel
>>passionate about configurations are involved in the btf.
>>For the most part, everyone wants configs and it looks
>>like if we can just get a proposal that the btf can
>>stand behind (with all the holes plugged), the rest of
>>the VSG will pass it. It makes me think of generate. We
>>sweat out so many details that by the time we sent our
>>"rough" proposal to the VSG it was passed almost without
>>comment.
>
>After working a full year on a configuration proposal, the proposal that
>the BTF floated to the VSG in December 1997 handled configurations by
>standardizing the -f, -v, -y and +libext command-line switches, and then
>added a couple more to use individual files for specific instances. Drew
>and Stu said they would vote against the IEEE spec if we passed these
>enhancements, so we abandoned the command-line switch approach and started
>down the path to config-endconfig / library-endlibrary proposal.
>
>I believe buy-in by both Drew and Stu are key to passing a configuration
>proposal, especially since I do not support the configuration proposal in
>its current complex form.
>
>>Maq likes the idea that we will have it implemented by
>>Cadence before it's even out to ballot. Since what
>>Cadence will do here is bound to become another defacto
>>standard, I would like to see our focus be on making
>>the small subset of functionality that meets 99% of
>>current user needs be *very* easy to identify and use.
>>Even if there is a lot of extra complexity that might
>>get used eventually, making the useful stuff jump out
>>of the spec and *simple* to use means it will get used.
>>
>>The reason to allow the extra complex stuff is simple.
>>If it's likely to become a defacto standard, why not
>>influence it with some sanity! `uselib was an ugly
>>hack that didn't deserve to live, but because it was the
>>only "standard" way out there to solve some problems,
>>other vendors (VCS) had to live with it. Let's try
>>to take advantage of our ability to influence Cadence
>>(even if you want to vote against it in the end).
>
>I agree that the `uselib hack is ugly. It has become a defacto standard (a
>rarely used defacto standard) because Cadence added it to their design
>flow. I fully expect `uselib to die a quick death if/when a reasonable
>alternative is standardized. Because we did not standardize `uselib, it
>should eventually die out altogether.
>
>This is the same reason we have chosen not to standardize the -v, -y and
>+libext switches, because once a reasonable replacement is in place, we
>fully expect the use of these switches to disappear (I anticipate writing
>some Perl script in the future that converts current command files into the
>new Verilog configuration syntax, then present the script at a conference).
>
>Where we disagree is on the "sanity" of the "complex stuff". We have taken
>what was a rather simple enhancement idea, and by committee, have decided
>to propose an elaborate solution to a simple problem. If the complex
>solution is standardized, we will never be able to remove it from the
>language. If in the future we discover a simple, elegant and better way to
>enhance configuration control using Verilog, we will be saddled with our
>current proposal. I believe we should pass a simple enhancement, based on
>Tom's proposal, allow Cadence to implement their full enhancement, and see
>which ideas find acceptance among the user community. Then we can
>standardize the user-accepted enhancements in a Verilog 2002 LRM.
>
>>Stefen
>
>Regards - Cliff
>
>//********************************************************************//
>// Cliff Cummings E-mail: cliffc@sunburst-design.com //
>// Sunburst Design, Inc. Phone: 503-579-6362 / FAX: 503-579-7631 //
>// 15870 SW Breccia Dr., Beaverton, OR 97007 //
>// //
>// Verilog & Synthesis Training //
>// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
>//********************************************************************//
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland.com
Specializing in Verilog HDL consulting and training.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.