Design Article
Hardware/Software integration: Closing the gap
Tom Huang, Pete Mar, InPA Systems inc.
3/13/2011 6:08 PM EDT
Introduction
In recent years, system integration associated with System on Chip (SoC) design has grown at a rapid rate and continues to drive the semiconductor design market. Although this growth has been beneficial for the design community, the sophisticated and complex manufacturing requirements of next generation devices have increased the cost of ASIC and ASSP development. Product implementation of complex, low-power designs requires early integration of various hardware features with corresponding firmware onto one silicon device. The reduced lifespan of current products have condensed SoC development cycles and have made the SoC verification and in-system validation process an arduous task. The bulk of time spent during the product development cycle of SoCs is often in hardware/software integration and has brought in-system validation to the forefront of this extensive process.
Hardware/Software development environments
Virtual platforms provide application software developers a head start towards interfacing with the IP and writing essential algorithms. Firmware can be written to interface with the fabric logic and enable the architecture, instruction set, memory, interrupt and important aspects of the design can be solidified prior to freezing the RTL. However, abstract models force developers to maintain separate versions of the firmware code to support both the virtual and hardware platforms. Although interface-modeling software is often employed, early access to hardware provides deterministic results to ensure functionality and verify the development is aligned.
In parallel with early software development, RTL logic functionality is defined, and then verified through logic simulation. This method becomes more tedious and difficult later in the design cycle as the design grows and the entire system needs to be verified. Methods such as RTL simulation and emulation are common practices, however, their advantages are offset by the cost of speed. Logic simulation provides high visibility into important nodes but run magnitudes slower than a design’s real-time speed. Emulation is faster than simulation and the high cost of such systems may be prohibitive.
The verification design gap
Software development tools and debuggers execute code rapidly, from setting breakpoints to stepping through instruction code with no delay. Although these debuggers execute in real-time or near real-time, software tools cannot provide visibility into the hardware other than some registers and memories. Verilog and VHDL simulators provide nearly full-node visibility into the hardware on a cycle-by-cycle basis via waveforms for debugging. However, compared to software development tools, HDL simulation/execution time is typically four to five orders of magnitude slower than virtual platform. HDL simulation can only generate data a few thousand cycles per second, which is too slow to enable debug of the firmware.
In recent years, system integration associated with System on Chip (SoC) design has grown at a rapid rate and continues to drive the semiconductor design market. Although this growth has been beneficial for the design community, the sophisticated and complex manufacturing requirements of next generation devices have increased the cost of ASIC and ASSP development. Product implementation of complex, low-power designs requires early integration of various hardware features with corresponding firmware onto one silicon device. The reduced lifespan of current products have condensed SoC development cycles and have made the SoC verification and in-system validation process an arduous task. The bulk of time spent during the product development cycle of SoCs is often in hardware/software integration and has brought in-system validation to the forefront of this extensive process.
Hardware/Software development environments
Virtual platforms provide application software developers a head start towards interfacing with the IP and writing essential algorithms. Firmware can be written to interface with the fabric logic and enable the architecture, instruction set, memory, interrupt and important aspects of the design can be solidified prior to freezing the RTL. However, abstract models force developers to maintain separate versions of the firmware code to support both the virtual and hardware platforms. Although interface-modeling software is often employed, early access to hardware provides deterministic results to ensure functionality and verify the development is aligned.
In parallel with early software development, RTL logic functionality is defined, and then verified through logic simulation. This method becomes more tedious and difficult later in the design cycle as the design grows and the entire system needs to be verified. Methods such as RTL simulation and emulation are common practices, however, their advantages are offset by the cost of speed. Logic simulation provides high visibility into important nodes but run magnitudes slower than a design’s real-time speed. Emulation is faster than simulation and the high cost of such systems may be prohibitive.
The verification design gap
Software development tools and debuggers execute code rapidly, from setting breakpoints to stepping through instruction code with no delay. Although these debuggers execute in real-time or near real-time, software tools cannot provide visibility into the hardware other than some registers and memories. Verilog and VHDL simulators provide nearly full-node visibility into the hardware on a cycle-by-cycle basis via waveforms for debugging. However, compared to software development tools, HDL simulation/execution time is typically four to five orders of magnitude slower than virtual platform. HDL simulation can only generate data a few thousand cycles per second, which is too slow to enable debug of the firmware.
Reducing the SoC development gap
As the delay in development time effects are more prominent amongst software developers, current tool offerings allow software developers to integrate hardware models with all of the interfaces into virtual platform. Hardware developers can implement various methods to make a hardware model available for software testing. Fortunately, FPGA vendors have steadily developed robust features, which have a vital role in making FPGA-based SoC prototypes a mainstream vehicle to aid designers with hardware verification and software development. FPGAs have increased in complexity with key features critical for prototyping such as increased amounts of memory and IP as well as system interfaces to DDRAM, PCIe, Ethernet and high-speed serial interfaces of over 10 Gb/s. Capacities of the largest FPGAs have grown to a point where SoC prototypes may even be created in a multi-FPGAs. Real-time speeds of an FPGA prototype and capacities are amongst the main reasons FPGA-based ASIC prototypes have thrived and continue to grow as a methodology.
Detection of software bugs can take over 50 percent of the overall software development time since developers must not only locate the problem in the code, but also resolve the issue without introducing other errors. With early access to an FPGA prototype, firmware developers can implement runtime and automatic debuggers to detect memory corruption and other runtime errors. Firmware development during the bring-up phase of an FPGA prototype and continued debug access throughout the verification process is critical.
Logic simulation has long been a method of RTL design verification due to cost efficiency and great signal depth. However, this methodology is magnitudes slower than the design’s clock speed. Access to an FPGA-based SoC prototype provides a platform that can run very fast, however, due to pin limitations and available local memory, visibility in FPGA-based prototypes is restricting. Vendor tools which implement the design into hardware is also limiting, as any RTL change requires P&R to be re-executed, which consumes numerous hours to run.
A combination of the benefits of logic simulators’ high-visibility and the real-time speeds of a prototype greatly enhance the software/hardware integration process. The InPA Full Visibility Technology offers full signal visibility during the vector simulation and in-circuit operations. Vector simulation captures all of the input vectors from the simulation test bench and reads the output vectors from the FPGA prototype. A snapshot of all design registers and memory in the FPGAs is taken and used by the InPA Technology to initialize vector simulation. This vital information is stored in a vector database, which enables the InPA Technology to reconstruct all the signals, thus, providing the same visibility as an RTL simulator, magnitudes faster. This same technique is used in the in-circuit operation (where the stimulus is not the test-bench but actual interfaces) with the added vectors that are being captured at full FPGA speed. Faulty vectors in the FPGAs are captured and stored in the InPA Technology vector database along with the other signals of the design. Similar to the vector simulation mode, all signals are visible.
As the delay in development time effects are more prominent amongst software developers, current tool offerings allow software developers to integrate hardware models with all of the interfaces into virtual platform. Hardware developers can implement various methods to make a hardware model available for software testing. Fortunately, FPGA vendors have steadily developed robust features, which have a vital role in making FPGA-based SoC prototypes a mainstream vehicle to aid designers with hardware verification and software development. FPGAs have increased in complexity with key features critical for prototyping such as increased amounts of memory and IP as well as system interfaces to DDRAM, PCIe, Ethernet and high-speed serial interfaces of over 10 Gb/s. Capacities of the largest FPGAs have grown to a point where SoC prototypes may even be created in a multi-FPGAs. Real-time speeds of an FPGA prototype and capacities are amongst the main reasons FPGA-based ASIC prototypes have thrived and continue to grow as a methodology.
Detection of software bugs can take over 50 percent of the overall software development time since developers must not only locate the problem in the code, but also resolve the issue without introducing other errors. With early access to an FPGA prototype, firmware developers can implement runtime and automatic debuggers to detect memory corruption and other runtime errors. Firmware development during the bring-up phase of an FPGA prototype and continued debug access throughout the verification process is critical.
Logic simulation has long been a method of RTL design verification due to cost efficiency and great signal depth. However, this methodology is magnitudes slower than the design’s clock speed. Access to an FPGA-based SoC prototype provides a platform that can run very fast, however, due to pin limitations and available local memory, visibility in FPGA-based prototypes is restricting. Vendor tools which implement the design into hardware is also limiting, as any RTL change requires P&R to be re-executed, which consumes numerous hours to run.
A combination of the benefits of logic simulators’ high-visibility and the real-time speeds of a prototype greatly enhance the software/hardware integration process. The InPA Full Visibility Technology offers full signal visibility during the vector simulation and in-circuit operations. Vector simulation captures all of the input vectors from the simulation test bench and reads the output vectors from the FPGA prototype. A snapshot of all design registers and memory in the FPGAs is taken and used by the InPA Technology to initialize vector simulation. This vital information is stored in a vector database, which enables the InPA Technology to reconstruct all the signals, thus, providing the same visibility as an RTL simulator, magnitudes faster. This same technique is used in the in-circuit operation (where the stimulus is not the test-bench but actual interfaces) with the added vectors that are being captured at full FPGA speed. Faulty vectors in the FPGAs are captured and stored in the InPA Technology vector database along with the other signals of the design. Similar to the vector simulation mode, all signals are visible.
|
|
|
|
|
Navigate to related information
ani593
3/17/2011 4:29 AM EDT
good one
Sign in to Reply
DKC
3/31/2011 3:51 PM EDT
Maybe the problem is that you are still designing at the RTL level.
http://parallel.cc
Sign in to Reply