Module 9: GDSII Generation and Tapeout · 9.5 DFM Considerations

DFM as a Discipline, Not a Checklist

In the last two articles we looked at yield and variation. In this last article of the module I want to step back over the whole flow, from the floorplan of Module 3 to the GDS of this module. Seen article by article it looks like a series of separate tasks and checklists. Seen as a whole, it is one discipline applied at every stage: design for manufacturability.

The course, re-read as DFM

  • Modules 3 and 4, floorplan and placement. Die size and utilisation were never just numbers to make timing and routing work. Die size is a cost and yield decision: a smaller die means more die per wafer and fewer defects per die, as we saw in Section 9.4 and the first article of this section. The power grid is a decision about margin against real IR drop and electromigration, not just compliance with one nominal number.
  • Modules 4 to 6, placement, CTS and routing. Congestion and routability are manufacturability concerns before any rule is broken. A design that only just routes needs detours, jogs and minimum spacings everywhere, which is exactly where DRC trouble, antenna violations and extra coupling come from.
  • Module 7, timing closure. Corner-based signoff, margins and derating exist to cover process variation, the same variation this section has been describing.
  • Module 8, physical verification. DRC, LVS, antenna, IR drop and fill are the checklist-shaped face of DFM. As Sections 9.2 and 9.3 argued, even these need an independent second look and an explicit decision process behind them.
  • Module 9. Streaming out, the independent review, the signoff report and the yield discussion are where the loop closes: the file leaves your hands only once every earlier decision has actually been checked.

The flow as one manufacturability discipline
Figure 1: Each stage of the flow makes decisions that affect how well the chip survives manufacturing

DFM was never a single step at the end. It is the combined effect of many decisions going back to Module 3, and the checklist of Section 9.3 was just the last place they were all looked at together before the file left your hands.

This is also what separates experienced physical designers: they bring this instinct into the early decisions, the floorplan and the power plan, instead of discovering problems at the checking stage, where every fix is more disruptive and more expensive.

Your own retrospective

Pick three decisions from your own uart_top work in Modules 3 to 8: for example the core utilisation you chose, a power strap width or pitch, or how you fixed the antenna violation. For each one, write a single sentence connecting it to a manufacturability or yield consequence, not to “it made the check pass”.

Practice Exercise

Write a short retrospective, three to five sentences, on your uart_top project from Module 3 to Module 9. Name one decision you would make differently now, with the DFM view in mind, and say why.

Solution

There is no single right answer. Here is an example of the kind of reflection that works: “In floorplanning I pushed utilisation up to 60% to keep the die small. That made placement dense around the receive logic, which led to the congested routing, the DRC spacing violations of Module 8.1, and the long single-layer run that failed the antenna check. With what I know now, I would have left utilisation around 45 to 50%. The die would be slightly larger, but the routing would have had room, and several late fixes, each needing a re-run of every check, would not have been needed.”

What matters is not which decision you choose but that the reflection connects an early choice to a later manufacturability or yield consequence, rather than repeating that it passed the check at the time.

That closes this module and the part of the course that walks through the flow stage by stage. Module 10 introduces no new stages. It runs the whole flow, start to finish, on different designs: a combinational ALU, the sequential UART, a design built around an SRAM macro, and a small RISC core, plus a project on debugging a flow that does not work first time, which is honestly the most realistic project of all.

← Why "Correct at Nominal" Isn't Enough