Re: [vhdl-200x], vital issues

Subject: Re: [vhdl-200x], vital issues
From: Jim Lewis (
Date: Fri Mar 14 2003 - 11:43:21 PST

    I always run gate sims. Especially to find reset
issues and RTL to gate translation issues (sensitivity list +)
Were the issues primarily transaction issues or were they
timing issues? Transaction issues you could find if you
had any type of gate simulation models (even ones that run

    To me, static timing analysis (STA) is the only practical
way to find timing issues. For timing simulations to be
effective, you need to activate each critical path. You
probably need STA to find the critical paths. This is time
consuming and impractical unless it is a program requirement
(think of vectors for an ASIC tester where the ASIC goes in
a critical system like a spacecraft or airplane).

    With your timing issues, I would also be
investigating why I missed them with the static timing
analysis tool. I like to run gate level timing simulations
to validate assumptions (multi-cycle paths, false paths)
made in STA.

    According to a paper at DVCon vital is 4X slower than
Verilog. I would like to see VHDL have a gate level library
with timing that runs the same speed as Verilog, and one
without timing that runs faster (200 X faster just like the
name of the reflector replies :) )


Robert J Myers wrote:
> Jim;
> We've just recently run into a number of integration issues
> with FPGA designs that functional simulation didn't catch.
> When we went looking to determine the issues, we found that
> VITAL simulation showed us errors in coding approaches that
> were not completely obvious (such as async reset terms, timing
> issues on bidirectional busses, etc.). After reviewing the Modelsim
> VITAL simulation waveforms, we were able to resolve a number of
> the issues we had and get the designs running in our
> integration/validation/production(?) systems. Only potential gotcha
> that we're not sure about now is the temperature aspect (running at or
> slightly
> beyond Industrial temperature ranges).
> Regards,
> Bob
> Robert J. Myers
> Technical Consultant -- PSAS HW Engineering
> Raytheon Systems Company
> 2501 W. University Drive M/S 8070
> McKinney, TX 75071
> (972) 952-4352
> Jim Lewis
> < To: Steve Casselman <>
> > cc:
> Sent by: Subject: Re: [vhdl-200x], vital issues
> owner-vhdl-200x@ser
> 03/14/2003 11:39 AM
> Steve Casselman wrote:
> ...snip...
>>The real question is did Vital hamstring VHDL simulation speed to the
> point
>>were engineers _have_ to use Verilog to get their work done in a timely
> According to a paper at DVCon, Verilog gates are 4x faster than
> VHDL gates.
>>If that is the case then why not have a "gate level VHDL" format?
> This sounds great.
> My thought is that with economic forces at play, it sure would
> be nice for silicon vendors (and perhaps eda vendors too) if
> the VHDL format were some how compatible with the Verilog
> gate level format. This way they only need to support one
> sign-off quality gate level netlist.
> > We could call it SuperSpeed VHDL ...
> Perhaps I set my targets too low when I thought of matching
> the speed of Verilog gates. However, you sparked some ideas.
> What do we use gate level simulations for these days?
> I use static timing analysis to figure out how fast the chip
> runs. I use gate sims to find issues between RTL and gate
> (reset, ...) and as a sanity check on my timing assumptions
> made in static timing analysis. I am sure there are more.
> With some assumptions, perhaps we can even add modes to
> run gate sims without timing enabled and run considerably
> faster.
> Still I think we would all benefit if the base level library
> format were either based on or easily translatable
> from a Verilog library.
> Cheers,
> Jim
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jim Lewis,, Expert VHDL Training
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jim Lewis
Director of Training   
SynthWorks Design Inc. 

Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 12:04:21 PST