There’s a reason the verification hardware accelerator business is growing so impressively. Modern SoCs – now routinely multi-billion gate devices – must be verified/validated against massively demanding test plans, requiring high levels of test coverage. Use cases extend all the way up to firmware, OSes, even application software, across a dizzying array of power saving configurations. Testing for functionality, performance, peak and typical power, security and safety goals. All while also enabling early software stack development and debug. None of this would be possible without hardware accelerators, offering many orders of magnitude higher verification throughput than is possible with software simulators.
Maximizing Throughput and ROI
Hardware accelerators are not cheap, but there is no other way to get the job done; SoC design teams must include accelerators in their CapEx budgeting. But they want to exploit their investment as fully as possible. Ensuring machines are kept fully occupied and are fairly allocated across product development teams.
In the software world, this load management and balancing problem is well understood. There are plenty of tools for workload allocation, offering a range of sophisticated capabilities. But they all assume a uniform software view of the underlying hardware. Hardware options can range across a spectrum of capacities and speeds, while still allowing at least in principle any job to be virtualized anywhere in the cloud/farm. Not so with hardware-accelerated jobs which must provide their own virtualization options given the radically different nature of their architectures.
Another wrinkle is that there are different classes of hardware acceleration, centered either on emulation or FPGA prototyping. Emulation is better for hardware debug, at some cost in speed. FPGA prototyping is faster but not as good for hardware debug. (GPUs are sometimes suggested as another option for their parallelism, though I haven’t heard of GPUs playing a major role so far in this space.)
Verifiers like to use emulators or prototypers in in-circuit emulation (ICE) configurations. Here they connect the design under test to real hardware. This directly mimics the hardware environment in which the chip under design must ultimately function. This requires physical connectors, and hence application-specific physical setups. Further constraining virtualization except where the hardware offers multiple channels between connectors and the core emulator/prototyper.
Swings and Roundabouts
Expensive hardware and multiple suppliers suggest an opportunity for allocation software to maximize throughput and ROI against a range of hardware options. Altair aims to tap this need with their Altair® Hero™ product, an enterprise job scheduler built for multi-vendor emulation environments. As their bona fides for this claim, they mention that they already have field experience deploying with Cadence Palladium Z1 and Z2, Synopsys Zebu Z4 and Synopsys HAPS. They expect to extend this range over time to also include Cadence Protium and Siemens EDA Veloce. They also hint at a deployment in which users can schedule jobs in a hardware accelerator farm, choosing between Palladium and Zebu accelerators.
In a mixed vendor environment, clearly Altair has an advantage in providing a neutral front-end for user selected job scheduling. Advantages are less clear if users hope for the scheduler to dynamically load-balance between different vendor platforms. Compile for FPGA-based platforms is generally not hands-free; a user must pick a path before they start. Unless perhaps the flow compiles for both platforms in parallel, allowing for a switch before running? Equally scheduling ICE flows must commit to a platform up-front given physical connectivity demands.
Another point to consider is that some vendors closely couple their emulation and prototyping platforms. In order to support quick debug handoff between the two flows. Treating such platforms as independently allocatable would undermine this advantage.
In a single vendor environment, I remain open-minded. The hardware guys are very good at their hardware and have apparently put work into supporting virtualization. But could a 3rd party with significant cloud experience add scheduling software on top? To better optimize throughput and ROI in balancing jobs? I don’t see why that shouldn’t be possible.
You can learn more from this Altair white paper.
Share this post via: