It is your first week on a chip team and someone says the RTL is with verification, the constraints are with synthesis, and firmware is blocked on the register map. Every noun in that sentence is a person, and every person is waiting on an artifact someone else has not finished. This lesson names those people and the packages that move between them.
Who works on my RTL before and after me, and what do we hand each other?
The industry draws one line through the whole flow. Everything that agrees on behavior sits on one side: the architecture, the RTL design, which means register-transfer level code describing registers and the logic between them, and the verification that checks the behavior. That side is the front end, and this course never leaves it.
Everything that turns agreed behavior into tested silicon sits on the other side: synthesis, physical design, sign-off and test. That side is the back end, and the linked courses own it. The line marks responsibility, not time. Both sides work at once and trade feedback in both directions, so you will meet back-end engineers long before your RTL is finished.
Before you comes the architect, the person who decides what the chip must do and writes it down as an architecture specification. That document is your starting point. You read what each block must do, cycle by cycle, and turn it into RTL source that a simulator can run and a synthesis tool can build from.
Beside you works the verification engineer, who reads the same specification and writes an independent testbench against it. Independent matters: when your reading and their reading disagree, someone has found a bug or a gap in the specification. After your RTL and its testbench agree, the synthesis engineer translates the RTL into gates taken from a real library, guided by timing constraints that state the targets.
Then the physical design engineer shapes those gates into a layout: floorplan, placement, clock tree and routing. The timing sign-off engineer checks that the layout meets time, power and physical rules. The test engineer, where DFT means design for test, adds scan logic and test patterns so a tester can check every manufactured chip. Last comes the firmware engineer, who writes the software that runs on the silicon and leans on your register contract to talk to the hardware.
The picture below shows this chain as one column of roles. It is an order of handoffs, not an order of work: in a real project the roles overlap, and the next paragraph names the biggest overlaps. Read the column from top to bottom and look at the arrow labels: each one names the artifact that moves. The dashed brackets mark which half this course teaches and which half the linked courses own.
A column of boxes hides how much work happens at once. The verification engineer starts writing the testbench from the specification before your RTL is finished. The test engineer, who handles design for test, influences your RTL early, because choices such as how registers can be scanned or reset are easier to make before the design is frozen. The firmware engineer reads your register contract while the RTL is still changing, and often tests software on a model or an FPGA long before silicon exists. The synthesis engineer tries early builds to tell you whether a coding style will meet timing. Treat the column as who receives the finished artifact next, not who works alone while you wait.
The table below lists each role once: what the role owns, what it receives, and what it hands on. Read your own row first, then the rows beside it, because those neighbors define what your work must satisfy.
Role | Owns | Receives | Hands on |
|---|---|---|---|
Architect | block behavior and interfaces | product requirements | architecture specification |
RTL designer | cycle behavior written as code | architecture specification | RTL source |
Verification engineer | proof the RTL matches the spec | RTL source and the specification | testbench plus coverage report |
Synthesis engineer | gates plus timing targets | verified RTL and your statements about clocks and resets | constraints written with you, plus the mapped netlist |
Physical design engineer | placed and routed layout | mapped netlist and constraints | routed layout |
Timing sign-off engineer | timing, power and physical verdicts | routed layout | sign-off reports |
Test (DFT) engineer | scan logic and test patterns | sign-off reports and layout | tested silicon |
Firmware engineer | software that runs on the chip | tested silicon plus register docs | drivers and bring-up tests |
No company staffs this table exactly. A large company splits rows further: one team owns clocks, another owns reset, a third owns memories. A small team merges rows: the RTL designer writes the constraints, runs synthesis experiments, and answers firmware questions about the register map. Both shapes build working chips.
What never merges is the artifact. Even when one person plays three roles, the specification still exists, the testbench still checks it independently, and the layout still needs its sign-off reports. Learn the artifacts first and map them to names on your team. Ask who owns each row of the table above in your first week, and write the answers down.
Illustrative: on Monday the architecture specification says the counter clears on demand. The sentence never says whether clear beats a simultaneous event, so you ask the architect and learn that clear wins. You write the RTL with clear above counting in the priority list, and your simulation agrees with your reading. The verification engineer read the same sentence the other way, so their testbench expects the event to win, and the run fails on the shared case. Neither of you is careless: the sentence was ambiguous, and the two independent readings caught it.
By lunch the specification gains one sentence, your RTL already matches it, and the testbench keeps the colliding case forever. In the afternoon review you walk the synthesis engineer through your clocks and resets so the constraints say what you meant. Before you leave, firmware asks which address clears the counter, and you point at the register map instead of answering from memory. One unclear sentence touched five roles in a day, and every touch traveled as an artifact: a question, a sentence, a failing test, a constraint, a document.
Treating the role list as fixed. You memorise eight titles and then join a team of four where the RTL designer also owns synthesis and sign-off. Map the artifacts to real names instead: ask who writes the spec, who checks your RTL, who constrains it, and who tests the silicon. Titles vary, handoffs do not.
Handing over code without its contract. RTL without the specification it was written against forces every later role to guess your intent. Synthesis guesses your clocks, firmware guesses your registers, and each guess becomes rework with your name on it. Hand the spec and the register map with the code, every time.
Reading 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 gates, timing, power, or testability. Lesson 1.6, What Happens After RTL follows your code through the stages where those questions get answered.
Rule: know who receives your work and what they need from it.
The architect hands on the architecture specification. The RTL designer hands on the RTL source. The verification engineer hands on the testbench plus coverage report. The synthesis engineer hands on both the timing constraints and the mapped netlist: the constraints state the targets and the netlist is the implementation that claims to meet them. The physical design engineer hands on the routed layout. Two artifacts share one owner in the middle because constraints and netlist are written against each other in the same step.
Someone still does it. On a small team the RTL designer or the physical designer absorbs scan readiness and the sign-off checks, often with tool and vendor help. Roles merge but artifacts do not disappear: the layout still needs its reports and each chip still needs its test patterns. Name an owner for every row of the table, even when one name covers three rows.
It sits on the line: you state what the clocks and resets mean while the synthesis engineer turns that into targets the tools enforce. That is why constraints appear in your handoff even though you never run the back-end tools. Vague clocks become missed timing that returns to you as rework, so write down what you meant while you still remember it.
Eight roles move your RTL forward, and each handoff is an artifact with an owner.
Front-end agrees on behavior while back-end turns it into tested silicon, and both sides work at once.
Ownership varies by company, so learn the artifacts first and map them to names on your team.