Part of the  

Chip Design Magazine

  Network

About  |  Contact

Whole System Design: Abstraction, Security, and Scale

By James Hogan & Peter Levin

If you really want to burn somebody, especially when they’re not looking, cop a snarky grin and tell a friend about so-and-so being a prescient predictor of the recent past. Gets ‘em every time. Of course, the gag looses its originality and humor after, say, ten years of constant use. But there’s always a fresh target.

In fact, it would be difficult to find a person or topic more prone to overstatement and snarky grins than ESL. It has been on the horizon now for the better part of a decade, and “everyone knows” that it is just a matter of time until the breakout occurs. Investors have placed massive amounts of treasure on the bet, and careers have been defined and occasionally broken by the sweet temptation of this particular tower of Babel.

Happily, the current end-of-financial days crisis has instigated a fresh and constructive look at this decade-old problem. This time we’ll need more than a prayer – or better behavioral synthesis – to make things better. The good news is that the situation is about to improve, and in ways that may surprise even the most jaded and non-believers among us.

It would be easy enough to recite the liturgy (or litany, depending upon your faith or perspective) of EDA’s collective abuse and exploitation at the doorstep of the old temple. The problem is that such dogma hasn’t done much to revitalize the industry, either commercially or technologically. The resulting incremental improvements come at a cost far disproportionate to their impact. And even ESL has become something of a burnt offering.

Nonetheless, we’re stubbornly bullish on the idea that abstraction is always, with no exception, the key to utility and productivity. Because of the tremendous advances in – and therefore commoditization of – semiconductor manufacturing the value of complex devices, especially SoCs, is utterly dependent upon the ability to specify well, implement quickly, test for fidelity, and validate for function. Of course, like the engine under the hood of a car, hardware matters; it can add to or detract from the user experience. On the other hand, how many of us know or care about the brand of the motor. Most drivers take such things for granted, as long as their propulsion needs – expressed in (high level) terms of fuel economy, power and performance – are well satisfied. It is no accident that SoC design feels very similar to systems design, especially as software content becomes the primary factor of differentiation and scalability.

But don’t expect the polygon pushers to reach high into the system any more than you would expect an assembly programmer to build the advanced apps in a smart phone. Too expensive, too slow, too restrictive. When the wise men come, they will know two things: how to integrate the components of design implementation in a way that obfuscates the details, and how to use abstraction to their benefit. And they won’t call it ESL; however they may call it virtualization, just as they do today in the IT industry.

In fact, our customers are already years ahead of the tools they buy. Sure, they care about compactness, manufacturability, and power. But the real battleground – at least between them – is the truly differentiated trade-space between device integrity (does it do what I want it to do?), reliability (will it perform well, long, and under duress?), and security (am I assured of my privacy, and protection against nefarious intrusion?).

The promise of “system level” anything – we’re going to propose a more ambitious new name in a second – is to break down the parochial boundaries that separate abstraction layers like so much cruddy varnish, and instead integrate them under in a common methodology and view. This hypothetical tool – none exists yet but we’re unshakably optimistic – would truly facilitate architectural exploration without the constraining ties to hardware targets, bastardized (or proprietary) language, and prohibitive cost of migrating from simulation to emulation, and emulation to target platform. Moreover, and crucially, it has to conveniently and sensibly accommodate the application software that differentiates our customers’ products in the market. With possibly one large exception, this is basically how they make their profits. In other words, it is a pre-requisite, and a recipe, for the holy grail of scale.

For example, consider the automobile industry, the once and future king of virtual prototyping. Conventional wisdom is that the most successful firms (the current downturn notwithstanding) are masters of supply chain management. However, behind the scenes, is an equally important differentiator: the quality of the mechanical CAD tools that enable designers to explore virtual alternative “architectures” quickly and easily, from aerodynamic drag to sophisticated safety and control systems. We see no fundamental reason that this couldn’t be achieved for SoC platforms. Indeed, many of the component pieces are already there.

In other words, instead of the raucous battles over synthesis and layout, the vendors should focus attention on the neglected frontier of whole system virtualization. Today, software designers are effectively cut-off from hardware designers, and neither of them enjoys close ties to manufacturing and test. Tomorrow, with a little invention, we’ll offer customers a truly comprehensive approach – not just a better, faster, more automated path to implementation – but excellent virtualization that is at once affordable enough, fast enough and granular enough to sign off long before anyone commits anything to silicon.

Some of the leading edge tools are already getting close to the paradigm we have in mind, and can integrate the hardware abstraction layer with transactors, and the transactors with function. Indeed, many recent commercial innovations are well down the road of breaking the moribund constraints of narrowly targeted software stacks, and thus enable better top-down flexibility and design cohesiveness. The challenge remains, though, about what to do while the hardware is churning, and the software teams still aren’t settled, and possibly can’t settle, on detailed functional specifications . . . in part because the hardware is churning. This is the ultimate vicious circle, a true Teufelskreis. Adding insult to injury, the difficulty will compound as density increases and the SoC platforms have not just 50 million gates, but 200 million, and the software port is waiting on a physical prototype or is manually trimmed to fit inside an FPGA because the cycle-accurate simulation is just too slow. This is precisely the hell we want to avoid.

Let’s make an even more dramatic point: the ratio of software developers to hardware designers is something like 5-or-10 to 1, and the most economically interesting companies at the moment either have very specific performance gains in a narrow market, or are big-S software, little-s silicon plays. The opportunity, and need, to support their development using system virtualization is as large as it is lucrative. It also represents an important shift in mindset: renewed emphasis and focus on getting the problem statement right, first – a truly universal canon – and then worry about how to get the job done. An effective virtual platform would provide a crucial protection against the eighth deadly sin of incomplete, vague, or sloppy specifications. We suspect that this will follow a path very similar to the virtualization of automotive and aeronautic design, where suppliers are not just selling a “CAD” tool, but a heavy dose of methodology and support.

The bottom line is that strategic intent has to evolve to the systems level. We close, therefore, with a humble proposal. Ken Anderson recently reminded us ”that success is not determined by what happens to us, but by how we respond to the challenges.”

Instead of climbing the endless ladder of abstraction and local optimization, we suggest taking a step back and thinking about an altogether new approach: put the whole device, all in one place, all in one tool, all within easy reach of the various stakeholders, from beginning to end, until a happy customer can do something new, something much better. Let him start with real architectural exploration and specification at the top, and not even think about silicon until late in the game, if ever. Let’s stand near that guy, and not the tired old predictors of the recent past. And let’s call it Whole System Design.

Leave a Reply