Subject: Re: [vhdl-200x], vital issues
From: Robert J Myers (Bob_Myers@raytheon.com)
Date: Fri Mar 14 2003 - 12:52:07 PST
Jim;
Mostly, we've been running functional simulation prior to going
into synthesis/routing. Up until recently, we didn't have issues
with doing it this way. Granted, part of the router output is pre- and
post-routed timing analysis, based upon timing constraints that are
fed in via a router control file. We always review these reports, and
if deemed necessary, may switch the design effort from single-route
to multi-pass place & route mode.
However, with three of our FPGA designs recently, we've had issues
in validation and temperature checkout when the number of wait states
for handling bus/board transactions was reduced. (There is a
power-on/system running requirement that we need to meet). When
this was done, we started experiencing operation issues that were not
expected -- functional simulation did not indicate any issues. We normally
review the P&R reports, post-routed timing reports, and worst-case net
delay reports -- in this situation, all seemed to meet our design
requirements.
We then ran VITAL simulations and found issues whenever async resets
were activated during the test bench run -- portions of our designs went
unstable.
(This issue was corrected by removing local async resets and re-coding
them
into the sync clock term of all register and counter processes).
There were also other issues with regards to how we modeled bus
transactions (dealing with DSP interfaces as well as VME-based ones).
Problems with synchronizing async address/data/control signals were found
and resolved shortly after reviewing the wave traces of the internal nets
in the
VITAL simulation (which was in some instances a trick to resolve, since the
synthesis tool changed net names to internally generated net names).
From my understanding, the timing analysis tools that are supplied by our
FPGA vendors (Actel, Altera, Xilinx, etc.) are improving. However, this
doesn't
help us when we're locked into older technology FPGAs (due to being
near or at production release). Hopefully, our knowledge/expertise will
improve
in their use and we'll be able to turn designs more
efficiently/effectively.
I hope that some people (the 1076.4 group?) gets pro-actively involved and
maybe
determine what can be done to improve VITAL simulation so more people
will use it to help cut down integration/validation issues and time spent
in
the labs. I believe that VITAL simulations at this point should be a
requirement and
not an option for getting designs through the entire concept->production
cycle.
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
<Jim@synthworks.com To: Robert J Myers <Bob_Myers@raytheon.com>, vhdl-200x@server.eda.org
> cc:
Sent by: Subject: Re: [vhdl-200x], vital issues
owner-vhdl-200x@ser
ver.eda.org
03/14/2003 01:43 PM
Bob,
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
fast).
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 :) )
Cheers,
Jim
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
> <Jim@synthworks.com To: Steve
Casselman <sc@vcc.com>
> > cc:
vhdl-200x@server.eda.org
> Sent by: Subject: Re:
[vhdl-200x], vital issues
> owner-vhdl-200x@ser
> ver.eda.org
>
>
> 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
>>fashion?
>
>
> 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, www.SynthWorks.com, Expert VHDL Training
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 13:05:40 PST