Hyperstone Builds a Better Co–Verification Environment with Questa SystemVerilog DPI
The Questa SystemVerilog DPI enabled development of an enhanced Hyperstone mixed-language testbench, including the integration of an ISS C model and a software debug environment. By providing a bridge between the C, RTL, and gate levels, the DPI set the stage for co-verification and the software debugger interface, yielding significant productivity gains through parallel design and verification of software and hardware. This modular, transaction-level approach also supports testbench reuse in current and future designs.
“It’s very important that Questa extensively supports the features of the SystemVerilog DPI. This is not the rule.”
Arthur Freitas, Development Engineer
Since its founding in 1990, Hyperstone AG, of Konstanz, Germany, has gained a position as a leader in single-chip, flash memory controllers for SD/MMC cards used in such products as digital cameras, mobile phones, PDAs, portable multimedia players, and digital voice recorders.
Hyperstone keeps its competitive edge with innovative design strategies that leverage the opportunities of advanced verification technologies. Last year, its cutting-edge SystemVerilog-enabled testbench, used in the development of the S4 flash memory controller, generated so much interest at a users’ conference that it was voted the best paper on functional verification.
Not to rest on his laurels, the paper’s author, Arthur Freitas, a development engineer at Hyperstone, wanted to enhance the S4 testbench environment for the next-generation controller. Building upon the capabilities of his earlier work, he came up with an even more effective verification environment for the Hyperstone S5 single-chip flash memory controller. This included the integration of C code in HDL simulation using the Questa SystemVerilog DPI, which enabled hardware/firmware co-verification, parallel hardware and firmware development, and the debug of hardware models during HDL simulation.
Abstract and Accelerate
The Hyperstone S5 includes the Hyperstone E1-32X microprocessor core and SD/MMC interface logic. A substantial part of the system is implemented in firmware, making hardware/software co-verification highly advantageous.
Due to highly competitive design requirements, a hard macro version of the processor’s 32-bit RISC architecture was used in the system, necessitating a gate-level simulation. Not surprisingly, this resulted in simulation performance well below that required for co-verification. Therefore, Hyperstone needed to find a way to accelerate the microprocessor.
The S5 testbench replaced the gate-level representation of the design’s on-chip microprocessor with an ISS and interfaced a software debugger to the DUT.
The most cost effective approach was to instantiate an instruction set simulator (ISS), written in C, to replace the gate-level representation of the on-chip microprocessor. The high abstraction level of the ISS led to the required boost in simulation performance.
Hyperstone also wanted to establish an interface between their high-level software debug environment and the design under test (DUT), so they could run the software debugger on Questa. Among other things, this would enable the software designers to debug their C/assembly source code directly, rather than viewing events only in a waveform display. Hyperstone accomplished this by creating a UART DPI also written in C.
S4 to S5 Testbench Evolution
When they built the previous S4 testbench, Hyperstone reused the verification infrastructure and methodology from earlier projects, then replaced the gate-level representation of the microprocessor with its C-model representation— in order to speed up simulation and build a regression test suite that gave them the desired level of functional coverage. To accomplish this, they needed a mechanism that enabled Verilog code to call functions written in C. They decided on the SystemVerilog DPI.
“Mentor showed me all the things I could do with the DPI,” recalls Mr. Freitas. “It was not only much faster than a Verilog PLI, but also much easier to use and learn. It’s very important that Questa extensively supports the features of the SystemVerilog DPI. Not all companies support the whole set of features required to run our accelerated version of the processor in their simulators.”
The SystemVerilog DPI allows functions from SystemVerilog and C to call each other without caring in which language the function is actually implemented, providing a powerful bridge between high-level C and lower-level RTL models and on down to gate-level hardware. This allowed Hyperstone to use behavioral models in C, enabling simulation at a higher level of abstraction and substantially accelerating their verification environment. Importantly, the SystemVerilog DPI does not require engineers to define complex system tasks and associated callft routines as required by a Verilog PLI.
Still, the S4 testbench could not perform firmware simulation because the on-chip microprocessor had to both generate stimulus for the SD/MMC bus and act as pseudo-firmware. This is where Mr. Freitas saw future opportunity. The speed improvements gained by using the SystemVerilog DPI allowed him to add additional processors, written in C, to what would become the testbench first used on the S5.
“Thanks to Questa and the SystemVerilog DPI, our system was now fast enough to allow the simulation of two processors,” Mr. Freitas explains. “So we instantiated a new processor to act as the SD/MMC host.”
The additional processor freed the ISS to run the actual firmware exclusively, while the SD/MMC host ran the verification software. This new testbench both matched the real application and enabled hardware/firmware co-verification.
Now that the testbench matched the real application, the software developers became interested in simulating pieces of their code in the verification environment.
“By putting the software debugger into the verification environment,” recalls Pablo Dorronsoro, lead engineer in the development of Hyperstone’s hugely successful S–family of single-chip controllers, “our software engineers gained visibility into the whole system: firmware, RTL, and C models.”
Initially, the software debugger communicated with the flash controller via a UART interface. To connect the software debugger to Questa, Mr. Freitas wrote a behavioral model of the UART interface in C. This allowed the same development environment used by the software team to be used to control and examine the hardware simulation.
“Once we got this up and running, we could debug the whole thing using different approaches, all connected and working together through Questa,” Mr. Freitas explains. “For example, we used the waveform viewer to debug signals and see why an interrupt was coming too early or too late; the vpi_printf to print variables; Questa’s GDB debugger to set breakpoints in the ISS C code; and our in-house software debugger to debug the firmware.”
“Firmware developers are even able to develop software in the Questa environment,” Mr. Dorronsoro adds. “Using the same debugger in the same environment that we use when we develop software in the real controller is a big advantage.”
The interface between the software debugger and the DUT allowed firmware engineers to start testing and integrating code without having to wait for an FPGA prototype. This helped solve hardwarefirmware integration problems much earlier in the design cycle and improved the quality of verification since many hardware bugs were discovered this way.
“That we can start developing software before the hardware is available applies to the next version of the controller, as well as the next version of the flash chips that we get from our customers,” Mr. Dorronsoro explains. “This allows us to work in parallel with our partners and customers and come up with a product sooner. Furthermore, hardware has manufacturing problems that prevent us from carrying on with firmware development. In a simulation environment, you don’t have this problem.”
Because they work in different environments, hardware and software engineers find bugs not found by the other. The strategies and methods they use are distinct. This increases the likelihood that the same bugs are not missed and the same human errors are not repeated.
“As a verification engineer, I get true stimuli, which is the real firmware, in my design,” Mr. Freitas explains. “Let’s say we had a bad assumption in hardware, when I start simulating firmware in the hardware, I’m going to uncover these bugs. This is true stimuli that I get for free, and it complements my regression tests.”
The integrated debugger also enabled them to accelerate the debugging of problems found in the FPGA prototype and engineering samples.
“We no longer had to spend time reproducing test cases in the simulation testbench,” Mr. Dorronsoro recalls. “We simply hooked up the debugger to Questa to simulate the same piece of software that was causing the problem in the FPGA or ASIC sample.”
To test the performance of their integrated verification environment, Hyperstone compared the speed of communication between the software debugger and the flash controller when using their development board (the actual hardware) versus two simulations.
In the accelerated simulation using the ISS, the communication between the debugger and the controller was more than fast enough for the software engineers to write firmware in the simulation environment. The netlist simulation was more than adequate when debugging a timing dependent problem that required a cycle accurate simulation.
Reuse and Repeating ROI
The reusability of the SD/MMC host, the SystemVerilog shell, and other testbench components was a large contributor to the successful evolution of Hyperstone’s verification environment: past, present, and future.
“With the S5, we built an independent SD/MMC host that we can use in any project,” Mr. Freitas says. “In fact, we’re using it already in another project that has nothing to do with the S5 and S4 families.” In the future, Hyperstone plans to substitute the SD/MMC host with a SystemVerilog host, and then use Questa to write regression tests.
“We are planning to do verification IP for the SD/MMC interface totally based on the testbench automation features of SystemVerilog and Questa,” Mr. Freitas confides. “We’ll replace our current SD/MMC host ISS written in C and assembly code with a full constrained-random SystemVerilog SD/MMC host. This will give us a much more flexible and powerful SD/MMC host written solely in the SystemVerilog language.”
“Firmware developers were even able to develop software in the Questa environment. Using the same debugger in the same environment that we use when we develop software in the real controller was a big advantage.”
Pablo Dorronsoro, Development Engineer
Pablo Dorronsoro and Arthur Freitas, Development Engineers at Hyperstone AG.