22-08-2012, 12:25 PM
Hardware prototype:
VAT.docx (Size: 273.68 KB / Downloads: 31)
Hardware prototypes are hardware systems built to replicate the real system environment using programmable hardware, such as FPGAs. Hardware prototypes might provide the most high-performance solution for system verification, but also require the most work. The process begins with developing the prototype system. In most cases, the prototype system must be built or modified for system verification use. The prototype system requires a tested board with standard interface components, along with observation interfaces. The digital implementation is placed in programmable hardware. The analog and mixed-signal subsystems are implemented on the board.
Once the system is built and debugged, the design is compiled into programmable hardware devices, and system clock speeds are chosen to meet the timing of the compiled implementation. The subsystem teams might have already verified that the blocks map correctly into programmable hardware as part of the block-hardening process. Stimulus is provided through the prototype system board and can be driven through test equipment, external workstations, or networks. Software loading and debugging are done in the same manner as the real system. Service processors can be used to boot the system, and software debuggers connected through JTAG interfaces can be used to debug the software. The response checking is done in a manner similar to the real system. Response to the stimulus can be captured for analysis by test equipment, or the application can be tested to the user requirements.
Emulation :
In-circuit emulation provides the highest run-time performance for regression testing, hardware-software co-verification, and system-level verification. In-circuit emulation replaces the testbench with physical hardware, which is typically the system for which the IC is being designed. Working at the system level, in-circuit emulation verifies the IC as it interacts with the system, which includes system firmware and software. Rather than using testbench generated stimulus, which is often limited in scope, in-circuit emulation is able to use live data generated in a real-world environment.
RTL Analysis (LINTING) :
RTL analysis tools take the design RTL as input and analyze the code for bugs, without a testbench or specification of properties.
These tools use a variety of methods for performing this analysis, including formal techniques.
The major deficiency in most RTL analysis tools is the trade-off that must be made between accuracy of the check and the chance of incorrect errors being reported . These tools cannot infer all the information necessary to absolutely guarantee that the issues found are real bugs.
The simplest form of RTL analysis tools parse the code and identify issues from the textual representation of the design. These tools can find typographic and syntax errors that might result in incorrect connections or missing logic. Unfortunately, simply parsing the text does not provide enough information to detect more complex bugs without the risk of reporting many false violations. Early tools that focused only on the text were infamous for reporting thousands of violations that were not real errors.