I’m sure the suspense is killing you so I’ll just come out with it. EDA now stands for ‘Electronic Design Agility’. ‘Electronic Design Automation’ is gone forever.

That’s official. There’s no going back. Here’s why…

The huge number of variables, unknowns and risks that have become part of modern SoC development create multi-(multi-)dimensional problems so complex that forming a viable solution through planning and analysis alone is simply not possible. The right solution can only come out of an agile, iterative design process that relies on feedback cycles connecting developers to each other, the development team to the fab, the hardware experts to the software experts and most importantly, the development team to its customer.

It was heartening to read support for the idea that agile is part of the future of EDA in a post by Richard Goering from #48DAC in San Diego. In a post covering a keynote talk by Gadi Singer [Note: I originally had ‘interview with Gadi Singer’ here but Richard pointed out that it was in fact coverage of his DAC keynote. Richard: Thanks for setting me straight!], vice president and general manager of Intel’s SoC Enabling Group, Singer mentions agile methods as being part of an ‘Immenent EDA Transformation’:

“This is about having lots of feedback loops starting very early,” Singer said. “For those of you familiar with software methodology, it is about agile practices, not waterfall practices. With agile, you assume you have to make iterations, and every time you learn more you make changes. You have learning and validation cycles all through the design.”

Obviously I wouldn’t be here if I didn’t agree with that opinion but just because one person says it’s so doesn’t make it so. To get to where I am now, I had to challenge myself with a few questions to convince myself of the possibilities…

• When was the last time we finished a project on time and on budget when all the planning, estimating and scheduling were done up front?

OK, for a lot of people I could just stop there. I have no stats to back it up, but I’ve posed that question a few times asking for a quick show of hands. I never see that many go up so I’m convinced it’s rare. That’s the red flag that tells me something is just plain wrong with how we go about getting things done in hardware development.

In case you need a few more red flags…

• When design documentation so rarely represents a completed design, what sense does it make to finish it before I start writing code?
• If I’ve never accurately predicted the 3-day task I’ll be doing 4 months from thursday, why would I continue to build detailed schedules that go out 6 months or longer?
• How can I say code is done before I’ve seen it work properly?
• Why is feature creep soooo bad? Do we really think that the features we start with will be what the market needs 18 or 24 months down the road?
• If design specifications are so long and difficult to comprehend (assuming people actually read them in the first place), why do we keep writing them the way we do now?
• If the day actually does come when I am hit by a bus, is my test plan really enough to tell someone exactly what I’m doing? Or would it be better to just show people what I’m doing as we go along?
• Why wouldn’t we test, integrate and release code in small batches instead of doing everything at once?
• What good comes from sheltering the development team from its customer? Wouldn’t it be better to hear about their problems first hand?

A lot of what we do from a process point-of-view just doesn’t make sense anymore so if you find yourself nodding your head as you read any of these, you’re ready to become part of the imminent transformation Gadi Singer predicts.

For a long time, electronic design automation has been used to describe an entire world of tools that we use daily in semiconductor development. But the paradigm that revolves around automation as the solution to modern design problems is severely out-dated. Being agile and having the ability to react to situations we can’t possibly predict has, without a doubt, become more important than automating processes we can predict. It’s time to update the paradigm accordingly.

So there it is… ‘Electronic Design Agility‘ and the re-invention of EDA.

Like I said, that’s official and there’s no going back. It’s time to be agile!

neil

Q. What outdated practices have we been clinging to in hardware development even after they’ve repeatedly failed us?