Subject: Re: Brainstorming VHDL 200x
From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Mon Apr 03 2000 - 12:09:43 PDT
Here are my suggestions:
1. We should seriously look at a VHDL construct for the synthesis
compile on/off pragma. This way both simulators and synthesis tools
could understand the same construct. This issue falls into Steve's
Category 2.
2. How about allowing read-only references to signals deep in design
via hierarchical names? This will allow for verification tests to be written
in VHDL. Because of this problem today, verif engineers resort to writing in
C instead of VHDL. This issue falls into Steve's category 3.
- bhasker
> From owner-stds-vasg@ieee.org Mon Apr 3 09:01 EDT 2000
> From: "Stephen Bailey" <sbailey@synopsys.com>
> To: <stds-vasg@ieee.org>
> Subject: Brainstorming VHDL 200x
> Date: Sun, 26 Mar 2000 01:32:34 -0700
> Organization: Synopsys Inc.
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 5.00.2314.1300
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> Sender: owner-stds-vasg@ieee.org
> Reply-To: stds-vasg@ieee.org
> X-Resent-To: Multiple Recipients <stds-vasg@majordomo.ieee.org>
> X-Listname: stds-vasg
> X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org
> X-Moderator-Address: stds-vasg-approval@majordomo.ieee.org
> X-Received: By mailgate2.Cadence.COM as GAA16772 at Mon Apr 3 06:01:47 2000
>
>
> In my previous email, I attempted to set the current context that we find
> VHDL in relative to the competition. Although some people offerred some
> clarification or additional information, I do not recall any substantial
> disagreement with my statement of the context.
>
> I'd like to thank those who felt compelled to defend VHDL, in whatever way.
> I take it as an indication that they are compelled to defend because they
> truly care. This is a good sign. However, please try to keep in mind that,
> generally speaking, neither I nor members of this group are the ones who
> need to be convinced. (As the saying goes, you're preaching to the choir.)
>
> I think the next step in this effort is to perform some brainstorming. We
> need to get ideas: good, bad and ugly. Now is not the time to self-censor.
> The result of brainstorming is the gathering of as many solutions as
> possible. It is a separate activity to assess the cost and benefit of each
> possible solution.
>
> We also need to consider whether the 3 general categories for brainstorming
> are sufficient. I'd like to have the initial results of the brainstorming
> completed in time for the DAC VASG meeting (or at least that timeframe). I
> will investigate an alternative meeting format that would allow more to
> attend. More on that later.
>
> The 3 general categories that I believe the brainstorming should be focussed
> on are:
>
> 1. How to neutralize (or better) our current competitive disadvantage with
> Verilog at the gate level?
>
> 2. How to neutralize (or better) our current competitive disadvantage with
> Verilog in designer productivity at the RT/synthesizable level of design?
>
> 3. How to create compelling value to using VHDL by significantly increasing
> designer productivity (generally thought to be higher abstraction level
> design, but can be anything that otherwise does not fall in 1 or 2 above)?
>
> I believe these 3 categories are sufficient for the following reasons:
>
> 1. As stated in the context setting message. Gate level verification
> remains an "achilles heel" of VHDL. (Don't take that quite literally as in
> we fail unless we fix it. Just take it as a major competitive disadvantage.
> One that results in the competitor (Verilog) getting into our installed
> base.) I think we need to explore ways to neutralize this disadvantage and
> eliminate it from the competitive evaluation process. If we do not, it has
> been and will likely remain a deciding factor in many language evaluations.
>
> 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. However, I think it is worthwhile and
> justified to separate it out. The primary reason is that this is the level
> that 90% or more of HDL users are working at today. Most likely greater
> than 50% of HDL users will remain at this level for the next 5-10 years. We
> need to reward our current users and entice a broader user base.
>
> 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). I think it is
> worthwhile separating the sub-category of 2 from this broader category
> because the issues in 2 are well-known and understood. It should be
> possible to more quickly address a number of these. Issues related beyond
> the current state-of-the-art/practice will take longer to evolve. We need
> to brainstorm on how best to facilitate their development and
> standardization as well as what types of enhancements to pursue.
>
> CALL TO ACTION:
> Over the next couple weeks (deadline 15 April), I'd like any member of this
> group who would like to make a case for adding or removing brainstorming
> categories to do so.
>
> By 15 May, I'd like members of this group to complete their brainstorming as
> to what kinds of things can be done in each of the categories. The ideas
> can be wide-ranging or focussed. But, keep them categorized according to
> the final categories.
>
> LOOKING AHEAD:
> I'd like to take the results of the brainstorming and the survey (including
> the upcoming interviews) plus ISAC report on outstanding IRs as the inputs
> to the general evaluation of what we can and should do. This work will need
> to be done by a more focussed committee. After that work is complete, we
> should have a good framework for undertaking the technical work.
>
> -----------------------------------------------------------
> Stephen Bailey
> Staff Corporate Applications Engineer
> Synopsys Inc.
> sbailey@synopsys.com
> 303-588-2001 (voice/mobile)
> 650-584-4893 (voice)
> ----------------------------------------------------------
>
>
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 12:19:31 PDT