Richard Goering recently commented on the need for "Acceleration and Emulation and Why HW/SW integration needs both".This article defined and promoted acceleration and emulation as a good middle ground between Virtual and FPGA prototyping. Virtual models suffer from inaccuracy whilst FPGA suffers from poor debug.
The following HW/SW interface models were mentioned
- The software : Which needs a model of the Hardware
- Virtual Models : Mentioned only briefly - probably TLM.
- Acceleration : Design is a HW model (RTL) running on a simulator. TB is optimized on simulator (e.g. OVM TLM)
- Emulation : Design is a HW model (RTL), running on an emulator. TB running on emulator.
- FPGA Prototyping : Design is a HW model (RTL) on an FPGA.
I like Richards high-level diagram which shows the main technologies for HW/SW integration but for me a stronger story emerges. All of these environments have their own pros and cons which, with next generation chip design complexities and aggressive product cycles, probably all will be needed. The question will not be which of these technologies to use but how to use all of them together. The basic unit of HW/SW interface accuracy is the register so what we need to ensure is that all the models (e.g. firmware model, virtual, TLM, RTL, HVL models) are fully aligned. In order to facilitate smoother HW/SW integration right throughout the design flow, we need register management tools like Socrates Bitwise to keep the models aligned and reduce time spent in debug.
I think that acceleration and emulation are a good bridge between Virtual and FPGA prototyping but model management and centralization is key to the smooth transition between these technologies.

"Virtual models suffer from inaccuracy whilst FPGA suffers from poor debug"
Is this a statement you agree with? I've been using Altium Designer for a while. There are vast arrays of things that can be done to debug on an FPGA. I run CPUs inside which I can step line by line and view variables and memory. I can run virtual instruments and collect data with soft logic analyzers, use frequency counters, all sorts of things to aid in debug. Can you clarify what you mean by poor debug?
Posted by: Mike | 04/28/2010 at 04:00 PM