
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

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

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...
Emulation Outside the Box
Bernard Murphy 2 Weeks Ago