Aspirational Congruence

When talking to suppliers about their products, conversation tends to focus heavily on what they already have and why it is the answer to every imaginable need in their space. So it’s refreshing when a vendor wants to talk about where customers want to go without claiming they already have the answer wrapped up in a bow. I recently had such a conversation with Frank Schirrmeister of Cadence on the topic of congruence in hardware modeling through the ever-squeezed hardware and software development cycle.


The root of the problem is well-known – product teams are aggressively compressing development cycles to meet fast-moving market windows. One especially long pole in this effort is getting software ready as soon as possible after silicon. Virtual prototyping is a great way to accelerate development of higher-level software, but when you get closer to the hardware or you need to check performance, you have to turn to hardware modelling on emulation or prototyping systems.

There’s no question that simulation still plays a dominant role in hardware development and verification, but it is wildly impractical as a platform for developing/verifying software. Simulation also struggles with debug and regression in big, long and complex tests, particularly when trying to isolate root-cause problems over millions or billions of cycles. This is why emulation, running orders of magnitude faster than simulation, has become so popular. Emulation doesn’t compile as fast as simulation but at 140-150M gates compiling/hour, you can get 5-6 turns a day, making this approach a practical alternative even in relatively early stages of system development.

When it comes to software development and validation, emulation is arguably the best platform for bare-metal software (firmware and drivers for example) but is far too slow to practically support develop/debug cycles in middleware. That’s where you want to use FPGA prototypes which can run at least another order of magnitude faster and be able to develop/debug in the context of a larger system. This is closer to the expectations of software developers who want to work with what Frank calls “cup of coffee interactivity” – they’re OK to go for a cup of coffee wait for a run to complete, but they’re not OK with having to wait until the next day.

All of this is great, but how does it help software developers start earlier? FPGA prototypes are fast but bringup can take weeks, not an investment you want to make when the design micro-architecture is still being refined. So is early software development a Catch-22? Not if you have emulation/prototyping congruence. Imagine if, starting from an emulation build, prototype bringup could be reduced to a push-button step which would complete in limited time (perhaps a few days) and cycle-level correspondence could be guaranteed between emulation and prototype behavior, then software developers could start much earlier, even at mid-stage RTL. After all they don’t care about detailed hardware behavior (and especially not hardware debug), they just need enough to get started.

This goal is partly achieved today and partly aspirational. Congruence in modeling behavior is already available at cycle-level accuracy and RTL compile is already common between the two platforms. You want clock-tree transformation, gated clock handling and partitioning to the prototype to be transparent, which is largely in place today. But the back-end flow, into Vivado P&R for Protium, still requires some hands-on involvement which could be greatly reduced or even eliminated with maybe some compromise in modeling performance. For a software developer who doesn’t want to or need to know about FPGA tooling, this may completely be acceptable for early software validation/development. And reuse of previously compiled partitions/blocks with hands-free dependency management can further reduce compile times.

So to recap, the aspiration is to be able to start software development and validation while the RTL for the design is still in some level of flux. To do this it is essential to have congruence between emulation and prototyping, in setup and in modeling. Prototype setup should approach a push-button step given a functioning emulation and should compile as fast as possible (within as little as a day if feasible) to support software development staying nearly in sync with hardware evolution. And in modeling the models the hardware team and the software team are using should be congruent in behavior.

Some of this stuff is aspirational, some is already covered in Cadence prototyping (see here), however I'm sure Frank didn’t share this with me simply to admire the problem. I expect that Cadence is cooking more solutions to congruence as I write. For more info, watch for news in this area from Cadence.

On a final note, I chose the title of this piece partly because I thought it would make a great German compound-word, Aspirierendkongruenz as near as I can tell, based on Google translate (Frank can comment). Idle play of an idle mind.

More articles by Bernard...