Hardware and silicon design fundamentals

Register transfer level describes hardware as a set of storage elements plus the combinational logic that computes what moves between them on each clock edge. You are not drawing gates and you are not writing a program: you are saying which registers exist and what value each one takes next. That level exists because it is the highest abstraction a synthesis tool can reliably turn into gates while still letting you control timing. Above it, behavioural descriptions leave too much to the tool to be predictable; below it, gate-level design is unmanageable at any realistic size. The consequence is that almost every hardware interview question is an RTL question in disguise.

The vocabulary is the first filter, and most of it names an artefact rather than an activity.

term            what it actually is
--------------  ----------------------------------------------------------
RTL             registers plus the logic between them, written in an HDL
netlist         instances of real cells and the connections between them
synthesis       RTL in, netlist out, under timing and area constraints
constraints     the clocks, and what the tool must achieve, stated formally
STA             static timing analysis, checking every path without vectors
place and route deciding where each cell sits and how wires connect them
DFT             extra logic added so the manufactured part can be tested
soft IP         a block delivered as RTL that you synthesise yourself
hard macro      a block delivered already implemented, placed as one object
bitstream       the configuration data that programs an FPGA
GDSII           the layout format handed to the foundry

Read the middle rows as a pipeline: RTL becomes a netlist, the netlist becomes a placed and routed layout, and the layout becomes either a mask set or, for an FPGA, a bitstream. Each stage has its own idea of delay, and the numbers get more trustworthy as you go down, which is why timing that looked fine after synthesis can fail after routing.

The distinction between soft IP and a hard macro is the one candidates most often blur. Soft IP arrives as source, so it adapts to your process and your constraints and competes with your logic for area. A hard macro arrives already built, so its timing and power are known but its shape is fixed and your floorplan has to accommodate it. Choosing between them is a real decision with a real cost either way.

The two words worth being precise about are constraints and STA. Constraints are your statement of intent, and STA is the tool checking the design against that statement. Neither has any idea what your circuit is supposed to do, which is why a design can be perfectly constrained, entirely clean in timing, and functionally wrong.

RTL is a description of behaviour written by a person: an adder is a plus sign, a register is an assignment inside a clocked block. A netlist is a structural list of specific cell instances and the nets connecting their pins, produced by synthesis. The netlist contains no arithmetic operators and no if statements, only cells from a library. The practical consequences are that a netlist is enormous and unreadable by comparison, that it is tied to one target technology while the RTL is portable, and that any bug you find in a netlist has to be traced back to the RTL to be fixed, which is why keeping the two provably equivalent matters.

It is the palette synthesis is allowed to use: a set of small logic functions, flip-flops and buffers, each already laid out, each characterised for delay, output slew, input capacitance and power under a range of conditions. Cells in a library share a fixed height so they can be placed in rows, which is what makes automatic placement possible at all. The characterisation is what timing analysis actually reads, so the library is the bridge between a logical design and physical reality. A library usually offers the same function in several drive strengths and several threshold voltages, and choosing among them is how the tool trades delay against leakage.

Combinational logic goes into lookup tables, which are tiny memories addressed by the logic's inputs and whose contents are the truth table of the function you wanted. Any function of that many inputs costs exactly one lookup table, which is why FPGA area is counted in tables rather than gates. Around the tables sit flip-flops, dedicated arithmetic and memory blocks, and a configurable routing network of switches. The bitstream loaded at power-up sets the table contents and closes the routing switches. Everything about an FPGA's power and speed disadvantage follows from that structure, because the switches and unused resources exist in silicon regardless.

It states the things the tool cannot infer: which nets are clocks and at what period, how much uncertainty to allow on each, when inputs arrive relative to a clock and when outputs are needed, which paths are between unrelated clocks and should not be compared, and which paths are allowed more than one cycle. Everything the tool optimises for comes from that file, so an unconstrained clock is not optimised at all rather than optimised loosely. This is why reviewing constraints is as important as reviewing RTL, and why a clean timing report from a thin constraint file means nothing.

Fan-out is the number of inputs a single output drives. Each load adds capacitance, and a driver charging more capacitance switches more slowly, so a high fan-out net is slow and its slow transition degrades the timing of everything it feeds. Implementation tools deal with it by increasing the driver's strength or by replicating the driver and splitting the loads, which costs area and power. It matters in interviews because it is the mechanism behind advice that otherwise sounds arbitrary: a control signal broadcast to hundreds of places, or a reset distributed to every flop, needs a buffer tree in the same way a clock does.

Combinational logic's output is a function of its present inputs alone, so it holds no state and its behaviour has no history. Sequential logic contains storage, so the same inputs can produce different outputs depending on what happened earlier. Almost every real design is alternating layers of the two: registers holding state, combinational clouds computing the next state from the current one. The reason the distinction is drilled is that they fail differently. Combinational mistakes give you a wrong value immediately and reproducibly. Sequential mistakes give you a wrong value some cycles later, once, under a particular ordering.

