Dec 01 2011
Conservation of Design Pain
Regardless of system-design approach, painful tradeoffs are still needed–usually during integration.
Earlier this month, Steve Leibson shared his “prognostications from the ICCAD panel” concerning the shape of things to come for the EDA and chip design industry.
The part of this blog that caught my attention was the comments made by Patrick Groeneveld, Magma’s Chief Technologist and the General Chair for DAC 2012. Groeneveld acknowledged two paths to handling chip design complexity: partitioning and reuse. But he believed that both of the paths were evil since they introduce inefficiencies in the overall design.
Leibson disagreed; pointing out that the divide-and-conquer method was a tried and ture approach, dating back to theRoman Empire. “…it’s an approach that seems to have withstood the test of time. However, a divide-and-conquer strategy does indeed lead to suboptimal design in terms of efficient resource use. I just don’t know of any engineering discipline that avoids such inefficiencies when tackling projects of comparable complexity. Is it hubris to think that electrical engineering and chip design are somehow different?
Both Groeneveld and Leibson offer classic arguments to the age-old problem of dealing with complexity. There are no new solutions to this dilemma, only a re-shifting of unpleasant trade-offs. In a broader sense, this re-shifting can be thought of as maintaining the “Conservation of Design Pain.” I use the word “design” for brevity and rhythm. To be correct, I should have used “development” since the pain is spread across the full system/product life-cycle effects, from design through manufacturing.
This law of “pain” acknowledges the shifting of difficult decisions to different parts of the development cycle, depending upon the methodology. For example, both partitioning and reuse are useful techniques that overcome certain design complexities by increasing the design pain in other areas, namely, in integration.
Centuries of systems engineering confirm that most systems work best when they have low coupling and high cohesion between subsystems. This is a golden rule in the partitioning between (and within) hardware and software systems. Reuse follows the same rule, with the added advantage of functionally verified blocks of design.
By reducing complexity, both partitioning and reuse simplify the work of design engineers. For example, by utilizing code or hardware reuse, engineers don’t have to design everything, which affords them more time to concentrate on designing in there area of expertise. This leads to greater specialization, which is can be good.
But it also leads to a greater need for reintegration and often increases the complexity of interfaces. This effectively shifts the “pain” from the module to the interface subsystem.
Shifting pain from one part of the development cycle is the result of dealing with complexity. If recent trends are any indication, then the integration engineers are in for a world of hurt.

























