Your testbench is green, the waveform looks right, and the coverage report pleases you. It is tempting to call the design done and hand it over with confidence. Every engineer who has shipped silicon knows the feeling, and every one of them learned what comes next the careful way.
Your simulation passes. What still has to happen before this is silicon?
A passing simulation answers exactly one question: does the RTL behave as specified on the cases you wrote. That is no small thing, and this course spends four parts earning it. But behavior on tested cases is only the first of the questions a chip must survive.
Everything after it asks whether that behavior can be built: can the RTL become gates that fit, do those gates meet the clock rate on slow and fast silicon, does the layout pass physical rules, can a tester check every manufactured chip, and does the first silicon run real software. This lesson walks those stages at awareness level. It teaches no back-end tools: it says what each stage does and what it needs from your RTL.
Synthesis translates your RTL into gates taken from a real library, guided by timing constraints that state the clock targets. Floorplan, placement, clock tree and routing shape those gates into a layout: blocks get positions, cells get placed, a balanced clock tree spreads the clock so edges arrive together, and wires connect everything without breaking spacing rules.
Sign-off checks the layout against timing across slow and fast silicon corners, against the power budget, and against physical rules, using static timing analysis (STA), which means proving timing by calculation rather than by simulation. Test insertion adds scan chains and test patterns so a tester can drive and observe every flop on each manufactured chip, where DFT means design for test. Fabrication turns the layout into silicon through masks and a foundry, and bring-up runs real software on the first chips to prove the whole flow worked.
The picture below puts both halves side by side for the same design. Read the left column as what your green test already proved and the right column as what still needs proving. Every item on the right traces back to something your RTL must provide, which is the subject of the next section.
None of the back-end stages can fix a vague front end. Each one needs one thing from your code, stated while you write it rather than discovered months later:
Clocks: one clocking story with no hidden clocks, so synthesis and the clock tree build what you simulated.
Resets: a reset every flop can reach, so sign-off and test can return the chip to a known state.
Constraints: stated timing targets for those clocks, so every tool optimises toward the same numbers.
Hierarchy: block boundaries the tools can keep, so floorplan and timing work block by block.
Power intent: which blocks sleep and when, so the power plan matches the behavior you verified.
Scan readiness: flops the tester can control and observe, so DFT insertion needs no RTL rewrite.
Part 7 of this course collects exactly this list and turns it into a release package. When you are ready for the detail, start with What the Back-End Needs, which says what each item looks like in practice.
Trace one signal through the whole back end to see why each stage needs its line from the list above. Your RTL asserts a synchronous reset that clears every counter flop. Synthesis typically adds buffering so that reset can reach every flop. The clock and reset trees balance its arrival so no flop sees it a cycle late. Sign-off proves it works on slow and fast silicon alike, because transistors switch at different speeds in different corners. Test logic needs that reset to stay controllable in test mode, the tester exercises it on every manufactured chip, and firmware relies on it at power-up before the first instruction runs. One line in your RTL, six stages that depend on it: that is what silicon-ready means.
Believing a green test means the design is done. The testbench proves behavior on its own cases. Gates, timing, power, physical rules and testability are separate verdicts from separate stages, and each one can still fail on passing RTL. Celebrate the green test, then ask what the right column of the picture still needs.
Assuming the tools will fix a vague clock or reset story. Synthesis and the clock tree build what you described, not what you meant. A second clock you never named or a flop your reset cannot reach sails through simulation and fails in silicon, where fixes cost masks instead of edits.
Leaving test insertion for later. Scan readiness is an RTL property: flops the tester cannot control need code changes, not tool options. Keep every flop reachable from reset and observable through scan from the start, and DFT insertion stays a back-end step instead of becoming your rework.
Rule: a passing testbench starts the hardware flow, it does not finish it.
Any two from the right column of the picture: whether the gates meet the clock rate, whether power stays inside budget, whether the layout passes physical rules, or whether every shipped chip is testable. Each needs its own stage and its own verdict, and none of them follows from a green simulation.
Sign-off checks power against the budget across silicon corners. It needs your power intent: which blocks sleep and when, stated so the plan matches the behavior you verified. Without that statement the tools assume the worst case and the budget fails on pessimism alone.
Because fabrication produces many copies and each shipped one must be checked. Scan chains let the tester drive and observe every flop on every chip, which only works when the RTL keeps flops reachable and observable. Unscannable flops hide manufacturing defects that no simulation can see, since simulation checks the design while the tester checks the silicon.
A green testbench proves behavior on its cases; gates, timing, power, rules and testability need their own verdicts.
Six back-end stages stand between RTL and silicon, and each one needs one thing from your code.
Clocks, resets, constraints, hierarchy, power intent and scan readiness are RTL properties, so state them while you write.
Part 1 ends here: you can sketch the flow, name who does what, trade power against performance and area, and say what the back end still needs. Part 2 sets up the workstation where you will run the front-end loop yourself.