Single Top FPGA Tips

Tony Burch schrieb:

Nice. But what about nr. six?

A can't agree. AFAIK the ASIC guys do a Post Place & Route Simulation to check for possible errors of the compiler (wrong logic optimization, maybe wrong automatich pipeline modification etc.) But for a FPGA . . . In many cases, a real time test is much faster and more valueable for verification (including stress tests).

Regards Falk

Thanks Falk! I don't disagree with you! But where the emphasis on verification is depends partly on which company you are working for. I have worked in ASIC where verification with timing simulation is "everything". You can't sign-off or tape-out untill every block has been ticked. But having said that, real time FPGA prototyping in that process is also essential to success & a better chip.

I have also worked in a company that was doing only FPGA but there was a large emphasis on timing simulation. And I worket for yet another company where the primary emphasis was on real-time verification, and very little on timing simulation.

I wonder if others have had similar experiences of different emphasis in different companies?

I thought about what you said and I will make additions and changes to Tip Number 6 in Revision 1.1 of this the document. Thanks again. Kind regards, Anthony

IMHO under following assumptions, timing sim on placed and routed gatelevel netlist adds little value with great effort : [1] Design passes RTL functional sim. [2] Routed design is well constrained via static timing analysis. Note : Look at static timing analysis tool for ability to flag unconstrained paths. Xilinx trace uses -u option. Then go back and add constraints for any paths which have slipped thru crack, and rerun trace with -u option. [3] Synchronous design practices have been observed with excruciating care.

In theory, the above applies to both FPGA and ASIC, but obviously the cost of any error in an ASIC is tremendous, so go thru the extra effort with an ASIC. (mostly to cover butt ... and that is the defacto standard for ASIC flow).

I would be overwelmingly comfortable shipping quantity of FPGA based systems where above have been followed, and the system has undergone thermal testing.

Problems with timing simulations are they run very slow, take lots of effort to set up rigorously, and (once again IMHO) have a low probability of catching errors.

What type of error would a timing sim catch that have passed thru the above 3 wickets?

--

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

ht

Very informative..! Thanks Tony.

Slightly off topic, but what's going on with BurchEd? I've been wanting to get one of your boards for some time...

Wicket 1. Inadequate test cases. Not functionally verifying the many different modes of operation. Turn on code coverage for the first time in your life and see how poorly you've been exercising your designs. Then shudder at the thought of turning on those other options that check for condition coverage, etc.

Wicket 2. 'Well constrained??' What does that mean? To pass this wicket, incorrectly add a multi-cycle (or false path or ...) timing constraint. What will catch the incorrectly added constraint?

Wicket 3. 'Excruciating care??' What does that mean? The dictionary definition of 'excruciating' is extremely painful; causing intense suffering; unbearably distressing; torturing....OK, so you didn't mean

*that* definition ;) the next defn. is exceedingly elaborate or intense...in any case, even with such 'care', this does not verify that synchronous design practices have actually been observed. Even if it did, how do you verify that 'excruciating' care has been oberved and not 'pretty good' care? How do you measure the level of care? How do you implement this care procedure? What are the metrics?

All three wickets can be passed by those less skilled in design resulting in a design that fails on the bench that 'might' have been caught by running a timing sim (or other methods). For the more skilled, I agree that timing sims are painfully slow and catch virtually no design errors. But the real reason for not catching design errors has to do with the skill of the designer and the quality of the designs that they produce.

There is no substitute for skill, but also no really good measure of it either. The less skilled might not really know how 'less' they are and they would probably do well to use many different forms of verification. As they become more skilled, they'll naturally tend to see which methods are helping them find problems and which are a bit of a time waster, but they have to evaluate that themselves.

Kevin Jennings

Sorry, but inadequate test cases do not suddenly do better coverage when run in a timing sim vs an RTL sim.

When I say well constrained, you give an example of poorly constrained.

Quibbling over my use of word excruciating? Oh well. Once again, when I specified a higher level of care on synchronous design practices, the area you question is when these are weakly enforced.

The original poster described two places he has worked, one believing in timing sim on FPGA, other bypassing. Really there are two camps of thought. I couched my response with IMHO in two places ... meaning I recognize the fact that there are two camps, and I don't particularly want to spend the rest of my day debating with someone from other camp. Just wanted to clarify what the viewpoint of the "can skip" timing simulation for an FPGA design flow.

My last two points in first email were pretty key :

- in circuit testing, over temperature, with thorough test cases is an ultimate test for "goodness" whether it be an FPGA or an ASIC.

- Cost benefit ratio of gate level sim very high.

If I ran into someone in gatelevel sim camp of FPGA, I would explain my points, but not be dogmatic about it. Reality, as long as there is consideration for why certain things are done is really the important issue.

--

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

You ended your earlier post by asking for a type of error that a timing sim could catch that could get through the three wickets, that's what I was repsonding to.

Wicket 1 was simply "Design passes RTL functional sim". That can be a pretty low bar to hurdle until you start including minimum coverage metrics of some sort to insure that the design is at least being fully exercised.

Another way to fail timing sim even with complete code coverage is, lets say the designer uses either enumerated types in a state machine and forgets to include a reset mechanism but the reset state happens to be the first enumerated item. The functional sim passes but does so because it relied on the simulator initialization. Let's say the state machine gets implemented now as 'one-hot' in some device. If that device at power up resets flops to 0 we're in an 'impossible' state if no power up state is guaranteed then the gate sim should have 'X' for the state machine.

That's a way to get through wicket #1 and still have an incorrect design.

No, I gave an example of a design error. Design errors happen all the time, various forms of verification are intended to find those errors but I'm not aware of a tool which will validate that a particular input timing constraint itself is correct or not.

That's a way to get through wicket #2 and still have an incorrect design.

Only in fun, was meant to be taken lightly.

I questioned how you validate that the appropriate amount of care has been applied and how one would measure this. Without such unbiased measures, the level of detail that represents appropriate (or excruciating) care means only as much as the person providing the care thinks it might mean.

That's a way to get through wicket #3 and still have an incorrect design.

For the record, I'm not in the "timing sim an FPGA" camp.

And I was responding to ways that one can clear your wickets with an incorrect design and tried to show that which verification techniques are used can clearly be a function of the skill of the designer.

Agreed.

Agreed, and all I was really adding is that you can't simply evaluate those considerations without regard to the level of skill of the designer.

Kevin Jennings

Thanks mate! Exciting things are happening at BurchED...several projects in the pipleine aimed at helping FPGA designers. I can't say more than but if you want to be the first to know you can subscribe to FPGA News at

We no longer make the BurchED Brand boards but there are some great value boards available from many places, including Digilent

In my opinion, these Digilent ones look great:

• Basys, Spartan3,

• Spartan 3 Starter Board (some nice fast SRAM on there instead of SDRAM)

• Nexys 2, Spartan 3E,

• Spartan 3E Starter Board, Spartan 3E, 9 (I personally have this one)

For Altera, I like Terasic boards

• Altera DE1, Cyclone II, 0 (personally I have their earlier Terasic TREX C1 but that is no longer available)

By the way, can anyone give personal recommendations for some nice Lattice or Actel boards?

Kind regards,

Anthony Burch

Getting Started With Xilinx FPGAs Video Guide