EDA companies great and small have jumped on the design-for-manufacturing (DFM) bandwagon enthusiastically. New DFM companies and solutions were abundant at DAC 2005. But is DFM a vision of the future or merely what EDA commentator John Cooley flippantly refers to as "dollars-for-marketing?"
In truth, it seems that all you need to do to become a DFM company is add the acronym to your website and forego any real attention to fundamental flaws in your design methodologies. In all of the DFM hoopla, logic designers still struggle with out-of-control schedules, cost overruns, and a lack of communication between the front and back ends of the design process. What DFM really needs to do is raise the abstraction level for design and ease the flow of information throughout the design process. We used to have a name for it: electronic design automation.
Take, for example, the chasm between logic and physical design. Most DFM tools and methodologies approach manufacturing problems after physical design is completed.
No matter how clever the tools, there’s no such thing as first-pass success. The traditional flow has the logic designer producing the netlist, then moving to the physical design, then trial placement, then determinations of the routing specification files, and then circling back to the logic designer. Only after the logic designer is completely done and the physical designer is almost done do design teams begin to tackle DFM issues.
Wouldn't it be better to prevent the problems in the first place?
Secondly, even if there were enough physical designers in the world to work on every team, no company can afford to employ enough for every team. The typical ratio is one physical designer for every 10 logic designers. Outsourcing isn't going to make that better anytime soon.
If there is an issue in manpower and the capital required for design projects, then wouldn't it be a good idea to minimize the physical designer’s work and maximize the logic designer’s work efficiency?
More can be done to eliminate issues throughout the design process, starting with logic design, to get the design done right the first time. If logic designers have some knowledge of the effects of their design decisions on the physical implementation process, issues can be avoided early on in the design flow.
Unfortunately, engineers who use specialized logic design tools are having a huge amount of difficulty handing off their results to the next guy in the flow. And that's where the real challenge lies in EDA. One option is to invest lots of capital in convincing customers to hire more physical designers, and then to outfit those designers with new tools—the market that's been blanketed already by Synopsys, Cadence, and Magma. Or, you can offer tools in the front end that help pipeline the job, reduce design time, and inject design flexibility into the projects.
It's a false premise that logic designers can do their work more easily if they’re not required to handle things outside of their sphere of expertise. Any company based on that premise is in trouble. We haven't yet exhausted the ability of today's logic designers. We're just not giving them the information they need to succeed.