How to avoid Constant-0 drivers added to undriven nets

[cristianomodesti]

Good morning everyone.
I am trying to synthesise a very simple HDL design composed by a LSFR which basically implements a shift register whose input bit is a linear function of the previous content of the register. I made this test just to debug some strange behaviour I got during the implementation of a bigger design.

A hint of this test design can be found in the following code snippet:

module lsfr(
    input  logic clk_i,
    input  logic res_n_i,
    input  logic run_i,
    output logic data_o0,
    output logic data_o1,
    output logic data_o2,
    output logic data_o3,
    output logic data_o4,
    output logic data_o5,
    output logic data_o6,
    output logic data_o7,
    output logic data_o8,
    output logic data_o9,
    output logic data_o10,
    output logic data_o11,
    output logic data_o12,
    output logic data_o13,
    output logic data_o14,
    output logic data_o15,
    output logic data_o16,
    output logic data_o17,
    output logic data_o18,
    output logic data_o19
);

  localparam p_size = 10;//20;
  localparam [p_size-1:0] p_init = 0;

  logic [p_size-1:0] r_lfsr;

  logic c_lfsr_msb;

  always_comb c_lfsr_msb = r_lfsr[p_size-10] ~^ r_lfsr[p_size-07];
        
  always_ff @(posedge clk_i, negedge res_n_i) begin
    if (!res_n_i)begin
      r_lfsr <= p_init;
    end else begin
      if (run_i) begin
        r_lfsr <= {c_lfsr_msb, r_lfsr[p_size-1:1]};
      end
    end
  end

  assign data_o0  = |r_lfsr;
  assign data_o1  = r_lfsr[0];
  assign data_o2  = r_lfsr[1];
  assign data_o3  = r_lfsr[2];
  assign data_o4  = r_lfsr[0];
  assign data_o5  = r_lfsr[0];
  assign data_o6  = r_lfsr[0];
  assign data_o7  = r_lfsr[0];
  assign data_o8  = r_lfsr[0];
  assign data_o9  = r_lfsr[0];
  assign data_o10 = r_lfsr[3];
  assign data_o11 = r_lfsr[4];
  assign data_o12 = r_lfsr[5];
  assign data_o13 = r_lfsr[0];
  assign data_o14 = r_lfsr[0];
  assign data_o15 = r_lfsr[0];
  assign data_o16 = r_lfsr[0];
  assign data_o17 = r_lfsr[0];
  assign data_o18 = r_lfsr[0];
  assign data_o19 = r_lfsr[0];
endmodule

RTL simulation works fine and I get the expected output signals but when I synthesise this design with yosys, I am getting the expected behaviour just for data_o0 - data_o3 and data_o10 - data_o12, whereas the other outputs are seen as non-driven and thus yosys adds a constant-0 driver. In fact, during the yosys opt step, I get the following warning:

################################################################################
# Postprocessing blif 'results/lfsr_yosys_out.blif'
################################################################################
################################################################################
# Generating acitvity data 'results/lfsr.act' and according blif 'results/lfsr_ace2_out.blif'
################################################################################
Line 96: Skipping line ".conn data_o1 data_o13".
Line 97: Skipping line ".conn data_o1 data_o14".
Line 98: Skipping line ".conn data_o1 data_o15".
Line 99: Skipping line ".conn data_o1 data_o16".
Line 100: Skipping line ".conn data_o1 data_o17".
Line 101: Skipping line ".conn data_o1 data_o18".
Line 102: Skipping line ".conn data_o1 data_o19".
Line 103: Skipping line ".conn data_o1 data_o4".
Line 104: Skipping line ".conn data_o1 data_o5".
Line 105: Skipping line ".conn data_o1 data_o6".
Line 106: Skipping line ".conn data_o1 data_o7".
Line 107: Skipping line ".conn data_o1 data_o8".
Line 108: Skipping line ".conn data_o1 data_o9".
Line 109: Skipping line ".conn data_o1 r_lfsr[0]".
Line 110: Skipping line ".conn data_o2 r_lfsr[1]".
Line 111: Skipping line ".conn data_o3 r_lfsr[2]".
Line 112: Skipping line ".conn data_o10 r_lfsr[3]".
Line 113: Skipping line ".conn data_o11 r_lfsr[4]".
Line 114: Skipping line ".conn data_o12 r_lfsr[5]".
Warning: Constant-0 drivers added to 13 non-driven nets in network "lfsr":
data_o4, data_o5, data_o6, data_o7 ...

