asap7 mock-cpu reports a very odd hold WNS

[jeffng-or]

Subject

Describe the bug

asap7 mock-cpu has been reporting a very high hold WNS metric of 1e+42 since at least Nov 2025. The value first appears in the floorplan step:

	"floorplan__timing__hold__ws": 1e+42,

The log file has several complains about the constraints:

[WARNING STA-1554] ./results/asap7/mock-cpu/base/2_1_floorplan.sdc line 112388, 'mult_result[116][1]$_DFF_P_/QN' is not a valid start point.

Matt noticed this when we were looking through some metrics.

We also might want to update the metrics checker to flag very high metrics as a potential issue.

Sending to Arthur J, since it's on his design list.

Expected Behavior

reasonable hold WNS

Environment

current ORFS is demonstrating the problem. orfs git commit tag c5b07be00804be883f1e5ea6486ffc2e0931760b

To Reproduce

make DESIGN_CONFIG=designs/asap7/mock-cpu/config.mk floorplan
grep timing__hold logs/asap7/mock-cpu/base/2_1_floorplan.json

Relevant log output

Screenshots

No response

Additional Context

No response

[oharboe]

mock-cpu Design Objective & Timing Strategy

1. Design Objective: The "Timing Firewall"

The mock-cpu module is an architectural test case designed to simulate a CPU core with a deep clock tree (high insertion delay) that must communicate with the outside world (low latency).

To manage this, the design uses an Asynchronous FIFO (fifo_in / fifo_out) at the boundary.

• Outside World: Operates on clk_uncore (or generic IO timing).
• Internal Core: Operates on clk with a deep pipeline (1024 stages) and high clock latency.

The Goal: Isolate the internal deep clock tree from the IO constraints so that the tool does not attempt to fix false hold violations caused by the large clock insertion delay.

2. The Problem: False Hold Violations

Standard timing constraints (e.g., set_input_delay) are calculated relative to the clock capture edge.

• If the internal clk has a 2ns insertion delay, the tool interprets an input arriving at 0ns as having a massive "head start."
• Result: The tool incorrectly flags a Hold Violation and inserts a chain of delay buffers (hold pins) to match the internal clock latency. This bloats area/power and defeats the purpose of the FIFO.

3. The Solution: Optimization Targets via OPENROAD_HIERARCHICAL

We need to treat the IO paths as Optimization Targets (pure combinational delay limits) rather than synchronous Timing Closure paths. This requires two steps:

1. Visibility: Enable OPENROAD_HIERARCHICAL to "see" the internal pins of the FIFO instances (fifo_in, fifo_out).
2. Constraint: Use set_max_delay -ignore_clock_latency to constrain the path from IO ports to the FIFO pins. This ignores the deep clock tree entirely, preventing hold buffer insertion.

4. Required .sdc Implementation

The constraints.sdc must explicitly target the FIFO boundary pins. Based on the mock_cpu Verilog, the following setup is required:

# ==============================================================================
# MOCK-CPU TIMING FIREWALL
# Use OPENROAD_HIERARCHICAL to isolate deep clock tree from IOs
# ==============================================================================

# 1. Define Optimization Target (e.g., 80ps for ASAP7)
set io_target_delay 0.080

# 2. Identify FIFO Boundary Pins
#    Inputs/Control entering the Core
set fifo_in_data  [get_pins -hierarchical "fifo_in/wdata[*]"]
set fifo_in_ctrl  [get_pins -hierarchical "fifo_in/winc"]
set fifo_out_rinc [get_pins -hierarchical "fifo_out/rinc"]

#    Outputs/Status leaving the Core
set fifo_out_data [get_pins -hierarchical "fifo_out/rdata[*]"]
set fifo_out_ctrl [get_pins -hierarchical "fifo_out/rempty"]
set fifo_in_wfull [get_pins -hierarchical "fifo_in/wfull"]

# 3. Apply Constraints (Ignore Internal Clock Tree)

# --- Input Paths (Port -> FIFO) ---
set_max_delay -ignore_clock_latency $io_target_delay \
    -from [get_ports wdata*] -to $fifo_in_data
set_max_delay -ignore_clock_latency $io_target_delay \
    -from [get_ports winc]   -to $fifo_in_ctrl
set_max_delay -ignore_clock_latency $io_target_delay \
    -from [get_ports rinc]   -to $fifo_out_rinc

# --- Output Paths (FIFO -> Port) ---
set_max_delay -ignore_clock_latency $io_target_delay \
    -from $fifo_out_data -to [get_ports rdata*]
set_max_delay -ignore_clock_latency $io_target_delay \
    -from $fifo_out_ctrl -to [get_ports rempty]
set_max_delay -ignore_clock_latency $io_target_delay \
    -from $fifo_in_wfull -to [get_ports wfull]

# 4. Grouping for Reports
group_path -name "IO_to_FIFO" -from [all_inputs] -to [list $fifo_in_data $fifo_in_ctrl $fifo_out_rinc]
group_path -name "FIFO_to_IO" -from [list $fifo_out_data $fifo_out_ctrl $fifo_in_wfull] -to [all_outputs]

[arthurjolo]

I tried to open the design on the GUI to look at the hold violating paths. But both on timing report and chart windows it doesn't show any paths:

While trying to load the charts for the hold paths I get the following warning form the GUI: [WARNING GUI-0097] All pins are unconstrained. Cannot plot histogram. Check if timing data is loaded!
And when running report_checks for hold paths:

>>>report_checks -path_delay min
No paths found.

[arthurjolo]

The SDC files set manually all the setup constraints, but do not set any hold constraints, plus it sets as false hold paths all paths that cross clocks.

[maliberty]

There are no reg2reg paths. It seems poorly named as there is no cpu in this, just a fifo.

[oharboe]

There are no reg2reg paths. It seems poorly named as there is no cpu in this, just a fifo.

Yes. The use-case that it came from was the clock crossing FIFO that exists in the MegaBoom design outside when the BoomTile where it eventually connects to a clock crossing bridge, typically system bus to memory bus.

I think single-clock-source-and-frequency-two-clock-trees-async-fifo would be more descriptive.

Maybe mesochronous-fifo would be a good name?

Copy and paste this comment into Gemini to learn all about it...