Vivado Reports & Synthesis Terminology

Define WNS and state yours.

Worst Negative Slack: the smallest setup slack across every constrained path. Mine is +4.854 ns at a 100 MHz constraint, meaning the slowest path beats its requirement by 4.854 ns. Positive WNS means timing is met.

Define TNS and state yours.

Total Negative Slack: the sum of slack across all failing endpoints, a measure of how badly timing fails overall. Mine is 0.000 with 0 failing endpoints out of 892, so nothing fails.

Define WHS and state yours.

Worst Hold Slack: the tightest margin against data arriving too early after a clock edge, analyzed at the fast process corner. Mine is +0.159 ns, on a short one-LUT path between read pointer bits.

What is WPWS in your report?

Worst Pulse Width Slack, +4.500 ns: minimum clock pulse width and period checks at the register clock pins. My report checks it at Axi_Lite/Bvalid_reg, where a 10 ns period trivially satisfies the roughly 1 ns minimum.

How did you get 194 MHz when you only constrained 100 MHz?

Fmax is derived from slack: 1 / (10.000 ns - 4.854 ns) = 1 / 5.146 ns, about 194 MHz. It is an estimate from the existing run, not a separately constrained closure; to prove it I would re-constrain near 5.1 ns and re-route.

Why does setup analysis show 892 endpoints but pulse width shows 507?

Pulse width checks are one per register clock pin and the design has 507 flip flops. Setup and hold endpoints are data input pins of sequential cells, and one flop can terminate multiple constrained paths through different inputs like D and CE.

State your utilization numbers.

265 LUTs of 14400 (1.84%), 507 flip flops of 28800 (1.76%), 168 slices of 4400 (3.82%), 0 block RAM, 0 DSP, on the XC7Z007S at speed grade -1, out-of-context, routed.

Why is Block RAM zero when the design contains two FIFOs?

At 16x8, Vivado implemented each FIFO as a flip-flop array with a mux read tree instead of memory: 256 FDRE for storage plus MUXF7/MUXF8 for the 16-to-1 read. A BRAM is 18Kb; burning one on 128 bits is wasteful, and the tool's inference threshold favors registers at this depth.

Why is LUT-as-memory (distributed RAM) also zero?

The arrays were small enough that Vivado's heuristic chose discrete registers over RAM32-style LUTRAM. The combinational asynchronous read I need for FWFT is LUTRAM-compatible, so forcing ram_style = "distributed" would work and would trade roughly 256 FFs for a few dozen LUTs.

Explain FDRE, FDCE, and FDPE and map your counts to the design.

All are D flip flops with clock enable: FDRE has synchronous reset, FDCE asynchronous clear, FDPE asynchronous preset. My 256 FDRE are exactly the FIFO storage, 2 x 16 x 8 bits, uninitialized by reset. The 250 FDCE are control and datapath registers using the async active-low reset. The single FDPE is the Tx line register, the only flop that must come out of reset high because UART idles high.

Walk through your critical path.

From Receiver/Read_Pointer_reg[4], the read pointer's extra MSB, into Fifo_Memory_Hold_reg[9][4]/CE, a FIFO slot write enable. The read pointer feeds the full-flag comparison that gates pushes, so it sits in the write-enable decode. Three logic levels (LUT2, LUT6, LUT5), 4.633 ns data path, 1.289 ns logic and 3.344 ns routing, slack +4.854 ns.

Why is your critical path 72% routing delay?

The design uses under 4% of the slices, so placed cells are spread across the fabric with long nets between them. With only three logic levels, wire delay dominates. That ratio is normal for small sparse designs; a congested design fails differently, with high logic depth or detoured routes.

What are MUXF7 and MUXF8 and why do you have 32 and 15 of them?

Dedicated 2:1 muxes inside a slice: an F7 combines two LUT6 outputs into a 7-plus-input function, an F8 combines two F7s. Mine build the 16-to-1 read multiplexers over the register-based FIFO arrays, which is the fingerprint of a FIFO built from flops instead of RAM.

What is a CARRY4 and where do your 16 come from?

The 7-series fast ripple-carry primitive spanning one slice, four bits per cell. Mine implement the arithmetic: baud and sample counters, pointer increments, and the occupancy subtraction.

What are unique control sets and is your 48 a concern?

A control set is a distinct clock/enable/reset combination; registers can only pack into a slice with matching control sets, so too many fragments packing. 48 against 4400 slices is nothing; it becomes a concern when control sets are high relative to available slices.

Why does your utilization report show zero IOBs and zero BUFGs?

The run is out-of-context: the module is synthesized as an internal block, so no I/O buffers are inserted and no global clock buffer is placed. In the integrated design the AXI bus never touches pins, only Uart_Txd and Uart_Rxd do, and the PS-driven clock arrives on a global buffer.

check_timing flags 47 inputs and 38 outputs with no delay constraints, severity HIGH. Is your timing closure invalid?

No. Those are port-to-register paths that will not exist once the core is inside the SoC, where every AXI signal is fabric-internal. I deliberately set no input or output delays. The meaningful, fully constrained set is the register-to-register paths on sys_clk_pin, and all of those are met.

What is the 0.035 ns clock uncertainty in your timing path?

Derived jitter margin subtracted from the required time: total system jitter of 0.071 ns divided by 2, with no input jitter, discrete jitter, or phase error in an OOC run. It models clock edge variation the analysis must survive.

Define setup and hold time and state which corner each is checked at.

Setup: data must be stable before the capturing clock edge; checked with maximum delays at the slow corner. Hold: data must stay stable after the edge; checked with minimum delays at the fast corner. My report analyzes both corners, max and min paths.

If this design failed setup timing, what would you do, in order?

Read the failing path first. If routing-dominated, tighten placement with a pblock or raise implementation effort. If logic-dominated, cut levels: register the full/empty flags, pipeline the FIFO read decode, or give up FWFT by registering Data_Out and adding one wait state to the AXI read. Last resorts: retiming or lowering the clock target.

If you needed to cut area, what is the single biggest win?

Force the FIFOs into distributed RAM with a ram_style attribute: roughly 256 storage FFs and the F7/F8 mux trees collapse into about 32 LUTRAMs. After that, size the integer counters explicitly and share decode logic, but everything else is small next to the FIFO storage.

Why is there no power number in your reports, and what would you say about one?

I did not commit a report_power run. Vectorless power estimates without real switching activity are rough, so I would run it with SAIF activity data from the loopback simulation and still label it an estimate. For a design this size, static leakage of the part dominates dynamic power anyway.

What does Design State: Routed mean and why does it matter for your numbers?

Both reports were generated after placement and routing, so delays are real extracted net delays, not synthesis estimates. Post-route numbers are the sign-off quality ones; quoting post-synthesis timing is a common way to overstate results.

What does out-of-context mode actually do?

Compiles the module as if it will be stitched into a larger design: no I/O buffer insertion, no pin placement, its own clock constraint, results cached as a standalone netlist. I used it to characterize the peripheral alone so the numbers contain none of the Zynq PS infrastructure.

Your hold slack is only +0.159 ns. Should you worry?

No. Hold paths here are single-LUT hops between neighboring pointer registers, which are naturally short. Hold is corner-checked at fast silicon, and the router fixes real hold violations by adding delay; small positive hold slack is typical and does not degrade Fmax.