Systems on Chip (SoCs) integrate increasingly complex hardware features with even more complex software applications, which makes validating SoCs a challenging task. FPGA-based prototyping has become an increasingly popular way of validating SoCs, for good reasons: FPGA devices have enough capacity to fit complex ASICs, and run fast enough to interact with real world interface systems (e.g., Ethernet, PCI).
However FPGA-based prototyping is impaired by a complex setup, and its limited debugging capabilities leads to iterate costly place-and-route runs. The setup phase, or “bring-up” phase, partitions and maps the SoC into a multi-FPGA board. This is a complicated process, and verifying that the RTL has been properly mapped into the board is no small feat. Once that verification is done, system-level debugging can begin. A faulty behavior must first be identified as a software or hardware issue. Since the software and hardware debugging tools are disjointed, identifying the actual source of a problem a tedious task. Debugging the RTL is time consuming because a traditional FPGA prototype environment offers no visibility in the FPGA, and every time an ECO is applied, place-and-route must be run again.
InPA Systems proposes to address some of these limitations. The company claims that today’s trial-and-error debugging method can be significantly improved upon when software and hardware debuggers are synchronized with InPA’s “active debug” method, which can easier identify the source of issues at run time. The lack of visibility into the FPGA as well as a loose cross-reference between RTL code and multiple FPGAs makes debugging very complicated. InPA promises “full visibility” of signals, allowing users to capture complex scenarios when running the design at speed, so that they can analyze system faults more thoroughly and easily.
Reading more in depth, this how I understand what InPA is proposing:
- Integrate the RTL simulation and FPGA prototype environments to automatically verify that the mapping of the RTL into the multi-FPGA board is correct. This reduces substantially the cost of the “bring up” phase, which is usually done with a much slower gate-level simulation.
- Integrate the software and hardware debug environments so that engineers can catch issues easier when integrating both software and hardware in the FPGA prototype environment.
- Current prototype methods can capture the signals associated with a faulty condition, but they cannot do this over multiple FPGAs. Isolating a hardware problem in a RTL code that has been mapped into multiple FPGAs is then extremely complicated. InPA uses the same integrated environment to bring the user with full visibility of the signals, as well as cross-link of the RTL, across multiple FPGA. This helps identify the origin of faults in a much efficient manner.
The figure below shows how InPA showcases its “Active Debug” and “Full Visibility” technology. It uses hardware and software to enable full visibility into the FPGA design. It integrates the custom or off-the-shelf FPGA prototype environment (FPGA netlist and circuit board) with the simulator environment so that the user can see inside the design during verification. The Embedded Vector Processor Interface (EVPI) is inserted along with the Design Under Verification (DUV) into the FPGA to facilitate the communication between the simulator and the DUV. The debugging interface captures stimulus and response vectors for regression tests and debugging. InPA provides a close control of the debugging process by giving users an extensive triggering capabilities with its Embedded Micro Machines (EMMs), which can capture faulty conditions over multiple FPGAs and make signals fully visible –no FPGA recompilation required. I must admit that this part is bit obscure –does that mean that all RTL signal are preserved upfront, or that enough signal redundancy is kept to reconstruct any internal signal?
InPA Systems was founded in October 2007 by two emulation and verification EDA veterans, Thomas Huang, CTO, and Michael Chang, CEO. Notable in InPA’s business model is that the company offers an open system, supporting all popular fixed “off-the-shelf” prototype systems as well as custom prototype systems. The company expects to start beta testing with a few close prospects in late Q3’10, and to make its first product available in Q4’10. No doubt we will hear more from this company in the next few months.