Michael Sanie (Senior Director Marketing in the Synopsys Verification Group) gave the wrap-up presentation at SpyGlass World recently, on the Synopsys Verification Direction. I learned from an interview Michael gave to Paul McLellan that he is an accomplished pianist. I’m a pianist also, though of considerably less talent, so I had to build this blog around a musical theme.
The fugue is a form, perfected in the Baroque period, in which one or more melodies chase (the meaning of fugue) through multiple voices or levels of a piece. This reminds me of the way we think of functional verification today. We have multiple different ways to verify, like multiple voices: simulation, static and formal verification, emulation, virtual prototyping and FPGA prototyping. Each of these has its own advantages but you couldn’t think of completing verification without using all of them. And as in a fugue, verification involves a complex interplay of themes between these voices. Emulation may carry a theme for a while, until some unexpected behavior creates a need to drop into simulation, which may in turn require a need to drop a sub-theme into formal verification until a problem is resolved, from which the theme then returns to the emulation voice.
Now imagine if each time a transition was reached the performers had to stop to re-read the score, reset instruments and do a couple of dry-runs to make sure they had the next part polished. The audience wouldn’t stick around for long. But that’s the way the verification fugue has worked in the past. Synopsys coined the term Verification Continuum™ for rendering a seamless verification fugue. This requires native integrations of compile, debug and more across the platform of solutions in the continuum. If every tool reads the score in the same way, there is no need to re-read on every transition. If every tool interfaces to debug in the same way, there is no need to reset debug style or cross-compare between incompatible interfaces.
Fully accomplishing this is not easy, in part because individual components have their origins in different tools with different objectives but also because an optimum architecture for one component isn’t necessarily optimum for another. The Synopsys approach is a more difficult but also more enduring engineering solution than any number of quick fixes. Each individual theme (a component) is refined, while seamless transitions between the themes (the Continuum) are optimized. Synopsys started with this approach several years ago, even before its acquisitions of Springsoft and Eve. We’re already seeing the results of those optimizations.
Perfecting the Verification Continuum is an ongoing exercise. The SpyGlass™ integration roadmap is still being developed. But the direction is clear: to make delivering a majestic verification fugue as seamless and as compelling as possible. You can learn more about Synopsys verification solutions HERE. This shows a pretty easy-to-understand picture of the Verification Continuum. And if you’re confused (as I was) about the difference between Verification Continuum and Verification Compiler, Verification Continuum is a platform of verification solutions whereas Verification Compiler is a product which includes simulation, VIP, static and formal verification and more, but not emulation or prototyping. To learn more about Verification Compiler, click HERE.
By the way, if you’re not a fan of classical music and all this fugue talk means nothing to you, fear not. A greatly simplified version is the round (Row, row, row your boat, Frère Jaques or Three blind mice, sung by multiple voices, each starting at a different time). Counterpoint – using multiple voices with different but harmonically related melodies - underlies the fugue and is quite common in rock, folk and related music. Some examples: Scarborough Fair (Simon and Garfunkel), Hello Goodbye (Beatles), and I Get Around (Beach Boys). Replace “fugue” with any one of these and you should get the idea – melodies chasing around between different voices.
More articles by Bernard...