The synthesis script I am using is the following one:

yosys read_verilog -sv -DSYNTHESIS $::env(SOURCES)
yosys read_verilog -lib $::env(TECHMAP_DIR)/cells_sim.v

# begin:   
   yosys hierarchy -check -top $::env(DESIGN)

# coarse:
    yosys proc
    yosys flatten
    yosys opt_expr
    yosys opt_clean
    yosys check
    yosys opt 
    yosys wreduce
    yosys peepopt
    yosys opt_clean
    yosys techmap -D NO_LUT -map $::env(TECHMAP_DIR)/sub2bbadder.v -map $::env(TECHMAP_DIR)/add2bbadder.v -map +/adff2dff.v
    yosys techmap -D NO_LUT -map +/adff2dff.v
    yosys techmap
    yosys alumacc
    yosys share
    yosys opt 
    yosys fsm
    yosys opt 
    yosys memory -nomap
    yosys opt_clean -purge

# fine:
    yosys opt -full
    yosys memory_map
    yosys opt -full 
    yosys techmap -D NO_LUT -map $::env(TECHMAP_DIR)/sub2bbadder.v -map $::env(TECHMAP_DIR)/add2bbadder.v -map +/adff2dff.v
    yosys techmap -D NO_LUT -map +/adff2dff.v
    yosys techmap
    yosys opt -keepdc 
    yosys abc -lut $::env(LUTS)
    yosys opt -purge 
    yosys opt_clean -purge

#check:
    yosys ltp -noff
    yosys hierarchy -check
    yosys stat
    yosys check

yosys write_blif -conn -top $::env(DESIGN) results/$::env(DESIGN)_yosys_out.blif

The point is that I need those "copy" output signals having the same values (r_lsfr[0]) without having them treated like undriven nets.
Has anybody ever had an issue like this? How can I tell yosys these are needed signals?

Thanks for the help!

[nakengelhardt]

The error you copied does not come from opt, it looks like those warnings are produced by the tool you are using to read the output blif file produced by yosys. You have asked yosys to use the non-standard .conn instead of bufffers with the write_blif -conn flag (see write_blif help), but it appears that tool does not support that. Try removing the -conn flag.

[cristianomodesti]

Hi, thank you so much for your answer. I tried removing the -conn flag as you suggested, but it is not solving the problem.
I am using yosys as the synthesis tool for OpenFPGA and without the -conn, now VPR is complaining about missing pins:

ERROR (00_lsfr_MIN_ROUTE_CHAN_WIDTH) - -->>terminate called after throwing an instance of 'VprError'
ERROR (00_lsfr_MIN_ROUTE_CHAN_WIDTH) - -->>  what():  Error: Activity file does not contain signal data_o1__data_o13__data_o14__data_o15__data_o16__data_o17__data_o18__data_o19__data_o4__data_o5__data_o6__data_o7__data_o8__data_o9

So it looks like still yosys performs some kind of "optimization" and creates a wrong activity file without those pins. Actually I can see a decreasing amount of connection between the abc step and the opt ones. If I comment the last two opt commands during the fine step, I don't get that error but instead I get that clk_i pin is missing in the act description:

ERROR (00_lsfr_MIN_ROUTE_CHAN_WIDTH) - -->>terminate called after throwing an instance of 'VprError'
ERROR (00_lsfr_MIN_ROUTE_CHAN_WIDTH) - -->>  what():  Error: Activity file does not contain signal clk_i

But of course clk_i is used in my design and so I do not understand what's happening inside the tool.

[nakengelhardt]

No idea, again that error is happening in other tools that I don't know anything about. Please ask the developers of OpenFPGA about bugs in their tools!