Comment on "FPGA Simulation" as appeared in FPGA J

SAHO · Senior Joined: Oct 16, 2004 Posts: 24

Hello expert:

http://www.fpgajournal.com/articles/20040601_simulation.htm

Reading this article seems to suggest that there is no need for assertion based methodology (in the FPGA design flow). In addition to this, EDA vendors that support assertion languages are charging a premium for the tool support. Cheaper simulator like ModelSIM PE DOES NOT support PSL, only premium tool ModelSIM SE does. As we all aware that, budget is not infinite in non-ASIC design centre.

I would like to hear your views on this.

Personally, I think assertion verification is very useful and important for a good quality design.

SAHO

srini

alain94040 · Senior Joined: Jun 03, 2004 Posts: 22 Location: San Jose

vhdlcohen · Posted: Wed Oct 20, 2004 3:04 pm **Post subject:**

SAHO · Senior Joined: Oct 16, 2004 Posts: 24

With FPGA design mostly done in Windows platform and using cheaper tools at most times, assertion technology seems rather distant for FPGA designers as only premium based tool support PSL and SystemVerilog assertion. Do you agree with my observation? Contact with Model Technology support indicating that there is no roadmap for built-in PSL and SystemVerilog for ModelSIM PE edition. I think EDA vendors are not fair to FPGA designers, with limited money to spend on tools.

Of course, there is always OVL packages as replacement. Can someone provide a comparison between the difference of OVL and PSL, apart from the complexness of OVL model.

By the way, which tool supports the logic synthesis of assertion?

Your contribution is very very much welcomed and appreciated. I learned!

SAHO

vhdlcohen · Posted: Wed Oct 20, 2004 5:22 pm **Post subject:**

In support of EDA vendor's fees, it is important to realize the big expendidures in developing / integrating / and supporting ABV with PSL / SVA. Tool prices are always negotiable.

But the value of the tool in relation to its ROI needs to be addressed. To economize, one may get fewer licenses of the more expensive tools, particularly if they can be time-shared.

OVL is not as readable as PSL or SVA because it's an instantiation of IP modules, most of them fairly primitive. With PSL or SVA, one have more options to describe properties that are also more descriptive (my opinion).

About supports for logic synthesis of assertion, a google search on "Assertion Synthesis" produces interesting results from companies that support it. -- of course at more $$$

Can't win there !!! Laughing

Ben Cohen
_________________
Ben Cohen http://www.systemverilog.us/
* SystemVerilog Assertions Handbook, 3rd Edition, 2013
* A Pragmatic Approach to VMM Adoption
* Using PSL/SUGAR ... 2nd Edition
* Real Chip Design and Verification
* Cmpt Design by Example
* VHDL books

cschalick · Posted: Thu Oct 21, 2004 6:20 pm **Post subject: FPGA Simulation**

I think the article is very thought-provoking. There are contradictory ideas presented:

- the EDA industry has by and large orphaned the FPGA community
- FPGA design complexity is driving the need for "ASIC-like" verification practices

I think the suggestion that assertion based verification techniques described is based on availability and cost of tools - not really a value judgment, just an observation of the current state of EDA and FPGA design teams.

A point that isn't really made (but imho should be) is that the current "just get it in the lab and figure it out there" HIL techniques are not really appropriate when the design pushes the limits of the FPGA technology. IE, if there are significant timing challenges, just whacking code isn't going to get software running on a platform sooner - in fact it may delay it if the resulting designs require re-architecting to solve hairy partitioning or timing issues.

My personal view is that FPGA designs need the same amount of verification as ASICs. I believe it is always better to take the time to do it right the first time and reduce design-churn. One of my favorite sarcastic design axioms, "We don't have time to do it right, but we have time to do it twice."

cindy · Industry Expert Joined: Aug 17, 2004 Posts: 309

saho,

asif · Senior Joined: Oct 20, 2004 Posts: 18

The FPGA's are reaching a gate count of 8-10millions ,there difference in verification methodology for ASIC and FPGA's are converging.

Moreover using ABD is like adding an overhead plus calling for trouble for synthesis tool.

vhdlcohen · Posted: Sun Oct 31, 2004 9:22 pm **Post subject:**

asif · Senior Joined: Oct 20, 2004 Posts: 18

