Resizer Segmentation Fault

[progirep]

Hi all,

I'm trying to harden a macro for the MPW-4 shuttle. The resizer(?) causes huge memory consumption once an OpenSRAM macro that come with the Sky130 PDK is used. In order to track down the issue, I've made a very simple macro design that essentially encapsulates a 1 kB OpenSRAM block with clocked registers. The resizer still consumes ~6 GB of RAM, but this time ends with a segmentation fault. I've got 8 GB of RAM plus 4 GB Swap in my computer and ran only the base Linux desktop in parallel, so this shouldn't be a corner case for out-of-memory handling (I hope).

As reference, here is the complete Verilog description of the macro:

`default_nettype none

module sram1kbwrapper
(
`ifdef USE_POWER_PINS
    inout vccd1,    // User area 1 1.8V supply
    inout vssd1,    // User area 1 digital ground
`endif
      input clk,
      input reset,
      input csb0,
      input web0,
      input [3:0] wmask0,
      input [7:0] addr0,
      input [31:0] din0,
      output reg[31:0] dout0,
      input csb1,
      input [7:0] addr1,
      output reg[31:0] dout1
      );

wire [31:0] sram1_dout0;
wire [31:0] sram1_dout1;
reg sram1_csb0;
reg sram1_web0;
reg sram1_csb1;
reg [31:0] sram1_addr0;
reg [31:0] sram1_din0;
reg [3:0] sram1_wmask0;

   always @(posedge clk) begin
      if (reset) begin
     dout0 <= 0;
     dout1 <= 0;
       sram1_csb0 <= 0;
       sram1_web0 <= 0;
       sram1_csb1 <= 0;
       sram1_addr0 <= 0;
       sram1_addr1 <= 0;
       sram1_wmask0 <= 0;
      end
      else begin
     dout0 <= sram1_dout0;
     dout1 <= sram1_dout1;
       sram1_csb0 <= csb0;
       sram1_web0 <= web0;
       sram1_csb1 <= csb1;
       sram1_addr0 <= addr0;
       sram1_addr1 <= addr1;
       sram1_wmask0 <= wmask0;
      end
   end

sky130_sram_1kbyte_1rw1r_32x256_8 SRAMInternal
     (
     `ifdef USE_POWER_PINS
      .vccd1(vccd1),
      .vssd1(vssd1),
      `endif
      .clk0   (clk),
      .csb0   (sram1_csb0),
      .web0   (sram1_web0),
      .wmask0 (sram1_wmask0),
      .addr0  (sram1_addr0),
      .din0   (sram1_din0),
      .dout0  (sram1_dout0),
      .clk1   (clk),
      .csb1   (sram1_csb1),
      .addr1  (sram1_addr1),
      .dout1  (sram1_dout1)
      );

endmodule

`default_nettype wire

I've tried both using the efabless/openlane:mpw-4 docker image as well as the edalize/openlane-sky130:mpw4 docker image. In both case, I'm getting segfaults. Here is the "reproducible" file:

openroad_issue_reproducible.tar.gz

[progirep]

Oh, by the way, the Verilog example above has multiple errors. But fixing them doesn't make a difference regarding the issue.

[maliberty]

There is a packaging problem: (@donn please note) export EXTRA_LIBS=' /home/ruedi/XilinxImage/Caraval/SkyPDK/sky130A/libs.ref/sky130_sram_macros/lib/sky130_sram_1kbyte_1rw1r_32x256_8_TT_1p8V_25C.lib';

which leads to: Error: resizer.tcl, 23 cannot read file /home/ruedi/XilinxImage/Caraval/SkyPDK/sky130A/libs.ref/sky130_sram_macros/lib/sky130_sram_1kbyte_1rw1r_32x256_8_TT_1p8V_25C.lib.

Please add the missing lib

[progirep]

Oh, ok. I've added the missing file to a new "manual" directory in the "openroad_issue_reproducible" directory and referenced the file in run.tcl, run.sh, and env.* - the previously missing file is part of what open_pdks produces when enabling the Sky130 SRAM macros.

issue.tar.gz

[maliberty]

Your RAM has a very small transition limit:

bus(addr0){
    max_transition       : 0.04;

In addition you have: export PL_RESIZER_MAX_SLEW_MARGIN='20';

so you are trying to fix the slew to 0.032 which is not realistic to achieve. If I used a margin of zero then the design goes through without trouble. I'm not sure how this ram was generated but it is suspect in this regard.

[maliberty]

@jjcherry56 it would be good to harden rsz against such bad inputs.

[progirep]

Thanks for the feedback. The transition limits are coming from the files that open_pkds generates when asking it to also build the SRAM macros. It's weird that they are unrealistic, so I'm now wondering how the projects employing these macros address this requirement.

[maliberty]

@donn @RTimothyEdwards do you know how OL is generating its RAMs?

[RTimothyEdwards]

@maliberty : Macros come directly from the OpenRAM project, specifically pre-built macros that Matt Guthaus made for efabless and which we dropped into the repository at https://github.com/efabless/sky130_sram_macros/. Matt Guthaus has commit privileges to that repository. The open_pdks installer clones that repository and drops the files more or less verbatim into the location cited above (e.g., sky130A/libs.ref/sky130_sram_macro/lib/sky130_sram_1kbyte_1rw1r_32x256_8_TT_1p8V_25C.lib).

[maliberty]

I opened https://github.com/efabless/sky130_sram_macros/issues/9

[jjcherry56]

It tickled a bug in the resizer that is fixed by 789d5b3e9 master origin/master Merge pull request #1496 from jjcherry56/rsz_sm_max_slew