Is FPGA Prototyping really optional?
We conducted a survey on LinkedIn 2 weeks ago about the usage of FPGA prototyping vs. Emulation vs. Simulation. By no means this survey is representative of the whole industry – the sample is simply too small and probably biaised, as the question was asked to Exostiv Labs’ followers on LinkedIn. You can see above the results of this modest poll.
However, I have been reflecting about whether not using any of FPGA prototyping or emulation is still a viable option these days.
Tackling complexity has always been the job of engineers as well as EDA and instrumentation companies. Yes, this has been – and still is – one of the reasons for design reuse. It is no wonder why large EDA companies have also become large IP providers.
To deliver a high quality IP – and enable real reuse when building system-on-chip, the EDA tools at each stage of the IP development aim at:
- Running more cycles of operation, and:
- Subjecting the IP to end-product-like operating conditions.
Of course, creating a system that ‘works’ supposes that each of its building blocks also work properly. High complexity brings in high requirements in terms of number of cycles in service first – as described in this great article, that we have already referenced multiple times: ‘Deep cycles’ by Bryan Dickman and Joe Convey.
Further on, when the IPs are assembled to form a complete SoC, the 2 above requirements also apply. At this point, the goal is more to verify the functionality of the system as a whole – and check if the selected IPs harmoniously work together.
Simply put, this just cannot be done with simulation-based techniques alone.
As we have already evoked in past articles, the trends towards a general adoption of code coverage measurement, constrained random stimulus, a sharable verification plan and other simulation-based techniques have (probably) been the source of more efficiency at companies having to manage the verification of complex FPGA with larger teams. However, the hard truth is that the adoption of these techniques have not significantly resulted in a lower number of bug escapes to production (see the 2020 Wilson Group functional verification study)
So, is there any takeaway from the poll?
First, with 69% of our respondents using FPGA for prototyping (not especially themselves, but someone in the team does), I feel more comfortable that the above ideas are widely shared… (and yes, that’s great, because what we do at Exostiv Labs is adding the visibility to the FPGA prototype, which is another key of it – we’ll come back to this later). Okay okay, this does not cover the whole industry – and I promise that I’ll try to find representative numbers.
Second, there may be cases where simulation alone could be just what’s needed. After all, this poll was quite generalist. I am not sure that FPGA prototyping is very useful if what you design are radiation-hardened IP…?
Finally, I retrieve the usual rivalry ’emulation’ vs. ‘prototyping’, with – like one of my colleagues told me once – emulation being the prototyping of the rich… Right? Well, not so quick. In terms of number of executed cycles before production, FPGA prototypes will run 10x or 100x more of them than emulators. In addition, you can buy at 10 prototypes for the price of one single emulator. So, to run massive test cycles, you might want to consider FPGA prototyping AND emulation as 2 complementary tools rather than competing ones…
As always, thank you for reading.
– Frederic.
