Electronic Design

A Modest Proposal

For Preventing Companies from Being Further Burdened by Spiraling ASIC and FPGA Development Costs, and For Making Superfluous Engineers Beneficial to the Public

Whilst relaxing in my winged-back chair one evening, pipe in hand, loyal Irish Setter at foot, and perusing Jonathan Swift's A Modest Proposal, it occurred to me what a melancholy object it is to those who walk through this country, to see the streets bustling with hardware design engineers seeking an honest livelihood, forced to rummage for a place to park their abundant talent and experience. I think we can all agree that our industry has seen desperate times suffering from the telecommunications and Internet overhangs. As if to irritate the wounds further, the movement of jobs to other lands, driven largely by the absence of any significant productivity gains, has greatly added to the already crowded conditions.

In my endeavor to address the plight of companies developing ASICs and FPGAs, I came upon a proposal that, despite unequivocally improving the lot of companies, requires change on the part of design engineers to elevate their current condition. What to do with the poor, intransigent engineers who do not jump on this generous recommendation? Through much unselfish work on my part, as I have nothing to gain in the solution proposed, I have designed the proposal to deal with this side effect while simultaneously benefiting the general public as well.

As design and verification efforts, though laborious, can be characterized and scoped, companies have been distracted by less predictable issues like timing closure. With everything in life, the path of least resistance is often the most attractive—as design complexity grows, companies address the increasing design and verification demands by reflexively heaping more and more engineers on the problem. But this pushes out schedules, drives up costs, and forces companies to search the distant lands of spices, cricket, and great walls for more affordable versions of this highly replaceable labor. This is not unexpected, as the theory of comparative advantage predicts it. Without a substantive change in design and verification productivity, labor has come to dominate project costs and schedules. Like Adam Smith wrote in The Wealth of Nations, "If a foreign country can supply us with a commodity cheaper than we ourselves can make it, better buy it of them."

To address head-on the exploding design and verification problem as well as the commoditization of labor, we need a new development methodology and associated EDA tools that fundamentally enhance productivity. We must take design to a much higher level of abstraction, while retaining the ability to generate high-quality hardware. My proposal directly helps companies and greatly improves the lot of the enterprising engineer. This proposal has three components:

First, unlike previous approaches that naively put faith in the capabilities of the design engineer, I advocate following basic common sense and experience. Surely today, a computer has to be preferred for even the most sophisticated analyses. Examples of computers performing complex tasks abound—they include the uncanny ability for airlines to track luggage, the five-nines infallibility of grocery checkout scanning, and, of course, eerily accurate weather forecasting.

There can be no better candidate for automation than hardware architecture and implementation given their primitive, rote nature. By developing with pure algorithms in a highly abstract, non-hardware language, engineers can remain untainted, with computer-based tools instead figuring out the best architecture and implementation. Surely automated tools can outpace and outclass the output of design engineers – although even to imply a comparison is to demean the automated tools.

Second, a good design tool needs a language and underlying technology to be successful. Already adopted for high-level modeling, C is both freely and widely available. Sure, when C first got used as a modeling tool, no one picked it for its easy translation into hardware. But at this point, it is silly to question its appropriateness. Besides, multi-hundred million-dollar investments made over the last few decades repeatedly tried to push parallelizing compilers to deliver acceptable results—and now all of this technology is shamefully sitting on the shelf. It's time for a rebirth of the parallelizing compiler—this time to generate hardware from C. Whoever said "those who do not learn from history are condemned to repeat it" lacked the eternal optimism of the lemming.

Third, this proposal requires a bit of patience, or, if that is unacceptable, a little religion. Patience is required to debug issues uncovered during RTL-based verification, as the RTL output from this new tool will bear little resemblance or correlation to the design. It is, after all, an abstract, software-based algorithm translated to hardware. For those lacking patience, there's a terrific alternative. C offers the tantalizing prospect of performing all your verification and debug with the source using C tools, ensuring your fingernails never get dirty. All one needs is a little faith that this new tool's RTL output is 100% error-free.

Now, what do we do with all of the unencumbered design engineers that fail to follow my enlightened advice and are thus left behind? Without personal benefit, I struggled mightily for a solution to this problem. I ultimately received the advice of a selfless friend from Erehwon who assured me that, whether stewed, broiled, baked, fried, fricasseed, slow-roasted, or otherwise prepared, the domestic engineer can easily, and quite deliciously, feed a family of five for several days. While I am sadly unable to pass along, due to space constraints, a fine Vindaloo recipe that he suggested, I am happy to say that this final wrinkle to the proposal, which costs almost nothing, soundly addresses the overcrowding in the streets while it simultaneously feeds needy families and delivers a creative solution for the avoidance of Bovine Spongiform Encephalopathy.

For a non-satirical, truly serious (and seriously immodest) proposal, please check out www.bluespec.com. George Harper, a fan and liberal plagiarizer of Jonathan Swift, http://art-bin.com/art/omodest.html, is VP of Marketing for Bluespec Inc., an EDA company delivering high-level synthesis tools for control logic and complex datapaths.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.