search

The-OpenROAD-Project / OpenROAD-flow-scripts

OpenROAD's scripts implementing an RTL-to-GDS Flow. Documentation at https://openroad-flow-scripts.readthedocs.io/en/latest/
https://theopenroadproject.org/
Other
282 stars 262 forks source link

SRAM macro not getting picked up by the flow #175

Closed lakshmi-sathi closed 2 years ago

lakshmi-sathi commented 2 years ago

Describe the bug The flow just doesn't seem to pick up the SRAM macro for this manycore tile compute mesh design (bsg_manycore_tile_compute_mesh_real). It is hacking up and using an existing SRAM macro for the SRAM configurations that it requires. In the log for the macro placement step, this message is noted - 'No macros found: Skipping macro_placement'. The logs of the run are placed here: https://github.com/bsg-idea/bsg_sky130_designs/tree/test_sky130/designs/bsg_manycore_tile_compute_mesh_real/logs

Expected behavior The SRAM macro getting picked up by the flow.

Environment

File Uploads Just have to place this folder in the 'designs/sky130hd/' directory and run it as usual for reproducing the issue: https://github.com/bsg-idea/bsg_sky130_designs/tree/test_sky130/designs/bsg_manycore_tile_compute_mesh_real

@tspyrou @taylor-bsg

maliberty commented 2 years ago

@rovinski do you have time to take a look at this?

tspyrou commented 2 years ago

@rovinski assign to me if you don't have time to look at it.

taylor-bsg commented 2 years ago

@tspyrou Seems like Austin may be busy

rovinski commented 2 years ago

Hi @lakshmi-sathi this just got lost in my notifications. It looks like you aren't reading in the memory lib. You need to add the line:

ADDITIONAL_LIBS = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/sky130_sram_1kbyte_1rw1r_8x1024_8.lib

Blackbox verilog files have not been used for quite a while; OpenROAD requires a lib file for all macros, so you should remove the VERILOG_FILES_BLACKBOX line.

If this is a real RAM, you will need to include the GDS file under ADDITIONAL_GDS as well, otherwise you will not get a valid GDS (check for errors in 6_1_merge.log)

lakshmi-sathi commented 2 years ago

@rovinski I had previously tried with ADDITIONAL_LIBS but it wasn't working for me. I tried again just like you mentioned and here is what I get in the macro placement log:

OpenROAD 1 v2.0-880-gd1c7001ad
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
[INFO ODB-0222] Reading LEF file: ./platforms/sky130hd/lef/sky130_fd_sc_hd.tlef
[INFO ODB-0223]     Created 11 technology layers
[INFO ODB-0224]     Created 25 technology vias
[INFO ODB-0226] Finished LEF file:  ./platforms/sky130hd/lef/sky130_fd_sc_hd.tlef
[INFO ODB-0222] Reading LEF file: ./platforms/sky130hd/lef/sky130_fd_sc_hd_merged.lef
[INFO ODB-0225]     Created 437 library cells
[INFO ODB-0226] Finished LEF file:  ./platforms/sky130hd/lef/sky130_fd_sc_hd_merged.lef
[INFO ODB-0222] Reading LEF file: ./designs/sky130hd/bsg_manycore_tile_compute_mesh_real/sky130_sram_1kbyte_1rw1r_8x1024_8.lef
[WARNING ODB-0205] The LEF UNITS DATABASE MICRON convert factor (2000) is greater than the database units per micron (1000) of the current technology.
[INFO ODB-0225]     Created 1 library cells
[INFO ODB-0226] Finished LEF file:  ./designs/sky130hd/bsg_manycore_tile_compute_mesh_real/sky130_sram_1kbyte_1rw1r_8x1024_8.lef
[INFO ODB-0127] Reading DEF file: ./results/sky130hd/bsg_manycore_tile_compute_mesh_real/base/2_3_floorplan_tdms.def
[INFO ODB-0128] Design: bsg_manycore_tile_compute_mesh
[INFO ODB-0130]     Created 1263 pins.
[INFO ODB-0131]     Created 35764 components and 206260 component-terminals.
[INFO ODB-0133]     Created 38105 nets and 134730 connections.
[INFO ODB-0134] Finished DEF file: ./results/sky130hd/bsg_manycore_tile_compute_mesh_real/base/2_3_floorplan_tdms.def
No macros found: Skipping macro_placement
Elapsed time: 0:05.22[h:]min:sec. Average CPU: 61%. Peak memory: 138704KB.

