Questa Assertion-Based Verification Validates Bridge for Complex On-Chip Buses
Gordon Mortensen leads a development team at National Semiconductor responsible for companion chip sets to accompany their X86 Geode™ Integrated Processor products. These companion I/O chips integrate a wide range of functions, including traditional South Bridge functionality, Super I/O and legacy features, USB host controllers and audio controllers. With these complex designs, as Mr. Mortensen commented, “the number one challenge in verification is finding bugs early enough in the design that we are not impacting our schedule with bug corrections.”
“CheckWare monitors measured our test suite effectiveness and found interface bugs using simluation and dynamic formal verification”
Learn More About Questa Assertion-Based Verification
product overview: The Questa Formal Verification tool complements simulation-based RTL design verification by analyzing all possible behaviors of the design to detect any reachable error states.
Assertion Checkers and Monitors Verify Complex Bus Protocols
Mr. Mortensen’s team recently completed an I/O companion chip for National’s Geode family of processors. The development team used the Questa® Assertion-Based Verification Suite to verify portions of this million-gate chip more rapidly and more thoroughly than with traditional methods. The team focused in particular on a new internal bus architecture and an internal bus bridge that would have been especially difficult to verify without assertion-based verification.
At the start of the project, the team was “looking for the ability to enhance our standard black-box verification approach with something that would allow us to uncover corner-case bugs and more complicated bugs earlier in the design process,” said Mr. Mortensen. They selected Questa Check, Questa Search and the Low Pin Count (LPC) CheckerWare® monitor to accomplish this goal.
Assertions Help Designers with RTL
When discussing the process of adding the Questa tools to their existing environment, Mr. Mortensen remarked, “it was actually a seamless integration.” The designers found it easy to use Questa Check and add assertion directives into their RTL code. They used dozens of checker types from the Questa CheckerWare library including assert, assert_follower, known_driven, range, overflow, underflow and others. In all, the design and verification engineers added more than 2500 directives to the RTL source code, generating a total of approximately 5500 assertion checkers.
Mr. Mortensen said, “one of the primary advantages that using Questa Check gives us is in the process of instrumenting the design. It gives the designers another opportunity to verify that their intent is actually being implemented in their code.
The process of actually writing the assertion check helps the designers re-think what their intent was.” In fact, assertions added value to the project even before the first simulations were run. “We did find some issues with the design early in the process as a result of thinking about how to write the assertions,” he added.
Checkers in Simulation Detect Bugs and Improve Test Coverage
The National team ran checkers in simulation at both the block level and the full-chip level. By detecting design problems at the source, the Questa checkers helped to improve the overall verification flow. Mr. Mortensen said, “We found errors as simple as a FIFO being de-qued incorrectly up to very complicated, corner-case bugs that were very difficult to see with a test written by an engineer.”
In addition to reporting assertion violations and detecting bugs, Questa checkers also report corner-case structural coverage information. This metric helps verification engineers understand design structures that are not being well exercised by the existing simulation tests. “When Questa identified holes in our functional coverage or in our test suite, we would go back in and add targeted tests to cover those misses.”
CheckerWare Monitors Verify Bus Protocols
The National chip project included a new internal bus that Mr. Mortensen described as “quite complex, a streaming bus with varying degrees of scaled streaming on any transfer. A bus bridge connects this high-bandwidth streaming bus to a low-bandwidth bus that looks like a legacy bus. That bridge is quite complicated because there’s a lot of transaction interpretation difference on either side. One bus is looking for packeted data and the other bus is looking for single-event transactions. Bridging those two protocols is a difficult part of the design and that’s where the bugs would normally show up.”
As the first step in verifying the bus protocols and bus bridge, National and Questa engineers worked together to develop custom CheckerWare monitors for both the streaming bus and the legacy bus. Writing these monitors had value for the project team. “When the interface checkers were being written for the custom monitors it was in the stage of the project when we were making final the specification for bridging these two bus protocols,” explained Mr. Mortensen. “While writing the custom monitors with the help of the Questa application engineers, we were discovering issues with our bus specification where it was not quite clear or not quite covering all of the potential execution cases.”
Questa Search Thoroughly Verifies Bus Bridge
The National team decided to use the dynamic formal verification capability of Questa Search to exercise the many corner cases of the bus bridge far more thoroughly than simulation. “We used Questa Search primarily on this bus bridge module because it was the most complicated piece of totally new IP that went with the project. We were quite successful with Questa Search at helping expose bugs in corner cases,” said Mr. Mortensen.
The protocol monitors on the two buses detected several design errors in simulation; during dynamic formal verification these monitors served as interface constraints so that Questa Search explored only legal corner cases for the bus bridge. Questa Search discovered several additional design errors that were not found with simulation. As Mr. Mortensen explained, “the most interesting bug that we found was a corner-case condition on a coherent memory transaction. The address being issued for the transaction was actually out of spec on one of the bits. The transactions normally processed correctly because it was an unused address bit; we did not see the bug when we were running targeted tests in simulation, but the monitor flagged that as a problem with Questa Search.”
Silicon Testing Successful
Dynamic formal verification is effective at finding tough, corner-case bugs that otherwise would go undetected. “I am quite confident that we had some bugs identified using Questa Search that had a high probability of making it into silicon,” said Mr. Mortensen. “We definitely increased our confidence by using the Questa tools.” That confidence was confirmed when the chip was fabricated and tested in the lab. “I can say that we have not found any bugs on silicon with the bus-bridging module. We had a very successful project with initial silicon sampled to our customers.”
- STMicroelectronics: Simulation + Emulation = Verification Success
- Lockheed Martin Space Systems Company
- Dot Hill Systems Corp.
- Xsigo Systems
- ON Semiconductor
- Institute of Microelectronics
- Evatronix IP
- National Semiconductor
- Sun Microsystems: Three-Million Gate Design
- Sun Microsystems: Multi-Clock Design
- STMicroelectronics - mixed analog-digital verification success with OVM
- Advanced Micro Devices
- Hyperstone: ModelSim with SystemVerilog DPI
- Hyperstone: SystemVerilog DPI
Director, IA Chipset Design,