From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Jan 26 1999 - 09:39:52 PST
BAD MSG:
I have copied Drew, Stu and Tom to this e-mail discussion about
onfigurations. If you think anyone else on the VSG would contribute to
this discussion, please feel free to forward these comments to them.
X-Lines: 129
Content-Type: text/plain; charset="us-ascii"
Content-Length: 6437
X-Status: $$$$
X-UID: 0000000825
Status: RO
>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 //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.