Subject: Re: Brainstorming VHDL 200x
From: Stephen Bailey (sbailey@synopsys.com)
Date: Wed Apr 19 2000 - 05:59:52 PDT
Evan,
> Stephen Bailey wrote:
>
> > 1. As stated in the context setting message. Gate level verification
> > remains an "achilles heel" of VHDL...
>
> This may be heresy, but I don't think that this issue is quite this
> important. Why?
>
> 1) The industry seems to be moving towards RTL sign-off, possibly with
> equivalency checking.
If there is something we can do in the VASG to accelerate RTL sign-off, then
THAT IS A WAY TO NEUTRALIZE the advantage! Unfortunately, this is not
happening fast enough. Why and What we can do to accelerate it (if
anything) are excellent topics for discussion under this category.
> 2) How many people actually do significant gate-level sims? I suspect
> that a lot of people just do very limited testing, ...
As long as people (at least a significant percentage of the market) need to
do gate-level sim for any reason under the current language status quo, it
is a negative for VHDL because Verilog is much better at this task.
> > 2. Neutralizing our current competitive disadvantage with Verilog in
> > designer productivity at the RT/synthesizable level of design is closely
> > related to the 3rd category. ...
> >
> > 3. I believe that designer productivity is the only factor of
importance.
> > Designer productivity has many perspectives (tool performance, number of
> > keystrokes and correct-by-construction are 3 major ones).
>
> This may again be heresy, but I don't think that raw designer
> productivity is an issue. It looks bad when a competition demonstrates
> that designer X can code up a module in Verilog faster than designer Y
> can do it in VHDL, but it wouldn't surprise me if someone also ran these
> contests with Basic and C 20 years ago - with the unsurprising answer
> that you can code up something simple in Basic faster than you can do it
> in C.
You have decided to define designer productivity far narrower than I would.
However, within the complete context of designer productivity, our greatest
impact is HDL coding, verification and synthesis. We are dealing with the
VHDL language and cannot impact (directly) much beyond that.
> Second: just how much of the design process is taken up with RTL coding
> anyway? In my case, less than 10%. The rest of the process is far more
> time-consuming: defining specifications and architectures, correcting
> and iterating them, making sure procedures are adhered to, going to
> numerous meetings, developing an abstract version of the design, doing
> the back-end work, and so on. At the end of the day, it simply doesn't
> matter that it may take me an extra week to code up my RTL bits in VHDL
> compared to Verilog. I could even do it in schematics, and it's unlikely
> that anyone would notice the effect on the timescales.
But, HDL productivity is virtually all we are concerned with inside VASG.
More accurately stated, we are concerned with how HDL improves productivity
in an HDL-based design flow. All those other "pie chart" areas fall outside
the realm of this working group unless there is some way that we can modify
VHDL to improve them. If you have suggestions, that's what this
brainstorming process is all about.
Look at the Verilog 2000 language changes. Virtually every one of the
changes has a direct correspondence to reducing the amount of time it should
take a designer to write an RTL description. If HDL coding productivity
isn't important to the Verilog community, then why change Verilog?
-Steve Bailey
This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 06:32:04 PDT