search

YosysHQ / yosys

Yosys Open SYnthesis Suite
https://yosyshq.net/yosys/
ISC License
3.31k stars 860 forks source link

Instance of empty module remains in results of mxe synthesis #1506

Open Chopper455 opened 4 years ago

Chopper455 commented 4 years ago

Steps to reproduce the issue

When I synthesized 2D fht project from opencores I encountered problem concerning module wrapper for block ram instance in win-mxe build of yosys. In linux design was synthesizing just fine, but in windows shadow instance remains in edif file. Module had synthesis translate_off directives, so they were cleaned out along with all the contents of the wrapper module. The only thing remaining is the empty module "dpsram_128x16". And this instance remains in edif file, one output port without connected wires even is declared as zero-size. shadow_inst_test.zip

I've compiled with latest commit 7ea0a59. Both in xilinx target

read_verilog "../dpsram_128x16_new.v"
read_verilog "../mtx_trps_8x8_dpsram.v"
synth_xilinx -top mtx_trps_8x8_dpsram -family xc7 -edif synthesis_xilinx.edf -flatten

and in generic internal library

read_verilog "../dpsram_128x16_new.v"
read_verilog "../mtx_trps_8x8_dpsram.v"
hierarchy -check -top mtx_trps_8x8_dpsram
flatten
synth -top mtx_trps_8x8_dpsram
clean
write_edif -pvector bra synthesis_generic.edf

Expected behavior

When it is synthesized in Xubuntu 18.04, it works OK. for xilinx target

3.46. Printing statistics.

=== mtx_trps_8x8_dpsram ===

Number of wires: 53 Number of wire bits: 130 Number of public wires: 14 Number of public wire bits: 67 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 74 BUFG 1 FDCE 16 LUT1 18 LUT3 13 LUT4 1 LUT6 1 MUXCY 11 XORCY 13

Estimated number of LCs: 17

3.47. Executing CHECK pass (checking for obvious problems). checking module mtx_trps_8x8_dpsram.. found and reported 0 problems.

3.48. Executing EDIF backend. Warning: Exporting x-bit on (portRef (member mem_data 0)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 1)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 2)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 3)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 4)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 5)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 6)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 7)) as zero bit.

Warnings: 11 unique messages, 11 total End of script. Logfile hash: ae0ebed2f3 CPU: user 3.32s system 0.56s, MEM: 112.43 MB total, 79.43 MB resident Yosys 0.9+932 (git sha1 7ea0a593, clang 6.0.0-1ubuntu2 -fPIC -Os) Time spent: 45% 1x share (1 sec), 38% 20x read_verilog (1 sec), ...

and for internal library target

5.26. Printing statistics.

=== mtx_trps_8x8_dpsram ===

Number of wires: 44 Number of wire bits: 109 Number of public wires: 14 Number of public wire bits: 67 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 57 $ANDNOT 5 $AND 6 $_DFFPN0 16 $MUX 11 $NAND 4 $OR 1 $XOR 14

5.27. Executing CHECK pass (checking for obvious problems). checking module mtx_trps_8x8_dpsram.. found and reported 0 problems.

  1. Executing EDIF backend. Warning: Exporting x-bit on (portRef (member mem_data 0)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 1)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 2)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 3)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 4)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 5)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 6)) as zero bit. Warning: Exporting x-bit on (portRef (member mem_data 7)) as zero bit.

Warnings: 11 unique messages, 11 total End of script. Logfile hash: 96f87b8dec CPU: user 0.08s system 0.01s, MEM: 46.16 MB total, 12.66 MB resident Yosys 0.9+932 (git sha1 7ea0a593, clang 6.0.0-1ubuntu2 -fPIC -Os) Time spent: 21% 6x read_verilog (0 sec), 20% 14x opt_clean (0 sec), ...

Actual behavior

But when the same is synthesized in windows using MXE build, some shadow instance appears, even with flattening applied.

For xilinx target:

3.46. Printing statistics.

=== mtx_trps_8x8_dpsram ===

Number of wires: 59 Number of wire bits: 151 Number of public wires: 18 Number of public wire bits: 86 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 82 BUFG 1 FDCE 17 LUT1 21 LUT3 14 LUT4 1 LUT6 1 MUXCY 12 XORCY 14 dpsram_128x16 1

Estimated number of LCs: 19

3.47. Executing CHECK pass (checking for obvious problems). checking module mtx_trps_8x8_dpsram.. found and reported 0 problems.

3.48. Executing EDIF backend.

Warnings: 1 unique messages, 1 total End of script. Logfile hash: c9f608111e Yosys 0.9+932 (git sha1 7ea0a593, i686-w64-mingw32.static-g++ 5.5.0 -Os) Time spent: 1% 20x read_verilog (0 sec), 1% 12x opt_expr (0 sec), ...

and for internal library target

5.26. Printing statistics.

=== mtx_trps_8x8_dpsram ===

Number of wires: 49 Number of wire bits: 129 Number of public wires: 18 Number of public wire bits: 86 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 63 $_DFFPN0 17 $MUX 12 $NAND 6 $NOR 1 $NOT 2 $ORNOT 6 $OR 3 $XNOR 9 $XOR 6 dpsram_128x16 1

5.27. Executing CHECK pass (checking for obvious problems). checking module mtx_trps_8x8_dpsram.. found and reported 0 problems.

  1. Executing EDIF backend.

Warnings: 1 unique messages, 1 total End of script. Logfile hash: 0cfcdaf29d Yosys 0.9+932 (git sha1 7ea0a593, i686-w64-mingw32.static-g++ 5.5.0 -Os) Time spent: 2% 14x opt_clean (0 sec), 2% 12x opt_expr (0 sec), ...

What is bad, that resulting declaration in EDIF file of the module "dpsram_128x16" becomes inaccurate.

(cell dpsram_128x16
  (cellType GENERIC)
  (view VIEW_NETLIST
    (viewType NETLIST)
    (interface
      (port (array (rename addra "addra[6:0]") 7) (direction INPUT))
      (port (array (rename addrb "addrb[6:0]") 7) (direction INPUT))
      (port clka (direction INPUT))
      (port clkb (direction INPUT))
      (port (array (rename dina "dina[15:0]") 16) (direction INPUT))
      (port (array (rename dinb "dinb[15:0]") 16) (direction INPUT))
      (port (array (rename douta "douta[15:0]") 0) (direction OUTPUT))
      (port (array (rename doutb "doutb[15:0]") 16) (direction OUTPUT))
      (port ena (direction INPUT))
      (port enb (direction INPUT))
      (port wea (direction INPUT))
      (port web (direction INPUT))
    )
  )
)

We can see, that port douta that was unconnected in instance suddenly becomes zero-sized as if module was deleted, instance remained and module interface was constructed anew, but renaming with original port name and msb/lsb range remains.

daveshah1 commented 4 years ago

The default behaviour of the Verilog frontend is to turn empty modules into blackboxes; so their instances would remain as cells even after flattening (this can be disabled with read_verilog -noblackbox)

Nonetheless, the difference between mxe and Xubuntu are concerning - with Xubuntu seemingly behaving incorrectly, as is the odd port width in the EDIF.

As another data point, Arch Linux gives the same behaviour as mxe.