The use of hardware assisted verification (HAV) technologies was once a luxury, “nice to have” technology for IC design. Because of the costs associated with HAV, especially for the “big box” logic emulators, it was mainly leveraged by the larger companies for their largest SoC projects.
Today with even medium complexity SoCs, modern HAV technologies have become far more accessible and affordable at a time when the use of HAV has become an imperative for helping design teams get massive SoC-powered products to market on time.
In today’s SoC design world, the issue isn’t strictly getting silicon to function properly. The main issue is ensuring that the SoC and the application software that runs on the SoC work together properly and with the highest efficiency.
Let’s examine a common methodology employed with verifying hardware and software together and where the traditional methodology breaks down. We’ll then look at how EDA vendors are offering modern FPGA-based prototyping systems in their HAV suites that bypass the shortcomings of the older methods.
The HW/SW, “chicken and egg” dilemma
On SoC projects, software development and testing can’t wait until silicon is available; on the other hand, embedded software development would need silicon to run on. As a result, design teams have come up with many techniques to make parallel development work. However, born out of necessity, one in particular has emerged over the years as the preferred methodology.
In this methodology, design teams attempt to separate the software stack into hardware-independent and hardware-dependent portions, separated by an operating-system layer and communicating through well-characterized APIs.
Typically, the larger hardware-independent code can be developed in a server environment with standard debugging techniques, using stubs to stand in for the APIs. Then the designers develop the hardware-dependent portion of the code, while the RTL design takes shape, using a hardware emulation system or perhaps even logic simulation as an execution environment.
But this methodology has its flaws. The first, and most obvious, is that it’s not always easy, or even possible, to determine which portions of the code are really hardware independent.
Dependencies accidentally created deep into the application code could go unnoticed, especially when intensive I/O and high computing loads must meet hard timing deadlines. And software developers often have to make some assumptions about execution speeds, cache sizes, and memory latencies—assumptions that may later prove false.
The second flaw of this older methodology is simply the combination of speed and capacity. In the older methodology, the integration and testing of the software with the RTL model of the chip is generally going to execute too slowly, even on an emulation system, to allow extensive exploration of the entire software stack. This leaves two options.
The first is waiting until first silicon is back and hope and pray all the bugs were caught; but hope is not a strategy and a software workaround or shut down part of the chip may not be feasible or acceptable. The second option is to move to a modern, success-oriented methodology that deals with shortcomings of the traditional hardware/software co-verification methodology.
This methodology is centered around hardware-assisted verification (HAV) solutions in general and FPGA-based prototyping in particular. Modern HAV technologies offer a much better methodology and higher likelihood of success that requires less stress and praying to a deity.
Addressing HW/SW co-verification bottlenecks
The end goal when deploying an HAV methodology is to ensure that not only is the SoC hardware functionally correct but that the software running on the SoC is optimized so the entire product meets spec and is optimized for best functionality, performance, and power. Ideally, the full software stack and the complete RTL design should be tested together as soon as both are sufficiently complete and stable to allow meaningful execution runs.
This gives the development team the opportunity to identify bugs and hardware/software interactions early, and before committing to silicon. And good version control ensures that the software team is working with the current RTL model and that the hardware team knows at once if they have just broken the software.
Speed of the HAV technology is the key. To test the full software stack on the SoC model realistically requires the use of an HAV technology, the FPGA-based prototype system. The model of the SoC under development is programmed onto the FPGAs of the prototyping system, allowing software developers to create software and run the software stack to ensure it works with the system.
An FPGA-based prototyping system will be able to run the full software stack on a realistic model of the SoC logic and memory, fast enough for intensive software and system validation. But what about the model’s interaction with the outside world? Verification requires seeing how the design behaves in continuous operation with real-world data.
In the past, many designs have attempted to circumvent the challenge of verifying their designs in continuous operations by trying to identify patterns of input data that will be most challenging to the system. They would synthesize those patterns as scripts and feed them into the prototyping system to observe its response. Unfortunately, this is ultimately a low-probability approach.
As years of development have illustrated, sometimes a bit too graphically, it’s just not possible to anticipate, for example, what streams of video from HD cameras are going to cause an AI system to miscategorize a traffic situation. And, as any communications engineer can attest, it’s equally impossible to predict the patterns of data that will appear on a real-world Gigabit Ethernet link or PCIe bus. As both ADAS and networking engineers have learned, a-priori analysis is no substitute for massive amounts of real-world data.
Ideally, verification engineers could connect the high-speed FPGA-based prototype directly to the cameras, sensors, actuators, and displays of the real system, and subject the system design to real-world data, in all its randomness, unpredictability, and at its natural speed. That could mean running the FPGA-based prototype system in a moving car, on a live network switch, or in a storage controller in a data center.
However, this raises another question: how to get at-speed or near-speed signals from the real world into the FPGA-based prototype. Design teams have tried several approaches, but once again, one solution is emerging.
Intuitively, it might seem reasonable to just implement the critical interfaces in the FPGA-based prototype. After all, the finished SoC will include those interfaces, so they are a real part of the design. And external networks, buses, and control signals could be connected directly into the prototyping system.
But there are serious issues with this approach. The first is that it will divert important design and verification resources away from the main design project. Yes, these interfaces will be present in the finished SoC, but they will almost certainly be implemented as third-party IP. Assuming that the third-party vendors have already been selected, they may or may not provide FPGA models of their IP for a particular FPGA family.
The models may or may not be accurate reproductions of the ASIC interface blocks’ functionality and will certainly differ in timing. Implementing these interface blocks in the FPGA and verifying them potentially becomes a significant FPGA design project in its own right, drawing on critical interface and FPGA skills that are needed elsewhere in the design.
An alternative is to design external interface adapter cards to connect the real-world signals into the prototype system. Such an adapter can run at full real-world speed on the real-world side, and at the speed required by the FPGA-based prototype on the prototype side. But again, there are significant challenges.
To begin with, no high-speed interface adapter is a trivial design, including power considerations, clocking, board design, connector or cable signal integrity, and so on. Then there is the matter of getting the signals back and forth between the adapter card and the prototype system.
Running cables to the system backplane will introduce timing and signal-integrity questions and will require precise understanding of the FPGA-based prototyping system’s internal design. Designing daughter cards to attach directly to expansion connectors or to the FPGA cards themselves within the prototyping system will require an even more detailed understanding of the system’s electrical, mechanical, and thermal requirements.
A modern solution
Take the case of a family of off-the-shelf extension boards for the Veloce proFPGA CS system. It includes I/O adapters for a range of interfaces, including Gigabit and slower Ethernet, PCIe GEN4, USB, DDR4, various Flash memory interfaces, and a range of connector configurations for bringing the FPGA I/O signals out of the box. Such an I/O board, for example, combines Ethernet on an RJ45 connector, a USB connector with UART, a MIPI 60 connector, and a GPIO header, along with user-definable LEDs.
Figure 1 The Veloce proFPGA CS platform is an entry-level solution in which the UNO desktop system delivers FPGA-based prototyping. Source: Siemens EDA
The extender cards plug directly onto connectors on the Veloce proFPGA CS FPGA boards, minimizing latency and signal-integrity issues. This also saves the user from having to provide external clock and power sources for the boards. Supporting software seamlessly integrates the extension boards into the Veloce proFPGA CS development environment.
Figure 2 The Veloce proFPGA CS boards can be adapted and expanded with the latest FPGA generations and extensions cards equipped with interconnections, interfaces or memories. Source: Siemens EDA
The result is that users can quickly connect an SoC prototype on the Veloce proFPGA CS into the actual environment in which the finished SoC will operate, with the interfaces operating at or near full speed. Software developers can instrument and observe the full software stack executing in the real world, not within the confines of synthetic tests. Hardware engineers can observe hardware/software interactions with live, real-world data at high speeds.
Juergen Jaeger is director of prototyping product strategy at Siemens EDA.
Related Content
- The Growing Use of Hardware-Assisted Verification
- The Case for Hardware-Assisted Verification in Complex SoCs
- Can Hardware-Assisted Verification Save SoC Realization Time?
- Hardware-Assisted Verification: The Real Story Behind Capacity
- Hardware-Assisted Verification: Ideal Foundation for RISC-V Adoption
The post Enhancing SoC HW/SW co-verification with FPGA-based prototyping appeared first on EDN.