Register Bits

Using an FPGA vendor’s “Starter Kit” is a great way to get an even quicker headstart on prototyping a design. One can get things roughly working in say Modelsim while waiting on the starter kit, and then get things working post synthesis with the starter-kit long before one commits to even a prototype board.

Hi William, I agree. One can get started on the RTL logic early with a logic simulator. The inital firmware can be created without the RTL and IP blocks by ensuring good hardware abstraction and mocking some of the HW IP behavior in C/C++.

In the absence of a physical FPGA, it’s ideal to get the firmware running and interfacing with the fabric logic. I see the vendors do provide instruction set simulators (ISS), but I’m not sure how well these can tie in with a logic simulator. The goal is fast behavioral modeling of the processor that will run the firmware in step with RTL simulation of the fabric logic. One big concern is how fast a processor model would run while connected to the logic simulator.

Emulation is another way to get things running without the physical hardware, if you have deep pockets. Here is a related posting from Ralph Zach at a Mentor blog:

Emulation 101 – SoC Emulation vs. Prototyping: What’s the Difference?

http://www.mentor.com/products/fv/blog/post/emulation-101-soc-emulation-vs-prototyping-what-s-the-difference–8c757c3b-c4df-4475-8af1-ab24d1e6ff56

This shouldn’t be an either/or situation, I have worked on projects that involved both approaches at different points in the evolution of a project. Virtual prototyping, we used Mentor’s Seamless CVE to run incremental releases of our SoC as it evolved. We were able to get going on diagnostic and driver development while gathering hardware for FPGA prototyping. For some of the software, we had the basics in place but the parts and their function were pretty large and intensive, so we had to cross over to FPGA prototyping in development for performance reasons. With ESL, there is the ability to develop larger, more complex software on the virtual prototype but as we get down to detailed, lower levels of abstraction (behavioral, RTL), there will be a more pressing need to cross over to FPGA rather than remain on the virtual prototype. Even on modern desktops with fast CPU’s, multicore architectures, maybe even multithreading in EDA tools, the scale of the design will slow down the virtual prototype’s execution.

I personally would never go to market without a robust simulation environment coupled with custom FPGA prototyping. You are talking about a few thousand dollars to build a few custom test boards, and maybe $10k-$20k in NRE for design and layout. This is the ideal platform for co-design including driver/firmware development.

I’ve never found an “off-the-shelf” FPGA prototype solution that had much value. They always require compromises and workarounds that can be avoided by doing the prototype board design.

Abstracted models have limited value, in my opinion. They are too slow to allow software developers to properly build real-time code, and they burden developers with the need to maintain two descriptions in parallel with limited opportunity to prove equivalence.

Emulation has an advantage shared with virtual prototyping, and that’s the capability to analyze elements (nodes) within a design. As a Seamless user, I am biased towards virtual prototyping because I can get to any node. From Ralph Zach’s response on the Mentor blog, their emulator offers access to most. In either case, the hardware architecture is preserved while with FPGA prototyping, a design has to be repartitioned to fit each of your available chips. If you discover a problem in (e.g.) timing of data between two blocks, each on different FPGA chips … is the problem with your design, or the prototyping platform (i.e., offchip communications overhead)?

Worse, imagine the horror when you discover that a large functional block cannot fit onto the device technology that you have available for prototyping!!