Aldec Rounds Out ALINT-PRO Checker

If there’s anyone out there who still doesn’t accept the importance of static RTL verification in the arsenal of functional verification methods, I haven’t met any recently. That wasn’t the case in my early days in this field. Back then I grew used to hearing “I don’t make mistakes in my RTL”, “I’ll catch that in simulation”, “My editor automatically sets the RTL up correctly” and variants on these confident statements of infallibility.

Positions like these became much less frequent after IP reuse and SoC design took off. You might still feel the same way about your own code, but now you must work with RTL developed by someone no longer at the company, and integrate with other RTL developed by parties even further removed. How can you know what assumptions they made? You don’t have time to reverse-engineer this stuff in simulation, so do you just hope the other designers thought exactly the way you do when they built that code?

This topic is fairly widely understood in the ASIC world, perhaps less so in the FPGA world where design teams now working on monster FPGA SoC designs are starting to learn the importance of verification disciplines their ASIC counterparts have crafted over many years. A recent survey on trends in verification highlights that FPGA and ASIC verification needs are converging, which is good news for ALDEC who have in ALINT-PRO offered a common verification platform for both.

Static verification is your first safety net in functional verification. Naturally it won’t catch complex functional problems but it will get you past the basics – incorrect inferences, unintended truncation, unclocked cycles and other basic design flaws. You could still catch many of these in simulation but in verification environments of any scale that would be grossly inefficient. These all kick off with smoke tests, including static verification, to ensure basic mistakes are caught before valuable simulation cycles are wasted.

What’s more, simulation won’t catch everything. Signals crossing between asynchronous clock domains (say between a peripheral port and a central bus) can lock into metastable states or drop cycles, causing all kinds of havoc. While some claim you can catch these problems using simulation approaches, analyses of that kind are invariably incomplete. Static tools like ALINT-PRO have this kind of analysis built-in and since it is static, it is test-case independent, ensuring you will find all potentially problematic crossings.

That said, I’ll now contradict myself by adding that sometimes a combination of static and dynamic analysis is essential to reach more complete domain-crossing verification, especially where functional behavior is an essential part of the check. This often comes up in checking handshaking synchronization schemes. Aldec support this through close linkages between ALINT-PRO and the Riviera-PRO simulator or other simulators.

ALINT-PRO also provides pre-defined block-level models for Xilinx primitive libraries and now adds models for most of the Intel/Altera families of devices. This is important. When static analysis tools bump into a hard macro, such as a memory, they need hints on how to proceed, such as whether this is a registered interface and which clock controls the interface. Aldec provides a method for you to define these yourself, but life is a lot easier when models for all the basic blocks are already defined and verified with the FPGA vendor.

One last point I learned the hard way during my time in these trenches. Static checkers are based on rules and everyone has their own opinion on what rules should and shouldn’t be checked and at what stage. Some users want the whole check to be fire-and-forget so they enable all rules (more must be better, right?) and run. The result is massive volumes of reports they can’t possibly read and which they therefore ignore. Until a silicon spin fails, the boss asks whether they checked the static analysis and there’s a long, awkward silence.

The lesson is that checking everything makes no sense; you must be selective. And what you choose to select is sensitive to where you are in the design cycle. When building a brand-new RTL block, you might want to require more checks to comply with an internal (or external) standard. When checking modifications to a legacy piece of RTL, you need to loosen up; you don’t want to know about coding-style problems in areas you don’t plan to touch. In system integration, you want to focus mostly on functional issues (such as clock and reset domain crossing analysis). ALINT-PRO makes it possible to craft these choices in way that reflects your local preferences.

You can read the ALINT-PRO product description HERE.

More articles by Bernard…