errors · bitdewfpga bit, nextpnr's timing report

ERROR [timing-not-met]: timing not met: clk 33.61 MHz (FAIL at 100.00 MHz). The longest path between two registers takes more than one period of that clock, so the design cannot run at it, and no bitstream is written; top.log has the critical path report (the registers and the logic between them). Fix: make the path shorter (a divide or a modulo in one cycle is the usual cause: register the intermediate results), or give it the time it needs: create_clock -period 30.000 [get_ports clk] (33.3 MHz) makes the check pass, and the Basys3 pin gives 100 MHz whatever the XDC says (its oscillator, Basys3 reference manual), so those registers must then take a new value only every 3 clocks or more (a clock enable from a counter: if (tick) ...).

The period the fix suggests is computed from the failing clock's number (33.61 MHz needs 29.8 ns, so 30.000), and it comes with what it costs: the Basys3 pin still gives 100 MHz. A clock made inside the design (a divider's output) is checked at 100 MHz too, and then the fix names it instead.

ERROR [timing-not-met]: timing not met: clk 33.61 MHz (FAIL at 100.00 MHz). The longest path between two registers takes more than one period of that clock, so the design cannot run at it, and no bitstream is written; top.log has the critical path report (the registers and the logic between them). Fix: make the path shorter (a divide or a modulo in one cycle is the usual cause: register the intermediate results), or give it the time it needs: create_clock -period 30.000 [get_ports clk] (33.3 MHz) makes the check pass, and the Basys3 pin gives 100 MHz whatever the XDC says (its oscillator, Basys3 reference manual), so those registers must then take a new value only every 3 clocks or more (a clock enable from a counter: if (tick) ...). https://nosey-dewdrop.github.io/dewfpga/errors/timing-not-met/
ERROR [timing-not-met]: timing not met: clk 498.01 MHz (PASS at 100.00 MHz), slow 35.39 MHz (FAIL at 100.00 MHz). The longest path between two registers takes more than one period of that clock, so the design cannot run at it, and no bitstream is written; top.log has the critical path report (the registers and the logic between them). Fix: make the path shorter (a divide or a modulo in one cycle is the usual cause: register the intermediate results); slow is a clock made inside the design and is checked at the same 100 MHz, so clock those registers on the port clock with a clock enable (if (tick) ...) instead of on slow. https://nosey-dewdrop.github.io/dewfpga/errors/timing-not-met/

Why does it happen?

At 100 MHz a path has 10 ns; a 32-bit divide or modulo in one cycle takes 30. A design that fails timing may still seem to work on the board and fail at random, so the CLI stops instead of writing the bitstream (the recorded decision; Vivado writes it with a critical warning).

What is the fix?

Register the intermediate results, or clock those registers on the port clock with an enable instead of on a derived clock:

always_ff @(posedge clk) if (tick) count <= count + 1;

Which command prints it?

• dewfpga bit

Which probes in test/sv print this code?

• a design that misses 100 MHz: a 14-bit value turned into four registered decimal digits (a long divide chain)
• a clock divider's output clocks more logic than 100 MHz allows (four decimal digits of a 14-bit value on the slow clock); the XDC has no create_clock, as the course's master XDC arrives

Every probe, with what Vivado does and what each stage does here: the probes, stage by stage.