It still seems to skip the macro placement. Here is the config I am giving (I have removed VERILOG_FILES_BLACKBOX and I have added ADDITIONAL_LIBS, I am yet to add the GDS, just thought to see if it'll pick up the macro first):

export DESIGN_NICKNAME = bsg_manycore_tile_compute_mesh_real
export DESIGN_NAME = bsg_manycore_tile_compute_mesh
export PLATFORM    = sky130hd

export VERILOG_FILES = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/bsg_manycore_tile_compute_mesh.v \
        ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/hard_mem_1rw_byte_mask_d1024_w32_wrapper.v \
        ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/hard_mem_1rw_d1024_w46_wrapper.v

export SDC_FILE      = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/bsg_manycore_tile_compute_mesh.sdc
export RCX_RULES     = $(PLATFORM_DIR)/rcx_patterns.rules

export ADDITIONAL_LEFS = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/sky130_sram_1kbyte_1rw1r_8x1024_8.lef
export ADDITIONAL_LIBS = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/sky130_sram_1kbyte_1rw1r_8x1024_8.lib

export _VDD_NET_NAME = vccd1
export _GND_NET_NAME = vssd1

export MACRO_PLACE_CHANNEL = 160 160

export DIE_AREA    = 0 0 3800 3080
export CORE_AREA   = 57 28 3420 2800

The issue still persists after these changes to the config. Could you please give me a hint of what else it could be that I am missing?

maliberty commented 2 years ago

Your problem is:

[WARNING ODB-0205] The LEF UNITS DATABASE MICRON convert factor (2000) is greater than the database units per micron (1000) of the current technology.

this really should be an error as we disallow the ram cell on this basis.

lakshmi-sathi commented 2 years ago

I'm using the pre-built SRAM configuration made available via this repo: https://github.com/efabless/sky130_sram_macros/tree/main/sky130_sram_1kbyte_1rw1r_8x1024_8

Is this an issue with how the SRAMs were generated? These SRAMs seem to be developed for use with RTL2GDS flows for sky130, am I right?

maliberty commented 2 years ago

This is an issue for efabless to fix. Please open an issue with that repo. I'll keep this issue just for the warning vs error update.

maliberty commented 2 years ago

Fixed with https://github.com/The-OpenROAD-Project/OpenROAD/pull/1214

taylor-bsg commented 2 years ago

@mguthaus there seems to be a problem with interfacing the Sky130 SRAM LEFs to OpenRoad?

maliberty commented 2 years ago

@mguthaus the LEF needs to be in 1000 dbu/uu in skywater

mguthaus commented 2 years ago

HI @maliberty, where is that specified? I've been using 2000 in multiple tape outs through OpenLane.

maliberty commented 2 years ago

@mguthaus https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/ac7fb61f06e6470b94e8afdf7c25268f62fbd7b1/tech/sky130_fd_sc_hd.tlef#L26

mguthaus commented 2 years ago

Actually, the 2000 is not correct. It should be 1000. It must be that OpenLane just ignores this. My other technologies used 2000 and didn't expose that this was hard coded.

mguthaus commented 2 years ago

Also, the actual numbers are assuming it was 1000, so just modifying that line should be fine!

maliberty commented 2 years ago

It is not ignored (hence the warn/error above), it is wrong: https://github.com/efabless/sky130_sram_macros/blob/a4066fe72816cb8554303cb1faef6abf1377cb28/sky130_sram_1kbyte_1rw1r_8x1024_8/sky130_sram_1kbyte_1rw1r_8x1024_8.lef#L6

mguthaus commented 2 years ago

I went through the OpenLane flow and my design passed DRC, LVS, and other checks, so shrug

maliberty commented 2 years ago

@mguthaus sorry I just mean it is wrong as is. If just modifying to line is enough then that is great. Can you file a PR to that repo to fix it?

maliberty commented 2 years ago

and all the other rams

mguthaus commented 2 years ago

Yes, it is fixed.

taylor-bsg commented 2 years ago

Thanks Matt!

On Wed, Oct 20, 2021 at 11:37 AM Matt Guthaus @.***> wrote:

Yes, it is fixed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues/175#issuecomment-947935024, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AEH3XD633KMT2ECSDDUH4D6TANCNFSM5FDUZ3KQ .