I think i have not made myself very much clear. The point i wanted to highlight/make was :

Why should a verification Team/engineer bother if the design is going to be implemented in FPGA/ASIC/GateArray/Platform ASIC ???

I still feel that verification methodology is independent of Final Implementation of design.

I do agree with Ben Cohen about ...the uses of ABV methodology etc...etc....but synthesizing ABV/ABD for verification for FPGA , i don't see any advantage.

-Asif
ps :Verification here means is Functional (Pre Silicon) Verification

mark_litterick

Hi All,

At the time of this article I wrote the following response (Sent: Thursday, June 03, 2004) to Kevin Morris, the author. (at the time Kevin acknowledged the message but was busy with DAC commitments, so no reply yet)

-----------------------------------------------------------------------

I read with interest the article on "FPGA Simulation - Forget what you learned in ASIC design" by Kevin Morris in the June 1st edition of FPGA and Programmable Logic Journal. Its an excellent article but I don't agree with everything said, so here is some feedback!

-------------------------------------------------

Despite major reservations about the introductory paragraphs I find myself agreeing with the main conclusion of the article: namely that FPGAs place different requirements on the selection criteria for simulators and related tools. However this is secondary to the crimes committed in the introduction.

It is simply not true to state that "verification is what you do to make sure your design is correct before you commit to hardware". In my opinion "verification is what you do to make sure your design is correct" period. FPGAs need verified, the difference is that some of this task can be specifically targeted at an excellent full-performance emulation environment: the target application itself. Simulation based verification is still appropriate for efficient and effective validation of the majority of the device functionality. In addition simulation remains the best regression environment and of course is by miles the most effective debug environment for the FPGAs.

Complex FPGAs are extremely difficult to debug in the system and they are not immune to type of defects that lead to regression failures. Investing engineering effort into a robust verification environment that can be reused across multiple designs, implementing appropriate design-for-verification functional modes of operation and specifically targeting particular tests for real hardware are all effective ways of reducing your time-to-market with FPGA based systems.

Containing the majority of the FPGA verification task in the simulation environment has additional benefits when large designs are close to maximum utilisation of the devices. In these cases the device build times are significant (more than several hours) and the total debug loop from detecting a bug in the system, tracing it to the FPGA, having a guess at
the source of the problem (even with the "current generation of debugging aids"), and re-spinning the FPGA could be unacceptable.

Getting the balance right between features targeted for verification using real hardware and those validated by simulation is crucial. The more complex the FPGA the greater the emphasis for containing the problem in the world of simulation. Its all about reducing time-to-market and maximising product quality.

Even though simulation is a valid and crucial part of FPGA verification it is still true to say that the selection criteria for FPGA tools are based on different criteria than those for ASICs of a similar complexity level. Ease of use and debug are indeed the most important criteria since gate-level simulations are seldom if ever required, long tests can be targeted at real hardware, and functional design-for-verification (e.g. short-frame modes for telecoms) can be used extensively in the simulation environment (with full-frame being tested in hardware).

In conclusion I would say don't "forget what you learned in ASIC" but rather question your methodology and adapt it to the world of FPGAs to make full use of their capabilities.

cschalick

Mark, by reading your post, I think you and I are completely aligned. I have been fishing for wording to describe these points, you described them very clearly.

The tools required for FPGA verification may or may not be the same as ASIC designs require. In any event, it is folly to say that FPGA's do not need the same _level_ of verification as ASICs. If an FPGA design has the same amount of logic in it as an ASIC based system of 3 years ago, it stands to reason that the required verification for "proper system function" must be performed, regardless of the technology the logic is mapped to.

The complication is that 10 seconds of lab time can provide more insight than 10 days of simulation when bugs get hard to find. This drives FPGA designers to get into the lab as soon as possible in hopes of finding the "killer bug" as soon as possible. The sorts of things you want to find this way are either functions not properly modelled in the verification environment, or test left off of the test lists or transactor functions. The ability to "tape out early" and get in-system validation is a significant differentiator between FPGA's and ASICs.

Neither method of "check in code, debug in the lab" nor "don't go in to the lab until everything is perfectly verified" is appropriate for large FPGA designs. Something in between is necessary, even though a full rigorous verification effort must be completed before final shipment.