Histogram showing negative slack and yet timing passes

[byteit101]

I am working on a design for an ice40hx device, and while looking at the output of nextpnr, I became a bit confused. I was under the impression that negative slack means I have to slow my clock down and that timing shouldn't pass, but nextpnr is reporting it can run at >100MHz of my requested 80MHz, yet the slack histogram (of unknown units, they really should be listed) shows that there are at least two instances of negative slack. The other delays (async) are all smaller than the 9.8ns routing of the main clock, so I'm not sure what the histogram is actually telling me.

What is this actually showing me, and if it is indeed wrong, does it need to be fixed? And if it isn't wrong, can it be better documented?

<snip>
Info: Critical path report for clock 'global_clk$rename$0_$glb_clk' (negedge -> negedge):
<snip>
Info: 3.2 ns logic, 6.6 ns routing
<snip>

Info: Max frequency for clock 'global_clk$rename$0_$glb_clk': 101.50 MHz (PASS at 80.00 MHz)

Info: Clock 'clk' has no interior paths

Info: Max delay <async>                              -> <async>                             : 2.25 ns
Info: Max delay <async>                              -> negedge global_clk$rename$0_$glb_clk: 3.27 ns
Info: Max delay posedge clk                          -> negedge global_clk$rename$0_$glb_clk: 1.20 ns
Info: Max delay negedge global_clk$rename$0_$glb_clk -> <async>                             : 7.88 ns

Info: Slack histogram:
Info:  legend: * represents 34 endpoint(s)
Info:          + represents [1,34) endpoint(s)
Info: [ -1626,   -981) |+
Info: [  -981,   -336) |+
Info: [  -336,    309) | 
Info: [   309,    954) | 
Info: [   954,   1599) | 
Info: [  1599,   2244) |+
Info: [  2244,   2889) |+
Info: [  2889,   3534) |**+
Info: [  3534,   4179) |**+
Info: [  4179,   4824) |**+
Info: [  4824,   5469) |*****+
Info: [  5469,   6114) |*****+
Info: [  6114,   6759) |***+
Info: [  6759,   7404) |******+
Info: [  7404,   8049) |**********+
Info: [  8049,   8694) |*************************************+
Info: [  8694,   9339) |*********************************************************+
Info: [  9339,   9984) |************************************+
Info: [  9984,  10629) |***********************+
Info: [ 10629,  11274) |************************************************************ 

<snip>

[rowanG077]

Which version of nextpnr are you running? Not too long ago there was some significant changes in timing reporting. Including a fix that the slack histogram no longer includes async paths. If you are running on a version prior to that change that could explain the histogram you are seeing. The times in the histogram are picoseconds.

I tried to check if this is occurring with current master using:

module foo(
    input wire clk,
    input wire [20:0] a,
    input wire [20:0] b,
    output reg [20:0] out
);
    reg [20:0] x;
    reg [20:0] y;

    always @(posedge clk) begin
        x <= a;
        y <= b;
        out <= x / y;
    end

endmodule

yosys command: yosys -p "read_verilog ../artifact/test.v; synth_ecp5 -json ../artifact/test.json"
nextpnr command: nextpnr-ecp5 --um5g-25k --package CABGA256 --json ../artifact/test.json --freq 12.0

There I don't see any negative slack.

[rowanG077]

Just some more testing for my own sanity :), this verilog:

module foo(
    input wire clk,
    input wire [19:0] a,
    input wire [19:0] b,
    output reg [19:0] out,
    output wire [19:0] out2,
);
    reg [19:0] x;
    reg [19:0] y;

    always @(posedge clk) begin
        x <= a;
        y <= b;
        out <= x / y;
    end

    assign out2 = a / b;

endmodule

With commit 88714c5 (prior to the timing engine changes) I get this, notice the negative slack:

Info: Max frequency for clock '$glbnet$clk$TRELLIS_IO_IN': 13.46 MHz (PASS at 12.00 MHz)

Info: Max delay <async>                           -> <async>                          : 87.01 ns
Info: Max delay <async>                           -> posedge $glbnet$clk$TRELLIS_IO_IN: 2.61 ns
Info: Max delay posedge $glbnet$clk$TRELLIS_IO_IN -> <async>                          : 2.94 ns

Info: Slack histogram:
Info:  legend: * represents 1 endpoint(s)
Info:          + represents [1,1) endpoint(s)
Info: [ -3678,    607) |*+
Info: [   607,   4892) |+
Info: [  4892,   9177) |*+
Info: [  9177,  13462) |*+
Info: [ 13462,  17747) |*+
Info: [ 17747,  22032) |*+
Info: [ 22032,  26317) |**+
Info: [ 26317,  30602) |*+
Info: [ 30602,  34887) |*+
Info: [ 34887,  39172) |*+
Info: [ 39172,  43457) |*+
Info: [ 43457,  47742) |*+
Info: [ 47742,  52027) |*+
Info: [ 52027,  56312) |**+
Info: [ 56312,  60597) |*+
Info: [ 60597,  64882) |*+
Info: [ 64882,  69167) |*+
Info: [ 69167,  73452) |*+
Info: [ 73452,  77737) |*+
Info: [ 77737,  82022) |************************************************************

With current master I get this:

Info: Max frequency for clock '$glbnet$clk$TRELLIS_IO_IN': 13.46 MHz (PASS at 12.00 MHz)

Info: Max delay <async>                           -> <async>                          : 87.01 ns
Info: Max delay <async>                           -> posedge $glbnet$clk$TRELLIS_IO_IN: 2.61 ns
Info: Max delay posedge $glbnet$clk$TRELLIS_IO_IN -> <async>                          : 2.94 ns

Info: Slack histogram:
Info:  legend: * represents 1 endpoint(s)
Info:          + represents [1,1) endpoint(s)
Info: [  9022,  12515) |** 
Info: [ 12515,  16008) |* 
Info: [ 16008,  19501) |* 
Info: [ 19501,  22994) |* 
Info: [ 22994,  26487) |* 
Info: [ 26487,  29980) |* 
Info: [ 29980,  33473) | 
Info: [ 33473,  36966) |* 
Info: [ 36966,  40459) |* 
Info: [ 40459,  43952) |* 
Info: [ 43952,  47445) |* 
Info: [ 47445,  50938) |* 
Info: [ 50938,  54431) |* 
Info: [ 54431,  57924) |* 
Info: [ 57924,  61417) |* 
Info: [ 61417,  64910) |* 
Info: [ 64910,  68403) |* 
Info: [ 68403,  71896) |* 
Info: [ 71896,  75389) |* 
Info: [ 75389,  78882) |* 

[byteit101]

Ah-ha! I'm using an older version I think:

"nextpnr-ice40" -- Next Generation Place and Route (Version nextpnr-0.6-12-gc5666c47)

It would be great if the output lists the units as picoseconds

[rowanG077]

Yes you are using an older version. I agree with including units in the histogram.