Debugging simulations vs. emulations/prototyping[edit]
It is worth noting that simulation and prototyping involve two different styles of execution. Simulation executes the RTL code serially while a prototype executes fully in parallel. This leads to differences in debugging. In simulation:
- The user can set a breakpoint and stop simulation to inspect the design state, interact with the design, and resume simulation.
- The user can stop execution "mid-cycle" as it were with only part of the code executed.
- The user can see any signal in the design and the contents of any memory location at any time.
- The user can even back up time (if they saved checkpoint(s)) and re-run.
With a prototype:
- The user employs a logic analyzer for visibility, and so can see only a limited number of signals which they determined ahead of time (by clipping on probes). This is changing with emerging FPGA prototype tools that provide full visibility to 10,000s of internal signals, such as Certus.[2]
- The target does not stop when the logic analyzer triggers, so each time the user changes the probes or trigger condition, they have to reset the environment and start again from the beginning.
- Probes are added directly to the RTL design to make specific signals available for observation. When the system is run, the RTL-based probe connected to each of the instrumented signals collects the signal's value at each clock cycle. The data is stored in a trace buffer in FPGA block RAM. An analyzer connected to the prototype downloads the information giving the user offline visibility into the system for efficient debug.[3]
Acceleration and emulation are more like prototyping and silicon in terms of RTL execution and debugging since the entire design executes simultaneously as it will in the silicon. Since the same hardware is often used to provide both simulation acceleration and in-circuit emulation, these systems provide a blend of these two very different debugging styles.
High end hardware emulators provide a debugging environment with many features that can be found in logic simulators, and in some cases even surpass their debugging capabilities:
- The user can set a breakpoint and stop emulation to inspect the design state, interact with the design, and resume emulation. The emulator always stops on cycle boundaries.
- The user has visibility to any signal or memory contents in the design without the need to set up probes before the run. While visibility is provided also for past time, the amount of time that it can show in the past might be limited in some cases to the depth of the emulator's trace memory.
- The user can even back up time (if they saved checkpoint(s)) and re-run.
- Because of their high cost, emulators are beyond the reach of many developers, leading to the rise of advanced FPGA prototyping platforms and debug tools..
Emulation and 2-state logic[edit]
Another difference between simulation and acceleration and emulation is a consequence of accelerators using hardware for implementation – they have only two logic states – acting the way the silicon will when fabricated. This implies:
- They are not useful for analyzing X-state initialization.
- They cannot analyze strength resolution, or at least this must be done statically at compile time.
- Emulators do not model precise circuit timing, and hence they will probably not find any race conditions or setup and hold time violations.
These tasks are properly carried out during logic simulation or with a static timing analysis tool.
Emulation versus prototyping[edit]
A key traditional distinction between an emulator and an FPGA prototyping system has been that the emulator provides a rich debug environment, while a prototyping system has little or no debug capability and is primarily used after the design is debugged to create multiple copies for system analysis and software development. New tools that enable full RTL signal visibility with a small FPGA LUT impact, allow deep capture depth and provide multi-chip and clock domain analysis are emerging to allow efficient debug, comparable to the emulator.[2]
See also[edit]
You received this message because you are subscribed to the Google Groups "1TopReadys1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 1topreadys1+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/1topreadys1/CAForgrTk--RQWNwJ7csLdjmDtY0vY4QKDzTZWBsN_%2ByNpLccsg%40mail.gmail.com.
No comments:
Post a Comment