google / skywater-pdk

Open source process design kit for usage with SkyWater Technology Foundry's 130nm node.
https://skywater-pdk.rtfd.io
Apache License 2.0
2.99k stars 390 forks source link

Some magic.lef files have multiple ports per pin causing pin access issues with TritonRoute #304

Open antonblanchard opened 3 years ago

antonblanchard commented 3 years ago

In https://github.com/The-OpenROAD-Project/OpenROAD/issues/580 we are chasing an issue where TritonRoute has problems with pin access on some standard cells (in this particular case sky130_fd_sc_hd__fa_4).

@RTimothyEdwards noticed that the magic.lef files were created with an older version of magic, and some pins have multiple ports. Rerunning the failing test using a LEF converted with a newer version of magic fixes it.

A quick script to look for similar issues in the hd cells finds a number of cells that need fixing:

sky130_fd_sc_hd__a211oi_4.magic.lef
sky130_fd_sc_hd__clkinv_16.magic.lef
sky130_fd_sc_hd__dfbbn_1.magic.lef
sky130_fd_sc_hd__dfbbn_2.magic.lef
sky130_fd_sc_hd__dfbbp_1.magic.lef
sky130_fd_sc_hd__dfrbp_1.magic.lef
sky130_fd_sc_hd__dfrbp_2.magic.lef
sky130_fd_sc_hd__dfrtn_1.magic.lef
sky130_fd_sc_hd__dfrtp_1.magic.lef
sky130_fd_sc_hd__dfrtp_2.magic.lef
sky130_fd_sc_hd__dfrtp_4.magic.lef
sky130_fd_sc_hd__dfsbp_1.magic.lef
sky130_fd_sc_hd__dfsbp_2.magic.lef
sky130_fd_sc_hd__dfstp_1.magic.lef
sky130_fd_sc_hd__dfstp_2.magic.lef
sky130_fd_sc_hd__dfstp_4.magic.lef
sky130_fd_sc_hd__dlclkp_1.magic.lef
sky130_fd_sc_hd__dlclkp_2.magic.lef
sky130_fd_sc_hd__dlclkp_4.magic.lef
sky130_fd_sc_hd__fahcin_1.magic.lef
sky130_fd_sc_hd__fahcon_1.magic.lef
sky130_fd_sc_hd__fah_1.magic.lef
sky130_fd_sc_hd__fa_1.magic.lef
sky130_fd_sc_hd__fa_2.magic.lef
sky130_fd_sc_hd__fa_4.magic.lef
sky130_fd_sc_hd__lpflow_clkbufkapwr_16.magic.lef
sky130_fd_sc_hd__lpflow_clkbufkapwr_1.magic.lef
sky130_fd_sc_hd__lpflow_clkbufkapwr_2.magic.lef
sky130_fd_sc_hd__lpflow_clkbufkapwr_4.magic.lef
sky130_fd_sc_hd__lpflow_clkbufkapwr_8.magic.lef
sky130_fd_sc_hd__lpflow_clkinvkapwr_16.magic.lef
sky130_fd_sc_hd__lpflow_clkinvkapwr_1.magic.lef
sky130_fd_sc_hd__lpflow_clkinvkapwr_2.magic.lef
sky130_fd_sc_hd__lpflow_clkinvkapwr_4.magic.lef
sky130_fd_sc_hd__lpflow_clkinvkapwr_8.magic.lef
sky130_fd_sc_hd__lpflow_decapkapwr_12.magic.lef
sky130_fd_sc_hd__lpflow_decapkapwr_3.magic.lef
sky130_fd_sc_hd__lpflow_decapkapwr_4.magic.lef
sky130_fd_sc_hd__lpflow_decapkapwr_6.magic.lef
sky130_fd_sc_hd__lpflow_decapkapwr_8.magic.lef
sky130_fd_sc_hd__lpflow_isobufsrckapwr_16.magic.lef
sky130_fd_sc_hd__macro_sparecell.magic.lef
sky130_fd_sc_hd__mux2_8.magic.lef
sky130_fd_sc_hd__mux4_2.magic.lef
sky130_fd_sc_hd__mux4_4.magic.lef
sky130_fd_sc_hd__probec_p_8.magic.lef
sky130_fd_sc_hd__sdfbbn_1.magic.lef
sky130_fd_sc_hd__sdfbbn_2.magic.lef
sky130_fd_sc_hd__sdfbbp_1.magic.lef
sky130_fd_sc_hd__sdfrbp_1.magic.lef
sky130_fd_sc_hd__sdfrbp_2.magic.lef
sky130_fd_sc_hd__sdfrtn_1.magic.lef
sky130_fd_sc_hd__sdfrtp_1.magic.lef
sky130_fd_sc_hd__sdfrtp_2.magic.lef
sky130_fd_sc_hd__sdfrtp_4.magic.lef
sky130_fd_sc_hd__sdfsbp_1.magic.lef
sky130_fd_sc_hd__sdfsbp_2.magic.lef
sky130_fd_sc_hd__sdfstp_1.magic.lef
sky130_fd_sc_hd__sdfstp_2.magic.lef
sky130_fd_sc_hd__sdfstp_4.magic.lef
sky130_fd_sc_hd__sdlclkp_4.magic.lef
sky130_fd_sc_hd__xor2_2.magic.lef
sky130_fd_sc_hd__xor2_4.magic.lef

I'll leave it to someone else to decide if we want to recreate all the magic.lef files with a newer version of magic, or just the ones with known issues.

donn commented 3 years ago

Issue persists

antonblanchard commented 3 years ago

I tripped over this again when hardening a macro with sky130_fd_sc_hd__fa_1 cells in it. @RTimothyEdwards any thoughts on how best to fix it?

mattvenn commented 2 years ago

still seems ope

mattvenn commented 2 years ago

we just got caught by this issue:

always @(posedge clk1m_i, negedge rstn_i) begin: clk_xhxx                                                                                                                                                  
            if (!rstn_i) begin                                                                                                                                                                             
                clk10m_o <= 1;                                                                                                                                                                             
            end else begin                                                                                                                                                                                 
                if (count_int==4 || count_int==9) begin                                                                                                                                                    
                    clk10m_o <= ~clk10m_o;                                                                                                                                                                 
                end else begin                                                                                                                                                                             
                    clk10m_o <= clk10m_o;                                                                                                                                                                  
                end                                                                                                                                                                                        
            end                                                                                                                                                                                            
end             

the flops were instantiated as dfbbn, which then led to tritonroute failing with

[INFO DRT-0076]   Complete 100 pins.                                                                                                                                                                       
[ERROR DRT-0073] No ap for _278_/SET_B.
terminate called after throwing an instance of 'std::runtime_error'
  what():  DRT-0073                                                                                  
[ERROR]: during executing: "openroad -exit /openlane/scripts/openroad/or_droute.tcl |& tee >&@stdout /openlane/designs/asic_watch/runs/RUN_2021.12.29_13.25.48/logs/routing/22-tritonRoute.log"
[ERROR]: Exit code: 1                                                                                
[ERROR]: Last 10 lines:                                                                                                                                                                                    
child killed: SIGABRT              

[ERROR]: Please check openroad  log file                                                             
[ERROR]: Dumping to /openlane/designs/asic_watch/runs/RUN_2021.12.29_13.25.48/error.log
RTimothyEdwards commented 2 years ago

This issue was fixed by regenerating the LEF files in the open_pdks installation. This correction/patch has been in open_pdks since November 12.