|
Viewing 1 to (11 Total) FPGA Verification |
Total Posts: 6
Joined: Jan 2010
|
Hii,
While discussing FPGA based designs ,no one can ignore the importance of verification.In todays scenario verifying a design is the most challenging job.It is one of the major bottleneck in meeting the project schedules.
but can wee compromise on verification efforts?
The answer will be-NO? As an improper verification methodology will cause design re-spins,increasing the cost to market.
Now as we know there are various methods available for verifying HDL based designs.Formal verification,simulation, assertion and classical code walk through.
Which one of these can deliver.Lets discuss it here .My personal choice is assertion based verification along with transaction based test generation.
Posted on 2010-01-23 00:49:58 at 2010-01-23 00:49:58
|
|
Total Posts: 17
Joined: Feb 2010
|
Code Coverage: The First Step
I still contend that Code Coverage is the first step in putting together a cohesive FGPA simulation strategy. Without code coverage, you don't have any idea of whether your test bench is really testing the design.
While code coverage doesn't fully answer the question of whether you've tested a design, it certainly can tell you what you have NOT tested. And that's an excellent start.
Posted on 2010-02-15 22:54:32 at 2010-02-15 22:54:32
|
Total Posts: 8
Joined: Feb 2010
|
Requirement coverage: Second step ?
Code coverage only shows that the verification has tested statements, branches, conditions. The FPGA will never go in not stable state and definitive failure. But does it always do what it is expected to do? So for each test case, proof shall be given that the behavior of the FPGA is compliant to its specification. Of course, this is a long time to spend in modelisation or manual verification.
Posted on 2010-02-17 05:55:17 at 2010-02-17 05:55:17
|
|
Total Posts: 6
Joined: Jan 2010
|
code coverage is good! what's next
yes i do agree that code coverage is a very good start.It really gives a good estimate of the quality of the test-bench.
But to have a full functional coverage,we must have a methodology which targets the requirements.
So what are the best tools available for carrying out assertion based verification, developing layered test-benches and carrying out formal verification(!).
Posted on 2010-02-17 13:21:35 at 2010-02-17 13:21:35
|
|
Total Posts: 8
Joined: Feb 2010
|
Requirement coverage tool
Mentor ReqTracer should be a tool to manage the functional coverage. But the the video I saw of this tool did not convince me for all the functionality we needed. So we decided to develop our own tool, based on tcl scripting.
Test bench code is tagged with the requirements, the tcl script parses the test bench code to give synthesis of what is really performed in the verification simulation.
Posted on 2010-02-18 05:18:24 at 2010-02-18 05:18:24
|
|
Total Posts: 17
Joined: Feb 2010
|
Requirement Coverage Tool
Errr... Remy. Not to spew my Mentor Kool-aid all over the place, but ReqTracer does what you just said.
I suspect you saw an earlier version.
Ray "Mentor AE who drank all the Kool-aid" Salemi
PS. Why is Kool-aid spelled with an "aid" instead of an "ade" as in lemonade?
Posted on 2010-02-18 08:18:13 at 2010-02-18 08:18:13
|
|
Total Posts: 17
Joined: Feb 2010
|
The Best Tool?
I think the best tool depends up on your design and test bench.
If you have a very simple design, then you can implement functional coverage by writing down a list of tests and making sure that you've run each test. This is functional coverage.
On the other hand, if you have a very complex design, and if you're using constrained random to create your stimulus, then you'll need to implement a coverage model. This can be done with a combination of assertions and covergroups in SystemVerilog.
In that case, the best tool is a SystemVerilog simulator.
Then, after that, you can get very fancy by linking the simulator to a requirements tracking tool as Remy pointed out. At that point the best tool can be something like Reqtracer or a script like the one Remy's team created.
Posted on 2010-02-18 08:27:31 at 2010-02-18 08:27:31
|
|
Total Posts: 6
Joined: Jan 2010
|
Model based verification
Thanks for your replies.
my next query is regarding ABV vs model based verification for arithmetic modules such as Floating point units.
I feel developing a model is the best way to verify such designs ,where as ABV is good for protocol verification and bringing out timing issues in the design.
Is this assumption correct or ABV can be used to fully verify such designs.
Posted on 2010-05-18 14:31:05 at 2010-05-18 14:31:05
|
|
Total Posts: 17
Joined: Feb 2010
|
Property Checking is great for protocols. Floating point can use functional coverage
You nailed it. Formal property checking is best for deep state machines and protocols.
As the Intel FDIV bug proved, floating point verification depends up on the algorithm. In the case of the FDIV bug, there was a look up table with 1066 entries. Five of these were wrong. If Intel had done functional coverage on that table, and made sure that it had tested all the entries in the table, then the FDIV but (and its $420 M writedown) would not have happened.
Of course, everytime I mention this example I feel old. There's always an engineer out there who says, "But Ray, I was 10 when that happened."
Posted on 2010-05-25 06:45:47 at 2010-05-25 06:45:47
|
|
Total Posts: 6
Joined: Jan 2010
|
Writing functional coverage
hi everyone,
recently i got an opportunity to verify a floating point unit.This FPU is not compliant to IEEE754 as it uses 2's complement arithmetic.I had used constrained random verification and developed a reference model in system veilog.
i have run 30k-50k random numbers on it and could find some subtle bugs in the design.
but the big question is whether are there any more bugs in the design.i have randomized the operands but what can be the best coverage model to make sure that i have exercised enough combinations?
thanks for your replies.
Posted on 2010-08-14 02:25:39 at 2010-08-14 02:25:39
|
Total Posts: 5
Joined: Aug 2010
|
Functional coverage & random gen - when do we converge?
In response to war_isbest:
You raised 2 important discussions here - one on ABV and the other on CDV. Let me provide my views on CDV here.
As you have noted, you ran 30-50K random vectors, still not sure..that's always the case unless you have an exhaustive run - if your datapath is not too wide, you may do that. Formal with ABV is another good alternate - provided you have all the assertions coded!
With respect to fcov & CDV - here is what I have seen working:
1. Define good cov model - measure it against code cov, if code-cov is less yet fcov is more, that indicates weak fcov-model
2. Run as many seeds as possible. With all major tools supporting top level seeding, this is a good option. RVRA (from Aldec) supports: -sv_seed option to vsim. Similarly Questa has -sv_seed option. VCS has +ntb_random_seed etc.
3. Use advanced convergence technologies such as CCT/ECHO with VCS, see: http://www.cvcblr.com/blog/?tag=cct
http://bit.ly/9rrPAg
http://bit.ly/9iwx7j
4. Finally use traditional metrics like: "Bugless regression for 10-days" etc.
Regards
TeamCVC
www.cvcblr.com/blog
Posted on 2010-08-19 17:36:23 at 2010-08-19 17:36:23
|