Unclocked register/latch pins with falling edge triggered FFs

[jpf91]

Hi there,

I'm currently running one of my designs through the OpenRoad Flow Scripts flow with IHP PDK and it's complaining about unclocked register/latch pins in 2_1_floorplan.log.

I changed the floorplan script to do a verbose check_setup and had a look at the unclocked registers.
All of them are clocked from one clock and all of them are clocked on the negative clock edge (always @(negedge clk)).

Are falling-edge FFs supposed to work? I can't really seem to find any documentation for that, but maybe I just don't know the term to search for. When I change the verilog to use posedge, it no longer complains.

Of course it's also possible that I just did not constrain that clock properly. However, I don't see any errors about that in the logs. This is the clock definition:

set clk_div32_pin [get_pins -of_object [get_nets -hierarchical {stop.syn.clk_mult}] -filter "direction == output"]
create_generated_clock -name {clk_div32} -source $clk_div16_pin -divide_by 2 $clk_div32_pin

And all clocks in the design are then set to be asynchronous:

set_clock_groups -asynchronous -group {clk} -group {spi_clk} ...

I use the same design with TinyTapeout and have run their OpenLane flow locally. I don't see any unclocked issues there, so I think this should work with proper flow configuration?

[maliberty]

Negative edges are supported but on IHP there was a recent fix PR. You should make sure you are at the head of master.

[jpf91]

Hi @maliberty,

thanks a lot, that gave me some hints where to look and how to debug 😄

So I did some debugging and I think this is a pretty interesting problem:

• I didn't have that PR merged in my checked out version. However, I did also not have unmapped cells in my final netlist.
• I merged the PR locally nevertheless, but as expected it didn't change anything.
• I checked the netlist, yosys maps the required FFs to sg13g2_dfrbp_1. Is there any documentation what that cell is? But based on the discussion here, I assume this is actually a normal FF triggering on rising edge?
• The interesting point is what the CLK inputs are connected to for those cells... The signal is _0037_, whereas I constrained clk_mult. clk_mult exists, but it's not really used....
• My clocks are generated from a series of T-FFs. (Maybe not a good idea, but I want to see whether it works 😉 )

What happened here: My clock divider essentially looks like this:

wire[16:0] q;
assign clk_mult = q[5];

genvar i;
generate for (i = 0; i < 16; i = i+1) 
    begin: gen
        tff inst (.clk(q[i]), .arstn(arstn), .q(q[i+1]));
    end
endgenerate;

The TFF:

module tff(input clk, input arstn, output reg q);
    always @(posedge clk or negedge arstn) begin
        if (arstn == 1'b0)
            q <= 1'b0;
        else
            q <= ~q;
    end
endmodule

You can see that clk_mult should be the non-inverted q.

This signal is routed to shift_mult16.v and used like this:

always @(negedge clk_mult) begin
    if (mult_rst == 1'b1)
        b_latched <= b;
    else
        b_latched <= {1'b0, b_latched[B_WIDTH-1:1]};
end

So I think constraining clk_mult should actually be correct.

Now in the final mapped netlist, for the clock divider:

  (* src = "/home/usr7/cd101-tt/src/hdl/tff.v:11.5-16.8" *)
  sg13g2_dfrbp_1 \stop.syn.clki.gen[4].inst.q$_DFF_PN0_  (
    .CLK(\stop.syn.clki.gen[3].inst.q ),
    .D(_0037_),
    .Q(\stop.syn.clk_mult ),
    .Q_N(_0037_),
    .RESET_B(\stop.syn.clki.arstn )
  );

So it assigned q to clk_mult, which is correct. For the feedback, we need the inverted q. We can get this from Q_N and this is mapped to the artifical net _0037_. Fine so far.

Let's look at the location where the clk_mult is used:

  (* src = "/home/usr7/cd101-tt/src/hdl/shift_mult16.v:12.5-17.8" *)
  sg13g2_dfrbp_1 \stop.syn.filt.m1.b_latched[0]$_DFF_N_  (
    .CLK(_0037_),
    .D(_0005_),
    .Q(\stop.syn.filt.m1.b_bit ),
    .Q_N(_1201_),
    .RESET_B(_1363_)
  );

Actually all instances that trigger on the negative edge (all in this design), now use _0037_ instead of clk_mult. Without thinking too hard about it, I think this should be a valid optimization / mapping. It's now using the positive edge of the inverted clock which should be the same as the negative edge of the original one.

But: It breaks my timing contraints.

If I additionally constrain net __0037__ the warnings in 2_1_floorplan.log are gone. However, with this additional constraint CTS crashes :-) I don't have root rights on my current test setup, so I'm not sure if it's just OOM or proper crash. I can debug this later though...

I could probably also rewrite the original HDL to just make clk_mult the inverted output and make the clocked FFs trigger on the pos edge. Then I assume I could probably constrain clk_mult properly. However, I don't feel like these technology details should leak into the source HDL.

So what do you experts think? I this work opening a bug report? If you think it's a bug, I'll produce a complete, reduced testcase.

If you think it's not an issue, any recommendations how to deal with it in the design? even if it didn't crash CTS, constraining __0037__ is not a great solution, as the name could change in the future.

[rovinski]

In general, creating a reduced test case with good background information is absolutely preferred. In the OR and ORFS repositories, it is fine to submit issues which may or may not be bugs as long as the bug report format is followed (attached test case properly packaged with ORFS, environment, etc.). It will be much easier to determine if there is or is not a bug that way. If it is a bug, it is substantially easier to determine the cause and fix it. If not a bug, we can explain why it isn't and help you resolve your issue.

My first question would be to see the SDC file, as it sounds like there could be some missing constraints between the positive and negative edges. I will say that CTS does much better with positive edge constraints, I am not sure how well it can handle negative edge constraints, so any example designs there will help.