Feature request: optimize counters with constant high order bits

[azonenberg]

Consider the following code:

reg[7:0] dout = 0;
always @(posedge clk) begin
    dout <= dout + 1'h1;
    if(dout == 15)
        dout <= 0;
end

Since "dout" is initialized to zero, and goes back to zero when it hits 15, the high 4 bits can never be nonzero and should be optimized out.

I'll be implementing a new optimization pass for this. It'll be called "opt_counters" and should run during the coarse phase of synthesis.

[azonenberg]

On second thought, it makes more sense to do this in extract_counters. Counter optimization would thus consist of extract_counters followed by techmapping back to RTLIL cells.

[azonenberg]

ed1e3ed adds support for removing unused high-order bits of counters that can be extracted by count_extract.

Keeping this issue open until a full optimization step is added. We need to be able to map extracted counters back to generic RTL for devices without dedicated counter IP, plus expand the types of counters that can be recognized by the pass (#388)

[cliffordwolf]

I don't understand why this is needed at all. Why not simply run abc -dff?

Unfortunately you did not post an mcve, but I created this one from the code snippet you posted:

module test(input clk, output reg [7:0] dout);
initial dout = 0;
always @(posedge clk) begin
    dout <= dout + 1'h1;
    if(dout == 15)
        dout <= 0;
end
endmodule

Running this through yosys -p 'synth; abc -dff; opt -fast; dump' test.v shows us that ABC correctly sets dout[7:4] = 4'b0000:

...
  connect $abc$250$lo0 \dout [0]
  connect $abc$250$lo1 \dout [1]
  connect $abc$250$lo2 \dout [2]
  connect $abc$250$lo3 \dout [3]
  connect \dout [7:4] 4'0000
end

[azonenberg]

Because "abc -dff" also destroys $alu and other cells needed by extract_counter and similar coarse-grained synthesis passes.

In a typical synthesis flow (say synth_greenpak4) you'd run "extract_counter" early on, then techmap internal cells to simplemap cells, then run ABC and finally techmap to the native cell library. By the time you "abc -dff" you already have $_COUNT cells that are potentially larger than they need to be. (If you instead ran "abc -dff" early on, the coarse-grained passes would fail to match the required structures and not infer any counters etc.)

When you techmap these cells to native cells, you can end up needlessly mapping to e.g. a GP_COUNT14 instead of a GP_COUNT8 cell because the original register had constant high-order bits. The optimization can be either done in cells_map.v or in extract_counters, and the latter avoids doing it over and over in every technology library.

Although this optimization may be unnecessary in a technology that does not have dedicated counter IP or library cells (since ABC would make the DFFs constant and then the adder and FF would be trimmed during optimization), it's critical for those that do.

[cliffordwolf]

Okay. Thanks for the explanation @azonenberg.

[azonenberg]

Do you still want to keep this issue assigned to you instead of me? It seems like it would make more sense for me to finish the code because I wrote the original greenpak4_counters pass.