Red Flags Before You Floorplan

The last two articles taught how to read the synthesis reports. This one turns that into a habit.

Floorplanning, Module 3’s subject, spends real effort: die sizing, power grid planning, macro placement, pin assignment. All of it is wasted on a netlist that is structurally broken, and a broken netlist can produce a synthesis report that looks fine if you do not know where to look. This article is the where-to-look list.

The checklist

Check	Where to find it	What a red flag looks like
Sequential cell count versus RTL	Yosys `stat`, `dfxtp_*` rows	Does not match the register bits the RTL declares
Total cell count versus expectation	Yosys `stat`, `Number of cells`	Wildly larger or smaller than similar past designs, with no RTL change to explain it
Unmapped generic cells	Final netlist, or synthesis log	Any `$_AND_`, `$_DFF_P_` or similar `$`-prefixed cell surviving past `abc`
Worst slack sign	OpenSTA report, final slack line	Negative: a synthesis-stage violation, which only gets harder to fix later
Worst slack magnitude	OpenSTA report	Positive but thin (a small fraction of the period), on a path likely to lose margin to wire delay and skew
Suspiciously small design	Yosys `stat`, `Number of cells`	A handful of cells for a design that should be substantial; often large parts of the RTL were optimised away as unreachable, unused or constant
Latch inference warnings	Synthesis log	Any `Latch inferred for signal ...` on a signal meant to be combinational

Why zero violations is not the whole answer

Section 2.4 made half of this point: a clean report against loose or missing constraints is meaningless. The slack-magnitude row makes the other half explicit: a clean report against the right constraints, with only a sliver of margin, is a design one physical effect away from a violation. Placement, CTS and routing all lie ahead, and each consumes slack. A design reporting +0.15 ns at synthesis is not passing in any practical sense; it is very likely to fail the moment Module 4’s placement-driven timing report runs.

None of these checks needs anything beyond what the last two articles taught, the stat breakdown and the OpenSTA path report. The checklist is the same two reports read with one disciplined question each time: is there a reason not to trust this yet? Floorplanning tools cannot see whether the flip-flop count matches the RTL’s intent or whether a positive slack has real margin left. Every check here is cheaper and more directly diagnosable now than it will ever be later.

Applying the checklist to a broken report

A colleague hands you this stat excerpt for what should be a working alu8 variant with an added carry-in:

Number of cells:                  4
  sky130_fd_sc_hd__conb_1          2
  sky130_fd_sc_hd__buf_1           2

Chip area for module '\alu8':     18.40

Four cells and 18.40 µm² for an 8-bit ALU with ten bits of registered state is not a small design. It is a design that has been almost entirely optimised away. Two conb_1 constant drivers and two buffers strongly suggest most of alu8’s outputs resolved to constants during synthesis, which usually means an input that should drive real logic was left unconnected or tied to a fixed value, or a testbench stub was synthesized instead of the real module. This failure mode, a design that synthesizes clean with zero errors and a tiny cell count, is one of the most common and most dangerous in a real flow, precisely because it produces no error. The tool did exactly what it was told; what it was told to synthesize was not the intended design.

Practice Exercise

A synthesis report shows: cell count matching expectations, ten dfxtp_1 cells matching alu8’s register bits, and a worst slack of -0.34 ns. Is this design ready for Module 3’s floorplanning?

Solution

No. Everything structural checks out, but the slack sign check fails: -0.34 ns means the design already violates its constraint at the most optimistic stage of the flow, with an ideal clock and no wire delay. Every later stage (placement, CTS, routing) tends to add delay and consume margin, not create it, so a design that is negative here is essentially certain to still be negative, likely more so, with real physical effects. The next step is back to synthesis (a DELAY-biased SYNTH_STRATEGY per Section 2.2, revisiting the RTL structure per Section 2.1, or checking whether the constraints are unrealistically tight), not forward into floorplanning.

That closes Module 2. You have taken alu8 from RTL through a fully mapped SKY130 netlist, compared two synthesis strategies on real numbers, written and understood its constraint file, and learned to read both halves of its synthesis report critically enough to know when it is ready to move forward. In the next module we pick up where this checklist leaves off: turning a synthesis-clean netlist into the first physical decisions a chip needs, die size, power grid and floorplan.