You write ten lines of RTL, which means register-transfer level: a description of hardware as registers and the logic that computes their next values. You simulate those lines and the counter counts. It is natural to picture a straight road from here to a finished chip: your code, then some tools, then silicon.
You write ten lines of RTL. What happens to them before they become part of a chip?
The next section names many stages. Keep this short list beside you; every term is explained again where the course teaches it, and the Glossary has them all.
Architecture: the block structure of the chip, and how the blocks talk.
Verification: checking that the design behaves as specified.
Synthesis: turning RTL into a network of logic gates from a real library.
Floorplan, placement, routing: deciding where blocks sit, where each gate sits, and how wires connect them.
Sign-off: the final checks that must pass before the design is released to be made.
Back-end: everything from the gate network onward; the front-end is everything before it, ending with verified RTL.
A product starts as requirements: what the chip must do, how fast it must run, how much power it may burn. An architecture turns those requirements into a structure: which blocks exist and how they talk to each other. A microarchitecture and an interface specification turn each block into detail you can build from: registers, interfaces, cycle-by-cycle behavior. Then you write RTL design against that specification.
After your code comes functional verification, which means checking that the design behaves as specified. Then synthesis and technology mapping translate the RTL into gates taken from a real library. Floorplan, placement, clock tree and routing shape those gates into a layout.
Sign-off checks timing, power and physical rules. Fabrication, packaging and test turn the layout into tested silicon. Bring-up and silicon validation prove that the silicon runs real software.
Notice what moves between stages. Each stage takes an artifact in and hands an artifact on: a document, a piece of code, a netlist, a layout, a report. Your ten lines of RTL are one such artifact. They enter as RTL source written against the microarchitecture and interface specification, and they leave inside a mapped netlist after synthesis.
Nothing moves by conversation alone. When an artifact is vague, every stage after it pays for the vagueness, which is why this course spends a whole part on writing a specification you can test.
Verification does not wait for your code. While you write RTL, a verification engineer writes a testbench against the same specification, so the two of you interpret the same words independently. When your interpretations disagree, someone has found a bug or a gap in the specification, and the earlier it surfaces, the cheaper it is to fix.
Stages also overlap in time: synthesis experiments start before verification finishes, and floorplan feedback reaches the microarchitect while RTL is still changing. The picture below shows the order in which artifacts flow, not a calendar. Look at the boxes from top to bottom first, then trace the three dashed arrows that run back up.
The table below names the handoff at every stage: what goes in, what comes out, and who usually owns the work. Owners vary by company. Small teams merge roles and large teams split them further, so read the last column as typical, never fixed.
Stage | What goes in | What comes out | Usual owner |
|---|---|---|---|
Product requirements | Customer need and business goals | Requirements document | Product manager |
Architecture | Requirements document | Architecture specification | Architect |
Microarchitecture and interface spec | Architecture specification | Microarchitecture and interface specification | Design architect |
RTL design | Microarchitecture and interface specification | RTL source | RTL designer |
Functional verification | RTL source and the specifications | Testbench plus coverage report | Verification engineer |
Synthesis and technology mapping | RTL source and constraints (written with the RTL designer) | Mapped netlist | Synthesis engineer |
Floorplan, placement, clock tree, routing | Mapped netlist | Layout | Physical design engineer |
Sign-off | Layout | Sign-off reports | Sign-off team |
Fabrication, packaging, test | Layout released with sign-off reports | Silicon | Foundry and test house |
Bring-up and silicon validation | Silicon | Test report | Validation engineer |
The flow is drawn with arrows that run forward, but three arrows run back up the picture, and each one carries news nobody wanted. Read each scenario below as illustrative: a simplified example of the pattern, never a story about a real company or chip.
Illustrative: during functional verification, the testbench drives a case the specification never described, and the RTL answers it in a way the architect never intended. The fix is not more RTL. The specification gains a sentence, the RTL changes to match it, and the testbench keeps the new case forever. That is the first dashed arrow: bugs and spec gaps flowing back to RTL design.
Illustrative: after routing, the layout misses its speed target because one path through the logic is too deep. No placement effort closes the gap, so the microarchitecture changes: the deep path gains a pipeline stage and the interface specification records the extra cycle of latency. That is the second dashed arrow: physical feedback about PPA, which means performance, power and area, flowing back to the microarchitecture.
Illustrative: during bring-up, the first silicon runs software correctly but draws more power than the product allows in one common mode. The current chip cannot change, so the finding becomes a requirement for the next architecture: that mode gets its own power plan from the start. That is the third dashed arrow: lessons learned flowing back to the architecture of the next chip.
You read the flow as one-way. It is tempting to finish your RTL, hand it over, and consider your part done. But verification findings will come back to you, and routing results can force changes on code you wrote months earlier. Expect the return arrows and welcome them early, when each one costs a small edit instead of a late redesign.
You treat a passing simulation as a finished design. A green testbench says the RTL behaves as specified for the cases the testbench contains. It says nothing about synthesis, timing, power, or the cases nobody wrote. Lesson 1.6, What Happens After RTL follows your code through the stages where those questions get answered.
Rule: treat every handoff as a contract you could verify, and start verifying with the first one.
It takes in your RTL source plus the constraints that state the timing and physical targets, and it hands on a mapped netlist built from real library gates. The translation matters: behavior goes in, and an implementation that a back-end team can place and route comes out.
Bring-up and silicon validation, carrying lessons learned. Only real silicon running real software shows which architectural bets paid off, for example a mode that burns too much power. That feedback shapes the next architecture, never the current chip, because fabricated silicon cannot be re-architected.
The RTL source itself, so the testbench drives the real design, and the microarchitecture and interface specification it was written against, so the testbench checks the design against the intent instead of repeating your reading of it.
This course teaches the front end: the first five stages of the picture. When you are ready for what happens inside the back end, these courses own that detail:
A chip flows through ten stages, and each stage takes an artifact in and hands an artifact on.
Verification runs beside design from the start, stages overlap, and arrows point backwards as well as forwards.
Your RTL sits in the middle: written against the microarchitecture and interface specification, checked by verification, translated by synthesis.