What do you use FPGA prototyping for?

FPGA prototyping

Typical usages of FPGA prototyping

FPGA Prototyping is used for various purposes. Here are 2 of its main usages:

  • FPGA Debug: at some point of the FPGA design cycle, tests have to be run with a ‘real’ FPGA board to find the remaining bugs left undetected by simulation-based verification techniques.
  • SoC & ASIC Validation: before going to production, the ASIC gates get mapped onto FPGA gates. It can serve many purposes, from debugging the hardware to providing a software development platform for a future SoC. The term ‘FPGA Prototyping’ is also generally understood as ‘FPGA Prototyping of ASIC or SoC’ – or even ‘ASIC prototyping’.

Because FPGA protypes potentially run much faster than emulators and simulators, they are well suited to run extensive number of cycles. For this reason, they are crucial tools to increase the confidence that an FPGA, ASIC or IP is delivered without bugs in a maximum number of configurations. Regression testing is therefore a key application of FPGA prototyping as well.

How do requirements differ according to usage?

We found out that at least 3 dimensions characterize each usage. The relative importance of these dimensions defines the type of FPGA prototyping platform that should be used – and the requirements for the tools used with it.

Dimension 1: At speed operation

The first dimensions is whether the prototype should run at – or close to – the target speed of operation. Actually running a prototype at speed only has advantages. First, such a protoype is a more faithful image of the future system. Second, ‘at speed’ allows running the prototype in the target environment without having to use tricks to slow it down. Finally, the number of cycles executed per second is much higher, resulting in a better coverage. Usually, lowering the speed of a prototype is not a desired feature, but just a constraint that comes from:

  • Partitioning: it creates data ‘bottlenecks’ at the interfaces between the FPGAs, forcing to reduce the system frequency.
  • FPGA technology: if the prototype uses an slower (outdated?) process, there are chances that it won’t run at the target speed of the ASIC, for instance.
  • Tools capabilities: when the tools provided with the prototyping environment cannot operate beyond a specific frequency, this limitation falls back onto the prototype as a constraint.

Among the typical applications, validating the operation of specific IP that interoperate with external equipment is the one that is the most likely to run at speed of operation. An IP is smaller than a whole system and usually fits into a single FPGA. If we restrict to this portion of the SoC, there is no partitioning constraint. When the latest FPGA technologies are used, the speed can be very high, at, or very close to the future chip where the IP is integrated. When the prototype runs an interface IP, running at speed can even be a necessity – especially when testing the IP against a set of real-world peripherals that cannot be slowed down.

Partitioning and tools limitation can make running a FPGA prototype at full speed of operation simply impossible, even with the latest FPGA technologies. Usually, designers are able to accommodate for a lower speed. Worth noting, even at 1/100th or 1/1000th of the target speed, FPGA prototypes are still faster than most emulators.

Dimension 2: Required nr of gates

The size of the prototyped design impacts the required number of gates. When you have exceeded the size of the largest chip in a specific FPGA technology, you then need to partition. To limit this, you should use the largest chip available. This conditions the type of FPGA prototyping setup that you’ll be able to use – and can limit your choices. While smaller FPGA boards are numerous on the market – or can even be designed at a reasonable cost – large prototyping systems with FPGA in a mesh and the ad-hoc partioning capability are more a specialty or larger EDA companies. When a FPGA-based system or an IP is designed, there is more freedom in buying designing the board that *exactly* fits the prototyping needs.

Whether you are limited in your board choice or not, the question of the tools remains: which tool can you use with a platform to verify design and are they sufficient for your needs?

Dimension 3: Necessity of observation at bit level

What will you really do with the prototype? What do you need to look at and what is the key functionality that you’ll need to perform best? ‘Execution’ seems to be the primarily function of a prototype: it has to run like the target design – and this has either a verification or a design purpose. The design must work according to its specification: this includes an observation at the ‘hardware level’. The other main purpose would be to be able to design software – and the prototype is the first platform that the software runs on at an acceptable speed.

In most instances, ASICs are an assembly of IP building blocks which *should* have been verified already. (Otherwise, IP-based design which we have use over the last 2 decades would not make much sense.) When verifying ASICs, a lot of work consists in verifying that the chosen IPs properly function together ‘ as a system’ (= around busses). For this reason, during ASIC verification, most of the observation work is done at the interfaces between these IPs. Consequently, the need to precisely look at the inner workings of these IPs down to the bit level is more important when designing (and prototyping) IPs, than it is when prototyping whole ASICs.

Conclusion: FPGA prototyping usages can have very different ‘profiles’

Whether it is for FPGA debug, ASIC verification or IP verification, each of these usages define a very specific ‘profile’ that needs to be accounted for when selecting a FPGA prototyping platform.

Is at speed operation optional or a must? Should partioning be avoided? Is an older FPGA technology ok?

This first series of questions come into play when selecting the FPGA prototype and can have fundamental consequences on the project.

In addition, all prototypes require some level of ‘observability’.

What do you need to measure? Which options are there to achieve this? Which level of observability do you expect? What do you need to make prototyping really useful?

This second series of questions are more about the ‘tools’ – and especially the ‘observation tools’ used with the prototype.

It is worth noting that no FPGA prototyping system can be chosen idependently to how it is observed. Extracting the adequate level and quantity of data, measurements and logs is equally crucial for an efficient verification and testing job. I’ll cover this in a future post.

… to be continued…

Thank you for reading.

– Frederic