In the field of verification, virtual probes enhance the appeal of hardware accelerated simulation as a data center resource to hardware designers and software developers.
Hardware accelerated simulation continues to prove itself as a convenient tool for both hardware/software co-verification and for testing hardware and software integration.
Starting an operating system and executing a software application requires billions of verification cycles—traditional software-based analysis tools are not up to the task. Only hardware-based verification engines provide the throughput needed to meet this challenge. Because of this, hardware accelerated simulation and FPGA prototyping will become a must-have engine in the validation toolbox of today's design and verification teams.
With hardware-accelerated simulation and FPGA prototyping, embedded software developers can validate embedded software and perform system verification, an attractive feature. Only through hardware-accelerated simulation can they confirm that embedded system software can work with the underlying hardware because FPGA prototyping does not provide hardware design visibility to debug internal work.
In addition, during the design cycle, project team members can use hardware-accelerated simulations typically much earlier than when using FPGA prototypes. Therefore, using hardware-accelerated simulation technology, the software development team began to verify earlier than when using an FPGA prototype.
Hardware engineers can also recognize the benefits of running software on hardware accelerated simulation. When an actual software product runs on hardware for the first time, it almost always exposes hardware errors, and even the most comprehensive verification method misses some errors. Running the software early can expose these errors so that we can resolve them. This is not only simple but also low cost.
Physical probe
In the past, software developers used physical JTAG probes to debug code that runs on hardware accelerators (Figure 1). The JTAG standard defines a series of signals and methods for reading and writing registers in a physical chip through a four-pin interface. The original intention of this approach is to provide a way to test the chip, let the test engineer snoop inside the package chip to confirm that it is working properly.
Software developers realize that they can use the same interface to read and write to the general-purpose registers of the processors in the chip. Being able to read and write to the processor's main registers means that they can debug programs running on the processor.
With some clever interfaces, they can use an embedded debugger (such as Lauterbach's Trace-32 or ARM's DS-5) to send commands to the JTAG probe to extract or set the onboard processor connected to the probe. status. This is the most common way for developers to run and debug "bare metal" programs and drivers on embedded systems.
With today's hardware-accelerated emulation systems, any signal of the design can be output through any I/O card connected to an external device. This method can be used to output four signals from the JTAG interface. By connecting these signals from the design in the hardware accelerator to the JTAG probe, the software developer can perform the same debugging work on the prototype board as the hardware accelerated simulation design.
Since the JTAG probe will be used on the prototype board later in the design and may be used in subsequent projects, software developers generally understand how and why the probe is used. Software developers naturally use this familiar tool when debugging software on hardware-accelerated simulation designs.
Although the JTAG interface allows the debugger to read and write registers directly, to properly debug the program, you need to be able to read and write to memory and control program execution. To meet this need, the processor designer added registers that the debugger can access to insert memory read and write instructions into the execution pipeline. This way, the debugger has full access to all memory and memory mapped devices in the design.
In addition, these designers have used breakpoint registers and other debug support circuits to allow the JTAG debugger to control program execution. This means that by connecting to the processor's JTAG, the debugger can display the program source code, the processor's registers, memory, variables, and the stack of programs. As a result, the debugger is able to set breakpoints, run and single-step debuggers, which are what software developers expect from modern software debugging environments.
Handling JTAG probe issues
Although the JTAG probe implements software debugging on a hardware accelerated simulation design, it also has drawbacks. First, JTAG probes and designs that run in hardware accelerators have their own self-excited clocks. In order to maintain synchronization, these clocks must maintain a consistent speed. If this is not possible, the connection between the debugger and the design will be lost.
In many cases, the probe needs to be reset; in some cases, the design itself will need to be reset. Sometimes it is useful to slow down or even stop the design clock in the hardware accelerator because it captures and uploads the waveform on the design. This way, the developer can view the state of the design or force a design to transform it to a new value. In essence, hardware developers will lose a lot of hardware debugging if the clock on the hardware accelerator cannot be slowed down or stopped.
The second problem with using JTAG probes is performance. Since there are two separate clock domains, one on the hardware accelerator and the other on the probe, the data will be passed between the two domains, which creates a cross-clock domain problem. To solve this problem, the clock speed on the probe is usually lower than the clock speed of the processor. On the prototype board, the processor's hour hand speed can reach hundreds of megahertz or even gigahertz, which is not a problem. However, in hardware accelerated simulation, the clock runs at a rate of one megahertz or two megahertz, which may slow down the speed a lot.
For example, running a single instruction step by step in the ARM Cortex-A57 requires more than 4 million bits of JTAG scan chain activity. If the processor's clock is running at 2 MHz and the JTAG clock is one-fourth of its frequency, which is 500 kHz, it takes 8 seconds to update the view in the debugger after the step-by-step operation.
Another performance issue is the program download time. The software developer uses the scan chain to download the program to the target via the JTAG probe. If the program is large, it can take an hour or more to load the program into memory. Most software developers cannot accept this level of performance.
JTAG transaction processor
There is a way to use the JTAG debugger to eliminate these problems. The hardware-accelerated emulation system can drive and sample any signal in the design through the built-in programming capabilities of the circuit and hardware accelerators. Instead of using an I/O card to acquire signals from the design and then driving them with physical probes, we can use a "transaction processor" to programmatically drive the JTAG signals in the design. Like a physical probe, a transaction processor can also drive the same signal to transform it to the same value, providing the same debugging capabilities.
Since the design and JTAG transaction processor are both under the control of a hardware accelerated emulation system, the clock is controlled by a hardware accelerator. The clock domain can be synchronized, thus eliminating the problem of multiple clocks.
American Wall Switch And Socket
Wenzhou Niuniu Electric Co., Ltd. , https://www.anmuxisocket.com