TIL: The default counter example uses a gated clock and posedge FF. The top-level timing reports look promising. Nevertheless I was elaborating on an alternative. I changed the FF in the counter design to negedge, while keeping the gated clock, which is perfectly legal. Always @ (negedge clk) begin // (posedge clk) begin Unfort. the flow inserts ~ 8 delay cells into each soc->mprj line and the top level timing reports went crazy (10ns hold time violation, holy cow). I removed the gated clock as well, still using negedge. assign clk = wb_clk_i; // There are no massive delay cell chains in the netlist but a huge hold time violation. Unfort. the reset coming from the soc is sensitive to the negedge, so I added a posedge FF in the reset tree. reg reset_reg; always @(posedge clk) reset_reg <= reset; Now everything looks fine, no hold time violations anymore, super relaxed, de-risked interface timing and no delay cells. IMHO, this is a reasonable alternative and well suited for medium and large designs (diagram see below). Comments welcome, Cheers ! PS: It’s still worth looking into, why OL interprets the io timing delays wrongly (possibly) and adds a string of delay cells when a gated clock and negedge FFs are used.

The negative-edge clocked wishbone on the user project side has been suggested before and looks like a very good plan to get the best timing margin for a design. I was not aware of the issue of delay chains being inserted; that should be raised as an issue with the openlane developers. But my takeaway from your description is that the positive-edge reset caused the tools to stop inserting the delay chains? I learned recently about the common practice of synchronizing the set/reset inputs of flops to the opposite clock edge so that the reset and clock always happen as far apart as possible, which does make sense.

The SoC WB data\control registers are clocked with rising edge. To avoid hold time issues, someone might want to use falling edge FF in the user design (or inverted clock tree). The SoC WB reset signal is clocked with the falling edge inside the SoC. To avoid hold time issues in the user design, a rising edge FF can be used. I also think it is good alternative to register the root of the reset tree of the user design with the opposite edge as the user design registers, which plays out beautifully in our case. The picture above shows an async reset, but I think the ideas apply to sync reset as well.