Exostiv Blade is a Game Changer

How it started

Exostiv Blade all started from client requests in 2018-2019, especially from ASIC & SoC companies. They were seduced by the capture capabilities of Exostiv from FPGA running at speed – in some cases more powerful than the visibility tools built in their big EDA prototyping systems.

At that time, the main EDA companies had started to make their prototyping platforms and tools less ‘open’, so they could limit the ability of their clients to switch from vendor to vendor when a new investment cycle came up (some of them have somewhat reverted back from this policy since then). The market of FPGA prototyping platforms for ASIC roughly proposed 3 alternatives, which we already evoked in a past article:

• Integrated prototyping platforms from ‘big EDA’, that included the FPGA boards, a choice of plugin boards and the software tools to synthesize, partition and debug.
• Large boards with arrays of FPGA and additional plugin boards, but no software tool (3rd party tools were necessary).
• Custom in-house designed platforms that the clients designed and supported themselves.

Clients who design IP and subsystems that fit onto 1 or 2 FPGA chips often find ‘Big EDA’ prototyping systems too costly to buy and maintain. So they use commercial FPGA boards – like these provided by the AMD, Intel, High Tech Global or Enclustra – or build their own platform too. In this case, the boards also lack an integrated tool environment. Getting visibility has been especially painful: when there is a need to look into the system, engineers are often reduced to using limited JTAG tools, such as AMD ILA or Intel Signal Tap, that do not really scale with the complexity of the design.

So we came up with the idea to further extend what we were already doing with Exostiv: visibility into the FPGA, only bigger and scalable, with support of multiple FPGA. This initiated the ‘Exostiv Blade’ story. We were about to find that it went much further than ‘providing visibility resources’.

Only scaled-out FPGA prototyping gets close to a convincing cycle depth

I invite you to read 2 interesting articles – “The origins of bugs”, from Bryan Dickman and “Deep Cycles”, from Bryan Dickman and Joe Convey.

In this last article, the authors suggest that prototyping systems need to get bigger by plugging multiple boards in parallel while trying to achieve high clock speeds. Running a sufficiently high number of cycles on these prototypes is necessary to reproduce the conditions of bugs, find them and correct them.

Actual devices operating at multi-GHz and being deployed in numbers in the field can run an aggregated exacycles (1e18) and greater every day. In addition, the authors compute that the number of hours required to simulate 1 hour of target speed equivalent is in the 10k hours if 1000 simulations are run in parallel.

Consequently, only ‘scaled-out’ FPGA prototypes (running in the 10x MHz to 100x MHz) can achieve a convincing cycle depth required to get close to what the future ASIC will go through. Not simulation, not even emulation. Simulation and emulation both have their role to play, but are not sufficiently fast to reach the ‘deep cycles’ advocated by the authors.

So, the question is not ‘if’ we should use prototyping but rather ‘what for’ we should use it.

We have wanted to check the reality from the field and have asked to our clients.

Companies need to manage a variety of prototyping and emulation systems

What we found out from the field is a complex situation, where:

• There is a mix of emulation and prototyping
• Ageing FPGA prototyping platforms are costly to replace with the new generation, and this, no matter if they are commercial boards or in-house designed systems.
• Insufficient number of available gates, unfitness for the target chip environment and the ability to run at the target speed of operation are the main reasons to decide to change a prototyping platform.
• Over time, corporations have accumulated a very large collection of all kinds FPGA prototyping platforms. Reuse over multiple projects proves difficult.
• Prototyping are duplicated because design teams are on multiple locations. To a lesser extend, this applies to emulators too, but due to their costs, there is a trend to centralize this type of resources and access them remotely.

One of our key findings is that emulators are a scarce resource that is sometimes litteraly ‘clogged’ with workloads that could be run on a prototype at least 10 times faster. An example of this is the capture of traffic on an internal system bus for IP input vector generation and demonstration purposes.

In 2020 and 2021, the COVID-19 crisis has sent everybody work from home, creating issues at accessing prototypes – and resulting in an overuse of the emulators, because these are actually software that you can run remotely. Remotely accessing FPGA prototyping boards is not always effective.

A complex CAPEX & OPEX management problem

The table below summarizes the difficult trade off of using CAPEX to renew the existing set of prototyping boards vs. adding more emulators.

Emulators involve heavy CAPEX and potentially OPEX wasted in non-useful workloads. They also come short of providing the adequate number of cycles for test and debug.

Conversely, prototyping boards require more frequent cycles of investments (CAPEX) because they get obsolete more quickly and cannot be managed easily at enterprise level.

Exostiv Blade changes the game.

Better expense management calls for a platform upgrade:

• Upgrade the existing base of prototyping boards to extend lifetime on less demanding prototyping workloads.
• Upgrade the existing base of prototyping boards to allow enterprise-wide usage through remote access and avoid equipment duplication.
• Move non-essential emulation workloads back to prototypes to optimize the emulation vs. prototype resources usage and accelerate execution for these workloads.

Beyond providing unmatched scalable visibility into multiple FPGA, Exostiv Blade enables this upgrade towards multi-site, multi-target, multi-user heterogeneous FPGA test infrastructure.

As always, thank you for reading.

– Frederic