Hey, it works for me.
Posted by Chris Schalick on Fri, Oct 19, 2007 @ 09:34 PM
Ask anyone involved in verification if untested code will work and they all will say, "No." That is the driver for best practices in design and verification of large FPGAs. You can't test it if you don't know what it needs to do, so write a design spec and review it. You can't say you tested it if you can't describe the tests, so write a test plan and review it. Make sure to include directed tests, intentional corner case tests and random tests.
Sounds obvious, right? It's a simple game! Test everything in the design and it will just work. Then there is my all-time favorite lab debug phrase, "I ran it in simulation and, hey, it works for me. Must be a software problem."
Almost every engineer working with FPGAs when asked whether designs work right the first time in the lab says, "No." Yikes! All those months of testing. Ten's of thousands of lines of test code say it should work. Simulator farms, high end simulators, code coverage...everything works in simulation. So what's missing?
What didn't you test? Simulators are fantastic for making sure FPGA HDL code is doing what you expect. But in FPGAs unless you are a software IP company you aren't shipping HDL code, you are shipping hardware with real, live FPGAs in it.
Speaking of IP, it is tough to make a behavioral simulation model of something that exactly matches a synthesis model without giving away the guts. Not to mention how hard it is to document every bit and transition for the user. In the end, the only predictable way for FPGA customers to gain confidence in integrated IP is to work with the physical IP, not a model of it.
How about the synthesis and place and route process? Is it possible your code doesn't infer what you think it does? Would you see that in simulation? Conventional wisdom on physical design of large FPGAs is that you get thousands of "helpful" informational messages and warnings in a good design. It's pretty tough to find the 1 x message in the bunch that actually says, "I am a bug. Fix me, please."
A recent experience with a downloaded design highlighted these issues for me. There was a testbench and RTL for an FPGA ready design. The tests ran and passed. The good folks who did the design did the work to target an FPGA, so I ran their scripts and programmed the FPGA. Power up and nothing came out. Nada. Bupkiss. It turns out the HDL code was testing for known states and some signals were un-initialized; a classic X-propagation issue. Rather than reviewing the 10's of thousands of lines of code I took a Device Native approach and found the un-initialized code automatically.
A quick code change later and, "Hey, it works for me."