A latch is level sensitive: while its enable is asserted it is transparent, and its output follows its input. A flip-flop is edge triggered, sampling its input only at a clock edge and holding that value until the next one. Synchronous design is built on flip-flops because a design where data moves only at edges can be reasoned about one cycle at a time and analysed by a timing tool. A latch in the middle of such a design opens a window during which data flows through uncontrolled, so its timing depends on how long the enable is asserted, and it is usually there by accident rather than intent.

A combinational always block describes a function, and a function must define an output for every input combination. If a branch of an if or a case leaves a signal unassigned, the description says the signal keeps its previous value on that path, and keeping a previous value requires storage. Synthesis has no choice but to infer a latch. The fix is to assign a default to every output at the top of the block, or to make every conditional complete. It matters because the tool warns about it and the warning is easy to ignore, and the resulting latch quietly creates a timing path nobody constrained.

The difference is two characters of source and a completely different circuit.

// Combinational: a function of the current inputs, no storage.
// Every output is assigned on every path, so no latch is inferred.
always @(*) begin
  sum   = a + b;
  carry = 1'b0;
  if (sum > 8'd200)
    carry = 1'b1;
end

// Sequential: the same value, but sampled at the clock edge and held.
always @(posedge clk) begin
  sum_q   <= sum;
  carry_q <= carry;
end

The first block produces a cloud of gates whose output changes whenever a or b changes, including transiently while the two inputs settle at different times. The second block produces flip-flops whose outputs change only at an edge and are then stable for the rest of the cycle.

That stability is what makes the registered version the one you hand to anything else. A combinational output is only valid once its inputs have settled, so the amount of logic behind it is part of the timing budget of whatever consumes it. A registered output arrives at a known moment with the whole clock period ahead of it, which is why block boundaries are conventionally registered even when it costs a cycle of latency.

The detail candidates leave out is the default assignments in the first block. Without carry = 1'b0 before the if, there is no value for carry when the condition is false, so synthesis infers a latch on it and you have accidentally built a sequential element inside what you described as a function. The habit of assigning every output unconditionally at the top of a combinational block removes an entire class of defect.

A combinational output can pass through transiently wrong values while its inputs arrive at slightly different times, even though the final value is correct. Inside a synchronous design this is harmless, because nothing looks at the signal until the next clock edge and it has settled by then. It becomes a real defect the moment the signal is used as something other than data: as a clock, as an asynchronous reset, or as an enable for a latch. That is the reason gating a clock with ordinary combinational logic is a mistake, and why a glitch-free clock gating cell exists as a specific thing.

A Moore machine's outputs depend only on its current state, so they change only after a state transition and are stable for the whole cycle. A Mealy machine's outputs depend on the state and the current inputs, so they can react in the same cycle as an input arrives, which saves a cycle of latency at the cost of an output that is combinational and therefore glitchy and dependent on the input's arrival time. In practice you often register a Mealy output to get the timing behaviour of a Moore machine, and the interview point is that the choice is a latency-against-timing trade rather than a matter of style.

The shape of the machine is the answer to "what are the states", and the interesting part is always the arc nobody asked about.

flowchart TD
    IDLE[Idle] -->|req high| WAIT[Wait for data]
    WAIT -->|data valid| SEND[Send and assert ack]
    SEND -->|req low| IDLE
    SEND -->|abort| ERR[Error hold]
    ERR -->|clear| IDLE

Written as RTL this is conventionally three pieces rather than one: a clocked block that holds the current state, a combinational block that computes the next state from the current state and the inputs, and a third block producing the outputs. Separating them is not decoration. It means the state register is unambiguously a register, the next-state logic is unambiguously a function with a default assignment on every path, and the outputs can be registered or not as a deliberate choice rather than an accident of where you wrote the assignment.

The arc worth staring at is the one from Send to Error hold. Every specification names the states in the happy path, and almost none name what happens when the far side withdraws mid-transfer, so that transition is where the machine either has a defined behaviour or falls out of its encoding. A machine with no arc for an unexpected input either sits in a state it cannot leave or, if the encoding leaves unused combinations, ends up in a state the designer never wrote.

That is also why the default branch of the next-state case matters more than it looks. Sending the machine to a known recovery state on any unexpected condition costs almost nothing and converts a hang into a recoverable error, and interviewers ask about it precisely because it is the part candidates omit when they sketch a machine from a diagram.

One-hot uses one flip-flop per state, so decoding the current state is a single bit test and the next-state logic is shallow, at the cost of many more registers. Binary uses the fewest registers and pays for it with a decoder in front of every output. One-hot suits FPGAs, where registers are plentiful and the logic depth between them is the constraint, and suits machines with many states whose decode would otherwise be deep. Binary suits designs where area or register count is tight. Either way the encoding is a physical decision that does not change the machine's behaviour, so it is a legitimate thing to leave to the tool.

It moves a value one position per clock, and that single behaviour covers a surprising amount of practical design. It converts between serial and parallel form, which is how nearly every low-pin-count interface works. It delays a signal by a known number of cycles, which is how you keep a data path aligned with a control path that has been pipelined. It generates a sequence, as in a counter built from a linear feedback shift register. And it moves a value across a clock domain boundary, which is exactly what a two-flop synchroniser is. Recognising the same structure in all four uses is the point.

Setup time is how long data must already be stable at a flip-flop's input before the clock edge for the flop to capture it reliably. Hold time is how long that data must remain stable after the edge. Together they define a window around the edge during which the input must not move. Both are properties of the flop as characterised in the library, not of your design. Your design's job is to guarantee the window is respected, which means data must arrive early enough and must not change too soon afterwards, and those two obligations pull in opposite directions.

Slack is one subtraction, and knowing which terms sit on which side is most of timing closure.

required time  =  clock period
                + clock arrival at the capture flop
                - clock uncertainty
                - setup time of the capture flop

arrival time   =  clock arrival at the launch flop
                + clock-to-output delay of the launch flop
                + combinational delay
                + interconnect delay

setup slack    =  required time - arrival time

Suppose the period is 5ns and the report gives minus 0.4ns of slack. There is nothing more to the violation than that: the path needs 0.4ns that the cycle does not contain, and every fix moves one of those terms. Shortening the logic or shortening the wires reduces arrival time. Increasing the period increases required time and helps every path in the domain, which is why it works and why it is the change you make last.

The term people forget is clock uncertainty, which subtracts from what you have. It absorbs skew between the two clock arrivals and jitter in the clock source, and it grows as a design gets physically larger because the clock has further to travel. Tightening a design's frequency target eventually runs into uncertainty rather than logic.

Now write the hold version in your head: launch and capture happen on the same edge, so the clock period does not appear anywhere. That is why hold and setup are not symmetric problems, and why a slower clock fixes one and is irrelevant to the other.

Because a hold check compares data launched by one edge against the same edge arriving at the capturing flop. There is no next edge involved, so the clock period is absent from the arithmetic. A hold violation therefore means the path is too fast: data reached the next flop and changed its input before that flop had finished capturing the old value. The fix is to add delay along the path, not to remove logic. The practical significance is that a setup failure can sometimes be worked around by running the part slower, while a hold failure means the part does not work at any speed.

Skew is the difference in clock arrival time between two points in the design at the same edge, caused by different path lengths and loads through the clock distribution network. Jitter is variation in when successive edges arrive at all, caused by the clock source and by supply noise. Timing analysis combines them into an uncertainty figure that eats into every clock period. The subtlety worth knowing is that skew is not simply bad: skew that delays the capture clock relative to the launch clock helps setup on that path while hurting hold, so it is sometimes introduced deliberately rather than merely minimised.

A clock has to reach every flip-flop in its domain, which is an enormous load for one driver, and it must arrive at roughly the same time everywhere or skew consumes the clock period. So clock distribution is built as a balanced tree of buffers, constructed by its own step in the flow after placement, when the tool knows where the flops actually are. Two consequences follow. Clock distribution consumes a substantial share of a design's dynamic power, because the tree switches every cycle regardless of what the logic is doing. And timing after clock tree construction is the first timing that means much.

It stops the clock reaching a block when that block has nothing to do, which removes the dynamic power of every flip-flop in it and of the branch of the clock tree feeding it. Because a clock tree switches every cycle whether or not the logic is active, this is one of the largest power savings available. The cost is that the enable signal must be glitch free, since a glitch on a gated clock is an extra edge and a corrupted register, which is why a dedicated gating cell is used rather than an AND gate in your RTL. Gating also adds skew and makes timing analysis more involved.

Asserting reset asynchronously is desirable, because it works even when no clock is running. Releasing it asynchronously is not, because release can happen arbitrarily close to a clock edge and a flop leaving reset at exactly the wrong moment can go metastable. Different flops can also leave reset on different cycles, so a state machine can start in a state that is not its reset state. The standard structure is a reset synchroniser: reset asserts immediately, and its release is passed through two flops clocked by the destination clock so that every flop in the domain leaves reset on the same edge.

Every one of them, and the mechanism depends on what is crossing rather than on where it goes.

flowchart TD
    A[Signal crosses<br/>into another clock] --> B{Single bit}
    B -- Yes --> C{Level or pulse}
    C -- Level --> D[Two-flop synchroniser]
    C -- Pulse --> E[Stretch or toggle<br/>then synchronise]
    B -- No --> F{One bit changes<br/>at a time}
    F -- Yes --> G[Gray code<br/>then synchronise]
    F -- No --> H[Handshake or<br/>asynchronous FIFO]

The left branch is the case everybody knows. A flop sampling a signal generated by an unrelated clock will eventually sample it mid-transition and can go metastable, holding an invalid level for an unbounded time, so a second flop is added to give the first a full period to resolve before anything reads it. Nothing between the two flops, and nothing else reads the first one's output.

The pulse branch exists because a synchroniser samples a level. A signal asserted for one cycle of a fast source clock can begin and end between two edges of a slower destination clock and never be observed at all, which is a different defect that no number of flops fixes. You either widen the pulse in the source domain or convert it into a level that stays put until the destination acknowledges it.

The right-hand branches are the ones candidates miss. Putting one synchroniser on each bit of a bus looks symmetrical and is wrong, because each bit resolves independently, so bits changing on the same source cycle can land on different destination cycles. For one cycle the destination reads a mixture of the old and new values, which is a number that existed in neither domain. Gray coding fixes it when only one bit changes at a time, which is why asynchronous FIFO pointers are Gray coded. For arbitrary data you hold the bus still and synchronise a single request bit instead, so the data crosses no synchroniser at all.

Both tell the timing tool to stop applying the default single-cycle check, and they assert different things. A false path says this path is never exercised functionally, so no timing requirement applies at all — legitimate for paths between genuinely unrelated clocks, or between two mutually exclusive modes. A multicycle path says the path is real but the receiving register is only enabled every so many cycles, so it may take that many periods. Multicycle is the safer of the two because a requirement still exists. A false path removes the check entirely, so an incorrect one is invisible in every report thereafter.

Within one simulation time step, blocking assignments take effect immediately and in source order, while non-blocking assignments all sample their right-hand sides first and update afterwards. Real flip-flops behave the second way: every flop clocked by the same edge samples the old values of its neighbours, not the values they are about to take. Using blocking assignment in a clocked block therefore describes a shift of data through several stages in one cycle, or makes the result depend on the order you happened to write the lines, and simulation and synthesis can disagree about it. The convention is non-blocking in clocked blocks, blocking in combinational ones.

The difference between two assignment operators is the difference between three registers and one.

// Non-blocking: a genuine three-stage pipeline.
// All three flops sample the OLD value of their source.
always @(posedge clk) begin
  q1 <= d;
  q2 <= q1;
  q3 <= q2;
end

// Blocking: d reaches q3 in a single cycle in simulation,
// because each line takes effect before the next one runs.
always @(posedge clk) begin
  p1 = d;
  p2 = p1;
  p3 = p2;
end

The first block is what you meant. Apply a value to d and it appears on q1 after one edge, q2 after two and q3 after three, because each flop reads the value its source held before the edge. This is exactly how hardware behaves, and it is why the ordering of the three lines is irrelevant.

The second block reads like software. p1 = d completes, then p2 = p1 sees the new p1, so d propagates all the way to p3 within one edge. Reorder those three lines and the behaviour changes, which is a reliable sign that a description is not describing hardware.

What makes this more than a style rule is that synthesis and simulation need not agree about the second block. Synthesis can produce three flops from it; the simulator produces the collapse-in-one-cycle behaviour. A mismatch between the two is the most expensive category of HDL bug, because your testbench passes and the silicon does something else. The reason the convention is stated as an absolute — non-blocking for clocked logic, blocking for combinational — is that following it removes the possibility rather than reducing it.

A wire is continuously driven by something else and models a connection; a reg is a variable that holds the value last assigned to it inside a procedural block. The names are misleading, because a reg does not imply a register: a reg assigned inside a combinational block synthesises to combinational logic, and a wire driven by a continuous assignment can be part of a critical path. The distinction is about which construct may assign to the signal, not about what hardware results. SystemVerilog's logic type exists to remove the confusion by covering both cases.

A parameter belongs to a module and can be given a different value at each instantiation, so one module can be instantiated at several widths or depths in the same design. A text macro is global and has one value for everything compiled after it. That difference decides whether a FIFO is one reusable module or three copies, and reuse in hardware is more valuable than in software because each copy also needs its own verification. Parameters also participate in elaboration, so widths derived from them are checked, whereas a macro is substituted blindly before the language sees it.

In arithmetic, silently, and the rule that decides it surprises people.

logic [7:0] a, b;
logic [7:0] sum8;
logic [8:0] sum9;

assign sum8 = a + b;   // 8-bit result: the carry out of bit 7 is discarded
assign sum9 = a + b;   // 9 bits, because the target width widens the addition

// The dangerous case: no wide target, so nothing widens the expression.
always @(*) begin
  over = (a + b > 8'd200);          // the add is 8 bits and wraps first
  over_ok = ({1'b0, a} + b) > 9'd200;  // widen an operand explicitly
end

The first two lines look like the same expression and are not. In Verilog the width of the assignment target participates in sizing an arithmetic expression, so the addition into the nine-bit signal is performed in nine bits and the carry survives, while the addition into the eight-bit signal is performed in eight and the carry is dropped without any warning being required.

The third case is where this becomes a bug rather than a subtlety. Inside a comparison there is no wide target to widen anything, so the operands size each other and the addition happens in eight bits. If a and b sum past the eight-bit range the result wraps, so the comparison against two hundred can be false for inputs that plainly exceed it. Widening one operand by concatenating a zero bit forces the arithmetic into nine bits and the comparison behaves.

Signedness has the same character. Mixing a signed operand with an unsigned one in a single expression can cause the signed value to be treated as unsigned, turning a small negative number into a large positive one, and again nothing is reported. The defensive habits are to size intermediate signals deliberately rather than relying on inference, to keep signedness consistent within an expression, and to have a lint tool flag every implicit truncation so the deliberate ones are the only ones present.

X is the simulator's way of saying it does not know the value: an uninitialised flop, a bus with no driver, a signal with two drivers disagreeing. It is useful because it makes missing initialisation visible. It is dangerous because X propagation is optimistic in some operators and pessimistic in others, so a design can appear to work in simulation despite genuinely unknown state, or fill the waveform with X and hide the real defect. The specific trap is that an FPGA's registers come up at a known value loaded from the bitstream while ASIC flops power up genuinely unknown, so a design that relies on initialisation works on the prototype and fails in silicon.

Because anything you build from combinational logic can glitch, and a glitch on a clock is an extra edge that no amount of downstream care recovers from. Dividing by registering a counter bit gives you an output that changes only at a clock edge and is therefore glitch free, at the cost of being a new clock that needs its own constraint and its own place in the clock tree. The better answer in many designs is not to divide at all: keep one clock and use an enable signal so the slow logic advances every nth cycle, which avoids creating a second domain entirely.

Because the cost of being wrong is asymmetric in a way software does not experience. A functional defect that reaches manufactured silicon is corrected by producing new masks and new wafers, which takes months and spends the manufacturing set-up cost again, and there is no patch. That asymmetry justifies spending more effort proving the design correct than designing it, and it explains the industry's habit of separating verification into its own discipline with its own engineers, languages and methodologies. Interviewers ask about it partly to see whether a candidate treats verification as a phase at the end or as the project.

It computes the delay of every path in the design against the constraints and reports which fail, exhaustively and without stimulus. That exhaustiveness is why it replaced timing simulation: no vector set covers every path. What it cannot do is tell you whether the design is correct, because it has no notion of what the circuit is for. It also believes your constraints completely, so a wrongly declared false path or a missing clock definition produces a clean report on a broken design. Timing analysis and functional verification are therefore complementary and neither substitutes for the other.

A directed test drives a specific scenario you thought of and checks a specific outcome, which makes it precise, readable and limited to your imagination. Constrained-random generation produces legal stimulus at random within declared constraints, running for far longer than you could hand-write and reaching orderings nobody anticipated. The catch is that random stimulus is worthless without two other things: a checker that knows the expected behaviour independently of the design, and coverage that tells you what the randomness actually reached. Directed tests remain the right tool for the corner you already know about, and for reproducing a bug once found.

Coverage answers "how much of the space have we been through", and the two families answer different questions.

kind               measures                          reaching 100% proves
-----------------  --------------------------------  --------------------------------
line / statement   source lines executed             no code is entirely untried
branch             both directions of each decision  no condition is one-sided
toggle             each signal saw 0 and 1           nothing is stuck or unconnected
FSM state          each state entered                no state is unreachable
FSM transition     each legal arc taken              the machine's arcs all work
functional         scenarios you declared as goals   your own list was satisfied
assertion          each property was exercised       the checks were not vacuous

Everything above the last two rows is a measure of the stimulus, not of correctness. You can reach full line and branch coverage on a design with the wrong behaviour, because executing a line says nothing about whether what it computes is right. This is the single most common misreading of a coverage report.

Functional coverage is different in kind, because a person writes the list of things worth covering: this FIFO was filled to capacity, this arbiter saw both requesters assert on the same cycle, this transaction was aborted mid-burst. That makes it the only coverage that measures interesting behaviour, and it also makes it as incomplete as the engineer who wrote it.

The last row is the trap in the table. An assertion that is never exercised passes every run, so a suite of assertions with no assertion coverage can report a clean result while checking nothing. Asking how a candidate knows their checks fired is a fast way to tell verification experience from verification vocabulary.

It states a property where the property lives, and checks it on every cycle of every test rather than at the end of one.

// A grant must arrive between one and four cycles after a request.
property grant_follows_req;
  @(posedge clk) disable iff (!rst_n)
    req |-> ##[1:4] gnt;
endproperty

assert property (grant_follows_req);

The value is in where that check runs. It is not part of one test's expected-result comparison; it is attached to the design and evaluated continuously, so it catches violations produced by tests written by other people for other reasons entirely. It also reports at the cycle the rule was broken rather than as a mismatch thousands of cycles later at the end of a transaction, which is the difference between a bug you diagnose in an hour and one you spend a day tracing backwards through a waveform.

The disable iff clause is the part that is easy to get wrong and worth pointing at. Without it the property is evaluated during reset, when req and gnt mean nothing, and it fails for reasons that have nothing to do with the design. With it too broad, the property is switched off in situations where it should still hold.

The trade-off nobody volunteers is that assertions are code and can be wrong in both directions. An assertion that is too strict fails on legal behaviour and gets weakened until it checks nothing. An assertion that is never exercised passes every run silently, which is why assertion coverage exists and why the useful interview question is not whether someone writes assertions but how they know theirs fired.

Simulation shows that the design behaves correctly for the stimulus you applied. A formal tool proves mathematically that a stated property holds for all legal inputs, or produces a concrete counterexample. That makes it extremely strong for bounded, control-heavy properties — arbiters, protocol rules, the claim that two states are mutually exclusive — and impractical for whole large data paths, where the state space defeats it. The related and universally used flavour is equivalence checking, which proves that a synthesised netlist implements the same function as the RTL, so you do not have to re-verify the design after every implementation step.

Because the two check different things and each has a blind spot the other covers. Timing analysis checks delays against constraints but knows nothing about function; RTL simulation checks function but knows nothing about delay. A gate-level simulation with back-annotated delays runs the real netlist with real timing, which catches the things that live in the gap: an X propagating from an uninitialised flop, a reset sequence that does not actually reach every register, a test structure that misbehaves, a constraint exception that was wrong. It is slow enough that you run a small selected set of tests rather than the whole suite.

Each stage narrows what is still free, and the useful thing is to see what becomes fixed at each step.

flowchart TD
    A[RTL plus constraints] --> B[Synthesis to a netlist]
    B --> C[Insert test structures]
    C --> D[Floorplan and placement]
    D --> E[Build the clock tree]
    E --> F[Route the wires]
    F --> G[Extract delays and<br/>sign off timing]
    G --> H[Physical checks<br/>then tapeout]

Synthesis chooses which cells implement your logic, working from estimated wire delays because nothing has a position yet. That estimate is why timing at this stage is indicative rather than trustworthy, and why a design that closes at synthesis can fail later.

Placement gives every cell a position, which converts estimated wire lengths into real ones. Clock tree construction happens after placement for exactly that reason: you cannot balance a tree to flops whose locations you do not know. Routing then commits every wire, and only afterwards can parasitics be extracted and the timing report be believed.

The step people omit when asked this question is test insertion, and it is the one that most visibly separates someone who has been through the flow. A manufactured die has to be tested for defects, so scan chains are stitched through the flip-flops to make them controllable and observable from the outside, and memories get built-in self test. That logic occupies area, appears in timing, and constrains your reset and clocking, so it cannot be an afterthought.

The other thing to notice is the direction of the arrows. Every stage's decisions constrain the next, and going back is expensive, which is why constraints and floorplan get scrutinised far more than the amount of text in them suggests.

Synthesis decides what: which cells from the library implement your logic, how deep the resulting network is, and where to trade area for speed. Place and route decides where: the physical position of every cell and the path of every wire. The reason this matters more in hardware than the equivalent split in software is that position is delay. Two cells that are logically adjacent may end up far apart, and the wire between them contributes real time to a path. So synthesis works from estimates it cannot verify, and a meaningful timing picture only exists once routing has happened.

Because a manufactured part can be perfectly designed and still be defective, and a defect deep in a state machine is unreachable from the pins. Scan chains solve that by connecting the flip-flops into shift registers in a test mode, so any state can be loaded in and any resulting state shifted out, turning a sequential test problem into a combinational one. Automatic pattern generation then produces vectors that detect a target fraction of possible faults. The cost is area, some timing impact, extra pins and a second mode the design must behave correctly in. Without it you cannot tell a good die from a bad one.

Mostly its area, and not linearly, which is the part worth writing out.

cost per good die  =            wafer cost
                        -----------------------------
                        dies per wafer  *  yield

dies per wafer     falls as die area rises
yield              falls as die area rises

a common simple model:  yield  =  exp of minus area times defect density

Both terms in the denominator move the same way, so area appears twice. A bigger die means fewer candidates are cut from a wafer of fixed size, and because defects are scattered across the wafer more or less independently of your design, a bigger die is also individually more likely to contain one. Multiply a smaller count by a smaller surviving fraction and the cost per working part rises faster than the area does.

That is the whole reason area reduction is pursued with an intensity that looks disproportionate from a software perspective, and why a memory nobody uses is a commercial problem rather than an untidiness. It is also why very large designs are sometimes split into several smaller dies that are assembled afterwards: the yield term rewards it even though the assembly adds cost of its own.

The terms outside the formula are worth naming too, because they are the ones a candidate usually forgets. Packaging cost depends on the pin count. Test cost depends on how long each part sits on a tester, which is set by how much test logic and how good a pattern set the design has, so investment in test design shows up directly in unit cost. And the whole calculation only applies at volume, since below some quantity the one-off engineering and manufacturing set-up dominates everything in it.

The final layout, after physical checks confirm it obeys the manufacturing rules and matches the intended netlist, is handed to the foundry as the data set from which masks are made. What matters about it is that it is a commitment: from that point the function is fixed in the physical structure of the die, so a functional bug is corrected only by a new revision with new masks and new wafers. That is the whole reason the verification effort before it is so large, and the reason the decision to tape out is taken by a group of people rather than an engineer.

Because it runs the real RTL at a real, if lower, clock rate, connected to real interfaces, months before any silicon exists. That lets software be developed and debugged against the actual design, lets the design be exercised for far longer than simulation could manage in the same time, and surfaces integration problems while they are still cheap to fix. The limits are worth stating: the FPGA version differs in timing, in the blocks it substitutes for vendor primitives, and in that its registers initialise from the bitstream, so it cannot confirm power-up behaviour or timing closure on the real part.

Because each target hides different things from you and rewards different structures. FPGA code leans on device primitives for memories, arithmetic and serial interfaces, and those instantiations have no equivalent elsewhere. FPGA registers initialise from the bitstream, so code can depend on an initial value that an ASIC flop will not have. Clock gating, multiple threshold voltages and custom memories are ASIC concerns with no FPGA counterpart, while an FPGA rewards a structure that maps neatly onto lookup tables and hard blocks. The portable core of the design is larger than the differences, but pretending the differences are zero is how a port overruns.

Into three places. Dynamic switching power is spent charging and discharging capacitance when signals change, and it scales with the capacitance, with the square of the supply voltage and with how often things switch. Short-circuit power is spent during a transition while both transistors in a gate conduct briefly. Leakage is spent continuously by transistors that are nominally off, and it grows with temperature and with lower threshold voltages. Which term dominates decides your strategy: switching-dominated designs are attacked by not switching, and leakage-dominated designs by turning things off or using slower, less leaky cells.

The relationship is worth holding in symbolic form, because it tells you which knob is worth pulling.

dynamic power  is proportional to  activity * capacitance * voltage^2 * frequency

knob                       effect                        what it costs
-------------------------  ----------------------------  ---------------------------
clock gating               cuts activity in idle blocks  glitch-free enable, skew
operand isolation          stops needless data toggling  extra gating logic
lower supply voltage       quadratic reduction           everything gets slower
lower frequency            linear reduction              throughput
power gating               removes leakage too           state loss, wake-up time
higher threshold cells     less leakage                  slower, so used off-path

The voltage row is why voltage scaling is the strongest lever available: the term is squared, so a modest reduction is a large saving. The catch is in the cost column — cells switch more slowly at lower voltage, so a design running slower must either accept less throughput or recover it another way, and the whole timing closure exercise is repeated at each supported operating point.

Clock gating is the row with the best ratio of saving to disruption, because a clock tree switches every single cycle whether or not the logic beneath it is doing anything useful. Stopping the clock to an idle block removes that entire contribution.

Power gating is the strongest and the most invasive, because a block with its supply removed loses its state and takes time to become usable again. That turns a power decision into an architectural one: something has to decide when the block is not needed, retain whatever state must survive, and hide the wake-up latency from whatever uses the block.

Pipelining cuts a long computation into stages separated by registers, so each stage has a full clock period and the design clocks faster. Throughput rises, latency rises slightly in absolute terms because of the extra registers, and area grows only by those registers. Parallelism replicates the computation so several items are processed at once, which raises throughput without touching the clock period and costs a full copy of the logic. Pipelining is usually the cheaper first move; parallelism is what you reach for when the clock period is already as short as the process allows.

If two operations never happen in the same cycle, they can share one piece of hardware with multiplexers selecting the inputs, which saves the area of the second copy. It is a good trade when the shared unit is large, such as a multiplier, and the multiplexing is small. It is a mistake when the multiplexers and the control logic cost nearly as much as the thing being shared, or when they sit on the critical path and turn an area saving into a timing failure. It also creates a structural dependency between two logically unrelated pieces of the design, which constrains later scheduling changes.

Because area buys three things you pay for repeatedly. It sets how many dies come off a wafer and how likely each is to contain a defect, so it drives unit cost non-linearly. It sets how much capacitance and wire length exists, so it drives power and, through wire delay, speed. And it sets how much of the design's routing resource is consumed, which affects whether the thing can be closed at all. On an FPGA the same pressure appears as fitting into a given device, where the next size up is a different part with a different price and possibly a different board.

Because they are different requirements and only one of them is usually the product's. A video or networking data path is judged on how many items it handles per second, so pipelining it deeply is free from the product's point of view even though each item now takes longer. A control loop or an arbitration decision is judged on how quickly it responds, so an extra pipeline stage is a real regression regardless of throughput. Establishing which one a block is judged on before optimising it is the difference between a useful change and a change that met a number nobody cared about.

Read the timing report rather than the code, because the report ranks paths by slack and names every element along the worst ones. That immediately tells you where the delay is concentrated and whether it is logic or interconnect. Then map the path's endpoints back to the RTL to see what function it belongs to, because the fix is almost always a change in the RTL's structure rather than in the netlist. The habit worth having is to look at several of the worst paths rather than only the first, because a group of paths sharing an element points at one cause rather than several.

That you think in cycles and in parallel rather than in sequence. Every statement you write happens simultaneously and repeatedly, and the question is not what the code does but what circuit it describes. Interviewers probe this directly by asking what a snippet synthesises to, or how many cycles something takes, or what happens on the first edge after reset. They also test a specific kind of pessimism: what this does when a signal arrives at the wrong moment, when two things assert at once, when a value crosses a clock boundary. Confidence about the happy path is not what the round is scoring.

A small set recurs because each has an obvious wrong answer. A synchroniser and a clock domain crossing, because the naive version is one flop. A FIFO with correct full and empty generation, because the off-by-one is easy to get wrong and the asynchronous version is a genuine test. A state machine from a written protocol description, because it exposes whether you separate next-state from output logic. A clock divider by an odd number, and a debouncer, because both tempt you into generating a clock combinationally. Practising these on paper is worth more than reading, because the errors are the kind that only appear when you write it out.

The question is asking you to read the description as a circuit, and there is a fixed order that gets it right.

always @(posedge clk) begin
  if (en)
    count <= count + 1'b1;
end

always @(*) begin
  if (count > 4'd9)
    flag = 1'b1;
end

Take the clocked block first. It is sensitive to a clock edge only, so every assigned signal becomes a flip-flop: count is a register. The assignment is conditional on en, so the register has an enable rather than a multiplexer in front of it, and the right-hand side is an incrementer feeding it. So far, so intended: an enabled counter with an adder in its next-state path.

Now the combinational block, and this is where the answer earns its marks. It is sensitive to everything it reads, and flag is assigned on one path only. When count is nine or less there is no assignment, so the description says flag holds its previous value, which requires storage. Synthesis infers a latch. You have described a level-sensitive element inside what looked like a function, and its timing depends on how long the condition holds rather than on a clock edge.

Say all of that, then say the fix: assign flag = 1'b0 unconditionally at the top of the block so every path defines it. Naming the inferred latch unprompted is the signal the question exists to detect, because it is the difference between reading HDL as code and reading it as hardware.

Answer at the level of what the step accomplishes rather than pretending familiarity with a command set. Timing closure, synthesis constraints and physical implementation are the same problems everywhere, and an interviewer who asks about a specific tool is nearly always checking whether you understand the step it performs. Saying which flow you have worked in, then describing the step in general terms and the decisions it involves, is a strong answer. Inventing a switch or a report name is a weak one, and it is easily caught by anyone who uses the tool daily, which is who is asking.

Say what state it reached and what you learned from where it stopped, because most hardware work is on a long programme and nobody expects every candidate to have taped out. What the interviewer wants is evidence of the loop: you wrote RTL, you verified it, something failed, you diagnosed it and changed the design. A project that reached a working FPGA prototype and was cancelled contains all of that. Describing a completed programme you were peripheral to, in contrast, gives an interviewer nothing to probe and invites questions you cannot answer about decisions you did not make.

Being asked how they found a bug that only appeared occasionally. The strong answer describes narrowing rather than guessing: reproducing the failure under conditions that change its rate, noticing that the rate moved with temperature or voltage or clock frequency, and using that to distinguish a functional bug from a timing or crossing problem, because a functional bug does not care about temperature. It names the instruments — a captured waveform from inside the device, a counter added to catch the event, a gate-level simulation of the suspect sequence. A weak answer describes reading the code until the bug was spotted, which does not scale to a failure that happens once an hour.

This is the question that most reliably separates candidates, and it is not asking about reset in the abstract. A strong answer names which registers are reset and which are deliberately not, because resetting everything costs area and routing on a large design. It says how reset is de-asserted, and why release is synchronised so that every flop in a domain leaves reset on the same edge. It distinguishes an FPGA, where registers come up at values loaded from the bitstream, from an ASIC, where they come up genuinely unknown, and notes that code relying on an initial value works on the prototype and fails in silicon. A weak answer says the reset signal sets everything to zero and moves on, which is a statement about intent rather than about what the hardware does.