Standard cell placement under power straps with same metal as standard cell pins causing obstructions for route. about openroad-flow-scripts

[maliberty]

There is a hook in pdn for POST_PDN_TCL (

OpenROAD-flow-scripts/flow/scripts/pdn.tcl

Line 7 in 4ac2d01

if { [info exists ::env(POST_PDN_TCL)] && [file exists $::env(POST_PDN_TCL)] } {

) so you could create a script and set the variable to pick it up.

[maliberty]

Just comment out pdngen in scripts/pdn.tcl

[nchiolino]

Excellent! Thank you very much for looking at that. For now, I am very much in business.

[maliberty]

The improve_placement problem should be fixed with The-OpenROAD-Project/OpenROAD#5143

[maliberty]

I just merged it - please update/rebuild and try again.

[maliberty]

In pdks with more layers you rarely see this so the placer doesn't handle it currently. I suggest putting placement blockages under your stripes to avoid any cells going there as a workaround.

[nchiolino]

Matt, thank you so very much for the super fast response.
Understood. That sounds like a great work around, how would I put placement blockage under the stripes? I apologize if that is somewhat straight forward. Do I handle that in the PDN.tcl file?

[maliberty]

I think it will require some custom scripting. You could see https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/scripts/placement_blockages.tcl as an example of creating blockages (in that case for macro channels).

[nchiolino]

Ok. So if I am understanding this correctly. This script is run every time right now for macros. So would I insert what I need into this script or create a script of my own? Does this script get called in the Makefile?

[nchiolino]

Excellent! I will give that a shot.
Thank you very much for the support.

[nchiolino]

Before this issue is closed, would you like for me to feedback to you if it worked? I will leave that decision up to you.

[maliberty]

Its always nice to hear about success 😄

[nchiolino]

The issue that I am running into right now is I dont know how to get the shape of the POWER and GROUND nets. In the macro version it sets a box after it finds the instances using
foreach inst [$block getInsts] { if {[[$inst getMaster] getType] == "BLOCK"} { set box [$inst getBBox]
But when I go to find nets using $block getNets it does not return the shape of the net. I am assuming. How do I get a box of the nets? Is there a getNetShape or something?

[maliberty]

You'll need to use dbNet::getSWires and then dbSWire::getWires to get the boxes that make up the net.

[nchiolino]

I apologize for bothering you again on this but I think I need some assistance in understanding what these odb objects are doing. I tried modifying the placement_blockage.tcl script to simply place a box of placement blockage of specific x and y size it seems to not be working. I ran the flow past placement and when viewing the layout in the gui I am not seeing the blockage. I have placement blockage view turned on as well. Here is the script.

proc block_stripes {} {
  set block [ord::get_db_block]
  set b [odb::dbBlockage_create $block 200 60 400 200]
 $b setSoft
 puts $b
}

[maliberty]

I think you are making such a small blockage it is hard to see. I tried set b [odb::dbBlockage_create $block 1200 60 4000 2000]

[nchiolino]

Ah yes. I made a bad assumption of the order of magnitude of the box. I see it on my end now. Excellent! Thank you very much.

[nchiolino]

Thank you for helping me with that. It looks like it is sort of working but cells are still placing over that area. Is there a way to set a hard keep out? Sorry for all the questions and thank you for the support.

[maliberty]

Blockages are hard by default

[maliberty]

I can't actually see the placement blockage in your image - would you turn off the stripe and turn on the blockage

[nchiolino]

Oh sorry. Is this image better? Again, it seems to be placing standard cells over the blockage still.

[maliberty]

At what step in the flow are you creating the blockage?

[nchiolino]

The code that is generating that blockage is being implemented in the POST_PDN.tcl file. So it is executed during the PDN step. Should the blockage exist before the PDN script? I notice that it looks for macros before this step, is that critical?

[maliberty]

That should work. Is this something where you can provide a non-proprietary test case?

[nchiolino]

Yes, I did some work to repeat this "issue" with the sky130hd tech. To repeat what I have, I modified the the following:
/flow/designs/sky130hd/gcd/config.mk

export DESIGN_NAME = gcd
export PLATFORM    = sky130hd
export VERILOG_FILES = ./designs/src/$(DESIGN_NICKNAME)/gcd.v
export SDC_FILE      = ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/constraint.sdc
# Adders degrade GCD
export ADDER_MAP_FILE :=
export CORE_UTILIZATION = 20
export CORE_ASPECT_RATIO = 0.3
export CORE_MARGIN       = 2
export PLACE_DENSITY     = 0.65
#export TNS_END_PERCENT = 100
#export DIE_AREA    = 0.0 0.0 86.36 88.88
#export CORE_AREA   = 5.00 5.00 81.36 83.88
# Use custom power grid with core rings offset from the pads
export PDN_TCL = ./designs/$(PLATFORM)/gcd/pdn.tcl
#export EQUIVALENCE_CHECK    =   1
export REMOVE_CELLS_FOR_EQY = sky130_fd_sc_hd__tapvpwrvgnd*

I added the line
export POST_PDN_TCL ?= $(PLATFORM_DIR)/post_pdn.tcl
to /flow/platforms/sky130hd/config.mk
The custom pdn.tcl file that I added here: /flow/designs/sky130hd/gcd/pdn.tcl

####################################
# global connections
####################################
add_global_connection -net VDD -pin_pattern {^VDD$} -power
add_global_connection -net VDD -pin_pattern {^VDDPE$}
add_global_connection -net VDD -pin_pattern {^VDDCE$}
add_global_connection -net VDD -pin_pattern {VPWR}
add_global_connection -net VDD -pin_pattern {vdd}
add_global_connection -net VSS -pin_pattern {^VSS$} -ground
add_global_connection -net VSS -pin_pattern {^VSSE$}
add_global_connection -net VSS -pin_pattern {VGND}
####################################
# voltage domains
####################################
set_voltage_domain -power VDD -ground VSS
####################################
# standard cell grid
####################################
define_pdn_grid -name "Core"
#add_pdn_ring -grid {grid} -layers {met4 met5} -widths {3 3} -spacings {1.6 1.6} -pad_offsets {10 10} -connect_to_pads -starts_with POWER
add_pdn_ring -grid "Core" -layers {met4 met5} -widths 3.0 -spacings 1.6 -core_offsets 10
add_pdn_stripe -layer {met1} -width 0.49  -pitch 5.44  -offset 0.00 -followpins
#add_pdn_stripe -layer {met4} -width 0.96 -spacing 5.00 -pitch 56.00 -offset 2.00 -extend_to_core_ring
add_pdn_stripe -layer {met4} -width 2.96 -spacing 1.00 -pitch 56.00 -offset 2.00 -extend_to_core_ring
add_pdn_stripe -layer {met5} -width 1.60 -pitch 56.00 -offset 2.00 -extend_to_core_ring
add_pdn_connect -layers {met1 met4}
add_pdn_connect -layers {met4 met5}
pdngen
####################################

The next file that was added generates the blockage. It lives here:
/flow/platforms/sky130hd/post_pdn.tcl

proc block_stripes {} {
  set block [ord::get_db_block]
      set b [odb::dbBlockage_create $block 32000 14000 165000 40000]
      $b setSoft
}

The function block_stripes has to then get called in the pdn.tcl script here:
/OpenROAD-flow-scripts/flow/scripts/pdn.tcl

source $::env(SCRIPTS_DIR)/load.tcl
load_design 2_5_floorplan_tapcell.odb 1_synth.sdc "Starting PDN generation"

source $::env(PDN_TCL)
pdngen

if { [info exists ::env(POST_PDN_TCL)] && [file exists $::env(POST_PDN_TCL)] } {
  source $::env(POST_PDN_TCL)
}

block_stripes

# Check all supply nets
set block [ord::get_db_block]
foreach net [$block getNets] {
    set type [$net getSigType]
    if {$type == "POWER" || $type == "GROUND"} {
# Temporarily disable due to CI issues
#        puts "Check supply: [$net getName]"
#        check_power_grid -net [$net getName]
    }
}

if {![info exists save_checkpoint] || $save_checkpoint} {
  if {[info exists ::env(GALLERY_REPORT)]  && $::env(GALLERY_REPORT) != 0} {
    write_def $::env(RESULTS_DIR)/2_floorplan.def
  }
  write_db $::env(RESULTS_DIR)/2_6_floorplan_pdn.odb
}

All other files associated with the sky130hd has not been modified from when I grabbed it from the repo.
Once this is all setup, I ran
make place
and it generated the image attached. You can see that a standard cell has been placed inside the blockage.

Let me know your thoughts.
Thank you

[nchiolino]

Sorry to request more help on this issue but as it turns out, I am terrible at TCL, definitely not my strong suit. That in combination with little to no documentation on the db variable, I think I could use a hand on this script. I have test all the sections of this script apart from the collection of shapes. The set shapset, clip result, and output work. The only portion that I cannot correctly script is the collect shapes portion (lines 12-17).

proc block_stripes {} {
  set tech [ord::get_db_tech]
  set units [$tech getDbUnitsPerMicron]
  set block [ord::get_db_block]

  #
  # Collect up all the stripes as boxes
  #
  #set shapes {}
  #    lappend shapes [odb::newSetFromRect 873399 0 903399 306200]

  set shapes [dbNet::getSWires]
  foreach wires [$wires dbSWire::getWires] {
       set box [$wires getBBox]
       lappend shapes [odb::newSetFromRect [$box xMin] [$box yMin] [$box xMax] [$box yMax]]
    }
  #
  # Set shapeset variable 
  #
  set shapeSet [odb::orSets $shapes]

  #
  # Clip result to the core area
  #
  set core [$block getCoreArea]
  set xl [$core xMin]
  set yl [$core yMin]
  set xh [$core xMax]
  set yh [$core yMax]
  set core_rect [odb::newSetFromRect $xl $yl $xh $yh]
  set shapeSet [odb::andSet $shapeSet $core_rect]

  #
  # Output the blockages
  #
  set rects [odb::getRectangles $shapeSet]
  foreach rect $rects {
      set b [odb::dbBlockage_create $block \
                 [$rect xMin] [$rect yMin] [$rect xMax] [$rect yMax]]
      $b setSoft
   }
}

[maliberty]

I looked at the detailed placer and I think it is not handling such blockages (the global placer does). A workaround would be to generate the blockage creation into a script and then run it before initialize_flooplan so that the rows are cut by these blockages.

[nchiolino]

@maliberty , thank you very much for looking into that. That makes sense to have to generate the shape before it creates the site rows. I apologize for the delayed response, I have been working to get other parts of the flow operating with this technology. I am now back onto this issue and I very much need this to work in order to realize a fully routed design unfortunately.
I started by inserting the block_stripes proc in the floorplan.tcl script below, at this point and unfortunately, it looks like its working too well. It is now cutting the horizontal power strapes and the pdn generation is attempting to connect the met1 strapes with another pair of met2 vertical wires. Any advice on what to do next?

# Initialize floorplan using CORE_UTILIZATION
# ----------------------------------------------------------------------------
} elseif {[info exists ::env(CORE_UTILIZATION)] && $::env(CORE_UTILIZATION) != "" } {
  set aspect_ratio 1.0
  if {[info exists ::env(CORE_ASPECT_RATIO)] && $::env(CORE_ASPECT_RATIO) != ""} {
    set aspect_ratio $::env(CORE_ASPECT_RATIO)
  }

  set core_margin 1.0
  if {[info exists ::env(CORE_MARGIN)] && $::env(CORE_MARGIN) != ""} {
    set core_margin $::env(CORE_MARGIN)
  }

proc block_stripes {} {
  set block [ord::get_db_block]
      set b [odb::dbBlockage_create $block 838399 39100 903399 268899]
      $b setSoft
}
block_stripes

  initialize_floorplan -utilization $::env(CORE_UTILIZATION) \
                       -aspect_ratio $aspect_ratio \
                       -core_space $core_margin \
                       -site $::env(PLACE_SITE)

# Initialize floorplan using DIE_AREA/CORE_AREA

[nchiolino]

@maliberty , I had another idea that I am trying to setup. Is the flow capable of placing a MACRO with no pins and no liberty information in the core? I think that if I can create a BLOCK of met2 obstruction or via obstruction right under the power straps, that the DRC rules will avoid placing a standard cell in that area. Is that equivalent to the blockage we have already tried? I am trying to use the macro place command but cant seem to get it to work.

place_macro
    -macro_name macro_name
    -location {x y}
    [-orientation orientation]

Any thoughts on that idea?

[rovinski]

placing a MACRO with no pins and no liberty information in the core?

Yes

There is the cut_rows command which breaks up rows to remove certain cell sites, and this could be run after power planning is done so that it won't impact the power grid. Unfortunately, it's only set up right now to remove cell sites underneath macros.

If you could create fake macros (they don't even need obstruction layers) over the areas you want to prevent placement, I believe you could run cut_rows to remove the cell sites, and then delete the macros.

I was thinking briefly about how hard it would be to simply add in a manual cut_rows function to remove sites in a user-specified rectangle, but I think that ultimately making the detailed placer respect placement blockages is a better solution.

[maliberty]

It is somewhat equivalent as the macro will just cause the rows to be cut the same as the blockage did. However the OBS will induce spacing requirements that I don't think you want.

[maliberty]

@rovinski note that if dpl obeys the blockage the flow will have to be changed as well. Today gpl will respect blockages around macros but rsz might put some buffers in an otherwise blocked channel between macros. Currently dpl will legalize them there but if we obeyed the blockage they would be moved far away. We would have to remove the macro blockages after gpl. We would need to distinguish mpl created blockages from user ones.

[rovinski]

Hmm, is there a notion of a soft blockage vs. hard blockage? Or just one kind of blockage? I didn't consider that, I was assuming that (no cell site) ≅ (placement blockage). In that case, a manual cut_row function might be useful.

[rovinski]

LEF/DEF Ref seems to have soft blockages: https://coriolis.lip6.fr/doc/lefdef/lefdefref/DEFSyntax.html#Blockages

SOFT
Indicates that the initial placement should not use the area, but later phases, such as timing optimization or clock tree synthesis, can use the blockage area. This can be used to preserve certain areas (such as small channels between blocks) for buffer insertion after the initial placement.

And it seems like it's already in ODB: https://github.com/The-OpenROAD-Project/OpenROAD/blob/6fc686431fbb0dadf024120f912b28d982b899d5/src/odb/include/odb/db.h#L4162-L4165

So it seems like DPL just needs to check if the blockage is soft or not before considering it to be valid.

[maliberty]

The flow is gpl, resize, dpl so dpl would need to distinguish the source of the instance when considering the blockage. Possible but trickier.

[rovinski]

I read it as:
gpl: do not place in soft or hard blockages
rsz: do not place in hard blockages
dpl: do not place in hard blockages

I think that it doesn't necessarily matter what the source of the instance is, just about gpl vs dpl.
If you want to make it more specific to consider the source, then that's an okay interpretation too. But like you said, trickier.

[nchiolino]

Excellent. Thank you both very much for all the feedback. Unfortunately I am not quite sure how to proceed, am I creating a dummy macro and running the cut_rows command? I only found one example of cut_rows being used in the ihp-sg13g2 config file. I did find the mp_test1.tcl example under the mpl2 tools example. I was able to run this example then simply run cut_rows with success. So I understand the flow. However, I cannot figure out how to add an empty macro to my flow design, run cut_rows, then delete the macro later. Any more advice? Thank you very very much again.

[maliberty]

I think the fastest path for now is to add the blockages. It will be some time before dpl can be enhanced.

[nchiolino]

So to be clear, I should add the blockage with a fake macro, then run cut_rows ? How do I delete the macro before place?

[maliberty]

I don't think you need a fake macro is odb::dbBlockage_create is working for you.

[nchiolino]

Unfortunately it is not. If I use odb::dbBlockage_create anywhere after initialize_floorplan it looks like standard cells are not avoiding the placement blockage as seen in the first image below:

I tried inserting the blockage statement in gpl and dpl scripts with the same result.
If I use the blockage statement before initialize_floorplan, it seems to work too well as seen in the second image below:

Does that make it more clear? I can provide more information if you would like.
Thank you

[maliberty]

My thought was to run through pdn generation and write out a script to generate the blockages. Then re-run using that script at initialize_floorplan to cut the rows.

We do need to do some work on improving our blockage support but I think that will work for the short term.

[nchiolino]

Understood, I will give that a try. I am not quite sure how to do that exactly. Should I:

• make floorplan (find the size and location of the blockage I need from the met2 strapes)
• insert blockage statement before initialize_floorplan
• re-run make floorplan.

Will that not produce the same result as image 2 in my last comment?
I really do apologize for all the questions.

[maliberty]

I'm not sure what you mean by "it seems to work too well". Where you have blockages it looks to have cut the rows.

[nchiolino]

Ah yes, I do apologize for being vague on this thread in my later posts, that is my fault. Here is a detailed breakdown of how I am running the flow now, and the result I am getting. I hope this helps clarify some things.

First: I run the flow through PDN to gather vertical met2 power rail location and size for the blockage creation. I have also run the flow through placement this time to show that cells are being placed behind the power rails. So the command is: make place and the result of that is shown in figure 1.

Second: I insert the blockage code into floorplan.tcl here:

# Initialize floorplan using CORE_UTILIZATION
# ----------------------------------------------------------------------------
} elseif {[info exists ::env(CORE_UTILIZATION)] && $::env(CORE_UTILIZATION) != "" } {
  set aspect_ratio 1.0
  if {[info exists ::env(CORE_ASPECT_RATIO)] && $::env(CORE_ASPECT_RATIO) != ""} {
    set aspect_ratio $::env(CORE_ASPECT_RATIO)
  }
  set core_margin 1.0
  if {[info exists ::env(CORE_MARGIN)] && $::env(CORE_MARGIN) != ""} {
    set core_margin $::env(CORE_MARGIN)
  }

proc block_stripes {} {
  set block [ord::get_db_block]
      set b [odb::dbBlockage_create $block 838399 39100 903399 268899]
      $b setSoft
}
block_stripes
  initialize_floorplan -utilization $::env(CORE_UTILIZATION) \
                       -aspect_ratio $aspect_ratio \
                       -core_space $core_margin \
                       -site $::env(PLACE_SITE)

Next, run make nuke, to clear out all previous files. Then re-run the flow through route, so I simply run make. The result of that can be seen in figure 2 below:

At first glance it appears to have worked but upon closer inspection it suffers from two major issues. One, it is not running all met1 horizontal power straps due to cells not being placed there. The only reason there is met1 horizontal straps is becuase I am running -extend_to_core_ring. This can be seen in figure 3 below:

Problem number two is that detail route is failing to find all the pins to route to. I am assuming becuase there are cells on the each side of row blockage that it cant get to? I have pasted a couple of screen shots from the drt error below.


Please let me know if I am running this flow the way you are describing or if you have any more questions in general.
Thanks!

[maliberty]

Would you show a screenshot of one of the failed instances, say output3?

[nchiolino]

Yes, no problem. Here is instance name output3. It looks to be located on the left of the blockage but could be trying to route to the cells on the right of the blockage, maybe.

[nchiolino]

Actually, I think that the power and ground for those bottom cells is the issue. It does not seem to be connected to power and ground but I dont know how to fix the pdn issues.

[maliberty]

The detailed router doesn't care about power connection. I don't think the problem relates to pdn but it just an issue with accessing the cell. You could verify that by not running pdn at all and see if it is the same.

[nchiolino]

Understood. How do I run the flow without PDN? I used to be able to do this by commenting out the PDN file in the config file but I get errors when I do this now.

[nchiolino]

Interesting. I ran the flow with no PDN or blockage comments and am still getting these DRT errors. Here are a couple of screen shots.


They seem to be for different standard cells this time but still the same result overall.

[nchiolino]

I apologize, looks to be a false alarm! During all the changes I was making, I forgot that I was using a version of the LEF standard cells with too much OBS in them. I have a new version of the standard cells that work better with the DRT. It looks like its starting to look good now for routing. I will continue through with this flow and report back how far I got.
Thanks.

[nchiolino]

This is so very close to being 100% working! The only remaining issue is getting that bottom row of power to fill in somehow. Is there a way to run maybe a second grid?

[maliberty]

@gadfort do you have any thoughts on this bottom row?

[nchiolino]

Just to provide some more clarification. Here is what I am seeing in regards to PDN with the blockage.

A majority of the designs that I have done in the past, I have used the -followpins command for the first layer standard cell row power grid. The only way the blockage is working is if I use the -extend_to_core_ring command, but it is not populating that bottom row, and now I am discovering that its also not connecting some met1 rows over the blockage.
Is there a way to re-run pdn for just the core, after place?

[gadfort]

I don't see any reason why the met1 followpins would skip the bottom row, I would need a better understanding of how the floorplan was generated. If you run PDN after you have cut the rows the met1 (which follows the rows) will also get cut. (pdn does not look at standard cells for obstructions, so delaying it would also not help).

[nchiolino]

@gadfort , to me it seems like -followpins is treating each "broken up" chunk of the core as separate core areas that need to be connected with met2 (vertical). So its adding those random met2 vertical straps to connect each core segment. When I do -extend_to_core_ring its treating the core ring as the vertical connections and not inserting the random met2 vertical strips. So it looks like the closest to what I need will be to use -extend_to_core_ring and just post process that last met1 row in GDS.
I also tried playing with the other options like -number_of_straps and that seems to do nothing. Any thoughts on why that would be?

[gadfort]

I think the correct order of operations for this would be:

1. init floorplan
2. generate power grid
3. add blockages
4. cut rows
5. optional remove blockages

This should allow you to use the followpins correctly since all you are attempting to do is hack around detail placements lack of support for the blockage.

[nchiolino]

I cannot seem to cut the rows at any step after init floor plan unless someone can show me a detailed step by step to do that. I have honestly tried to insert the blockage at every step before place and route and it only removes the rows before init floorplan. I think I am stuck with repairing the horizontal met1 rows after it produces GDS. Not a terrible compromise given the alternative.

[maliberty]

I was hoping this wouldn't be that hard to work around. I'll see about handling blockages in legalization next week.

[nchiolino]

No worries at all. I understand that I am using it in a very non-traditional way. It's honestly not in a terrible place given all those constraints. It's producing a fully routed chip which is fantastic for this technology. I really appreciate you looking into it and keep me posted if you find a solution that I can incorporate into this flow.

[maliberty]

The-OpenROAD-Project/OpenROAD#5104 will give hard blockage support in placement legalization which would make a simpler flow possible.

[nchiolino]

Excellent! Thank you very much. I have two questions with this:

1. I am building the tool locally, how do you suggest I import these changes? Do I just simply download the new dpl script and replace the one I have?
2. How does the blockage work now? Do I keep the blockage in the same place as I have it now or do I need to move it into dpl or post_pdn?

Sorry again for all the questions but I cannot thank you enough for the support.

[maliberty]

You can just create the blockages after pdn and then should be obeyed by later placement.

build.sh --latest should give you the more up to date OR version

[nchiolino]

Very awesome. Thank you so much. I will keep you posted on if it I could get it to work on my end.
Thank you

[nchiolino]

@maliberty , I seem to have run into a bug that is supposed to be fixed according to this thread The-OpenROAD-Project/OpenROAD#4125
Here is what I am seeing at the end of a test run.

==========================================================================
finish report_design_area
--------------------------------------------------------------------------
Design area 3008 u^2 27% utilization.

[INFO GUI-0075] Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[ERROR GUI-0013] Unable to find visible display control at Pins.
[ERROR GUI-0070] Error: save_images.tcl, 23 GUI-0013
Error: final_report.tcl, 69 GUI-0070
Command exited with non-zero status 1
Elapsed time: 0:04.06[h:]min:sec. CPU time: user 3.25 sys 0.25 (86%). Peak memory: 221832KB.
make[1]: *** [Makefile:814: do-6_report] Error 1
make: *** [Makefile:814: logs/sky130hd/gcd/base/6_report.log] Error 2

I did ./build_openroad.sh --latest

[nchiolino]

I must have not built the tool properly because it is still placing standard cells inside blockage.

[nchiolino]

Do not know if this helps but here is my env.sh output:

Git commit: a515fc6cc97a7092efd51a28c1414e2fb4e53413

kernel: Linux 6.5.0-28-generic

os: Ubuntu 22.04.4 LTS (Jammy Jellyfish)

cmake version 3.24.2

-- The CXX compiler identification is GNU 11.4.0

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Check for working CXX compiler: /usr/bin/c++ - skipped

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- OpenROAD version: v2.0-13772-ga515fc6cc

-- System name: Linux

-- Compiler: GNU 11.4.0

-- Build type: RELEASE

-- Install prefix: /usr/local

-- C++ Standard: 17

-- C++ Standard Required: ON

-- C++ Extensions: OFF

-- The C compiler identification is GNU 11.4.0

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Check for working C compiler: /usr/bin/cc - skipped

-- Detecting C compile features

-- Detecting C compile features - done

-- Found Python: /usr/bin/python3.10 (found version "3.10.12") found components: Interpreter 

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success

-- Found Threads: TRUE  

-- Performing Test C_COMPILER_SUPPORTS__-Wall

-- Performing Test C_COMPILER_SUPPORTS__-Wall - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wall

-- Performing Test CXX_COMPILER_SUPPORTS__-Wall - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-array-bounds

-- Performing Test C_COMPILER_SUPPORTS__-Wno-array-bounds - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-array-bounds

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-array-bounds - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-nonnull

-- Performing Test C_COMPILER_SUPPORTS__-Wno-nonnull - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-nonnull

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-nonnull - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-maybe-uninitialized

-- Performing Test C_COMPILER_SUPPORTS__-Wno-maybe-uninitialized - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-maybe-uninitialized

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-maybe-uninitialized - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-format-overflow

-- Performing Test C_COMPILER_SUPPORTS__-Wno-format-overflow - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format-overflow

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format-overflow - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-variable

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-variable - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-variable

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-variable - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-function

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-function - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-function

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-function - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-write-strings

-- Performing Test C_COMPILER_SUPPORTS__-Wno-write-strings - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-write-strings

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-write-strings - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-sign-compare

-- Performing Test C_COMPILER_SUPPORTS__-Wno-sign-compare - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-sign-compare

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-sign-compare - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-deprecated

-- Performing Test C_COMPILER_SUPPORTS__-Wno-deprecated - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-deprecated

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-deprecated - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-c++11-narrowing

-- Performing Test C_COMPILER_SUPPORTS__-Wno-c++11-narrowing - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-c++11-narrowing

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-c++11-narrowing - Failed

-- Performing Test C_COMPILER_SUPPORTS__-Wno-register

-- Performing Test C_COMPILER_SUPPORTS__-Wno-register - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-register

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-register - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-format

-- Performing Test C_COMPILER_SUPPORTS__-Wno-format - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal

-- Performing Test C_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal - Failed

-- Performing Test C_COMPILER_SUPPORTS__-fpermissive

-- Performing Test C_COMPILER_SUPPORTS__-fpermissive - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-fpermissive

-- Performing Test CXX_COMPILER_SUPPORTS__-fpermissive - Success

-- Performing Test C_COMPILER_SUPPORTS__-x

-- Performing Test C_COMPILER_SUPPORTS__-x - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-x

-- Performing Test CXX_COMPILER_SUPPORTS__-x - Failed

-- Performing Test C_COMPILER_SUPPORTS__c++

-- Performing Test C_COMPILER_SUPPORTS__c++ - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__c++

-- Performing Test CXX_COMPILER_SUPPORTS__c++ - Failed

-- Performing Test C_COMPILER_SUPPORTS__-std=c++17

-- Performing Test C_COMPILER_SUPPORTS__-std=c++17 - Failed

-- Performing Test CXX_COMPILER_SUPPORTS__-std=c++17

-- Performing Test CXX_COMPILER_SUPPORTS__-std=c++17 - Success

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-but-set-variable

-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-but-set-variable - Success

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-but-set-variable

-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-but-set-variable - Success

-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so

-- TCL header: /usr/include/tcl/tcl.h

-- TCL readline library: /usr/lib/x86_64-linux-gnu/libtclreadline.so

-- TCL readline header: /usr/include/x86_64-linux-gnu

-- Found SWIG: /usr/bin/swig4.0 (found suitable version "4.0.2", minimum required is "4.0")  

-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found version "1.80.0")  

-- boost: 1.80.0

-- Found Python3: /usr/include/python3.10 (found version "3.10.12") found components: Development Development.Module Development.Embed 

-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") 

-- spdlog: 1.8.1

-- Found BISON: /usr/bin/bison (found version "3.8.2") 

-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 

-- STA version: 2.5.0

-- STA git sha: ee8d3d0fa23bfbc69f3e936ff884c3d30f5bfb59

-- System name: Linux

-- Compiler: GNU 11.4.0

-- Build type: RELEASE

-- Build CXX_FLAGS: -O3 -DNDEBUG

-- Install prefix: /usr/local

-- Found FLEX: /usr/bin/flex (found version "2.6.4") 

-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so

-- TCL header: /usr/include/tcl/tcl.h

-- SSTA: 0

-- Found SWIG: /usr/bin/swig4.0 (found suitable version "4.0.2", minimum required is "3.0")  

-- STA executable: /home/nchiolino/OpenROAD-flow-scripts/tools/OpenROAD/src/sta/app/sta

-- Found re2: /opt/or-tools/lib/cmake/re2/re2Config.cmake (found version "9.0.0") 

-- Found Clp: /opt/or-tools/lib/cmake/Clp/ClpConfig.cmake (found version "1.17.7") 

-- Found Cbc: /opt/or-tools/lib/cmake/Cbc/CbcConfig.cmake (found version "2.10.7") 

-- Found SCIP: /opt/or-tools/lib/cmake/scip/scip-config.cmake (found version "8.0.1") 

-- Found OpenMP_CXX: -fopenmp (found version "4.5") 

-- Found OpenMP: TRUE (found version "4.5")  

-- GPU is not enabled

-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so

-- TCL header: /usr/include/tcl/tcl.h

-- GUI is enabled

-- Charts widget is not enabled

-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found version "1.80.0") found components: serialization 

-- Could NOT find VTune (missing: VTune_LIBRARIES VTune_INCLUDE_DIRS) 

-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found suitable version "1.80.0", minimum required is "1.78")  

-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so

-- TCL header: /usr/include/tcl/tcl.h

-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found version "1.80.0") found components: serialization system thread 

-- Found Boost: /usr/local/Number of processor cores: 4

lib/cmake/Boost-1.80.0/BoostConfig.cmake (found version "1.80.0")  

-- Found Eigen3: /usr/local/share/eigen3/cmake/Eigen3Config.cmake (found version "3.4.1") 

-- TCL readline enabled

-- Tcl Extended disabled

-- Python3 enabled

-- Configuring done

-- Generating done

-- Build files have been written to: /tmp/tmp.sv4KVwiTwo

[maliberty]

Git commit: a515fc6cc97a7092efd51a28c1414e2fb4e53413

This should have the change in it. Is it a hard obstruction (you can select it and see in the inspector)?

[nchiolino]

Interesting. It says soft is true. How do I make it a hard obstruction with the code I am using?

proc block_stripes {} {
  set block [ord::get_db_block]
      set a [odb::dbBlockage_create $block 238400 83100 303400 268900]
      set b [odb::dbBlockage_create $block 738399 83100 803400 268900]
      $a setSoft
      $b setSoft
}

I tried doing setHard and it did not like that.

[maliberty]

Just don't call setSoft, they are hard by default

[nchiolino]

Good news, the hard blockage is working as intended after pdn, which is great and I am seeing them as hard. Bad news, its now simply crashing after or during resizing. Sorry about all this.

Stack trace:

 0# 0x00005F6D0DE9EECB in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

 1# 0x00007C58E2242520 in /lib/x86_64-linux-gnu/libc.so.6

 2# pthread_kill in /lib/x86_64-linux-gnu/libc.so.6

 3# raise in /lib/x86_64-linux-gnu/libc.so.6

 4# abort in /lib/x86_64-linux-gnu/libc.so.6

 5# 0x00005F6D0DE9C868 in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

 6# dpl::Grid::initGrid(odb::dbDatabase*, odb::dbBlock*, std::shared_ptr<dpl::Padding>, int, int) in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

 7# dpl::Opendp::initGrid() in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

 8# dpl::Opendp::detailedPlacement() in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

 9# dpl::Opendp::detailedPlacement(int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

10# dpl::detailed_placement_cmd(int, int, bool, char const*) in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

11# 0x00005F6D0DF7AC64 in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

12# TclNRRunCallbacks in /lib/x86_64-linux-gnu/libtcl8.6.so

13# 0x00007C58E66CA028 in /lib/x86_64-linux-gnu/libtcl8.6.so

14# Tcl_EvalEx in /lib/x86_64-linux-gnu/libtcl8.6.so

15# Tcl_Eval in /lib/x86_64-linux-gnu/libtcl8.6.so

16# sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

17# ord::tclAppInit(Tcl_Interp*) in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

18# Tcl_MainEx in /lib/x86_64-linux-gnu/libtcl8.6.so

19# main in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

20# 0x00007C58E2229D90 in /lib/x86_64-linux-gnu/libc.so.6

21# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6

22# _start in /home/nchiolino/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad

Command terminated by signal 6

[maliberty]

Does your blockage extend outside the core area? I could see that causing a problem (which I'll remedy).

[nchiolino]

Yes, that did seem to be the problem causing the seg fault. Here is the new issue that it got to after I fixed the blockage sizes.

[maliberty]

Would you give a screenshot around one of these, eg 069 ?

[nchiolino]

It looks like a placement mess! This is instance 069

[maliberty]

That is after detailed placement? Are those instances marked fixed (check in the inspector)?

[maliberty]

I don't see how adding blockages would have had this effect. Please check for any pilot error.

[nchiolino]

I get a successful result if I run the flow with no PDN or blockage.

I can get all the way to DRT (successful DPL) with no obstructions. Obviously it cant route because of the original problem.

Then when I add the blockage in the POST_PDN.tcl file, I get the result below. I even made sure that the blockage snapped to the row grid, in case that helped. So from my end, the only addition that is making this error occur is adding the blockage. I dont see any description about them being fixed. Here is a screen shot of the inspector with a "bad" cell (095) as well as the error again showing that its during DPL. Is there a chance its still something on my end?

[nchiolino]

Also, I am still getting a GUI error with this new build. It seems to be when it tries to open klayout and proceed with the GDS conversion and end of flow. Here is a screen shot of the error when running the Nandgate45/gcd example. I don't mean to conflict errors in the same stream but I didn't know if these issues were related. It's just new since I did the most recent build. Do I need to file a separate issue?

[maliberty]

That would be a separate issue.

I'm totally perplexed by this. Do you get any messages during detailed_place? Are those instances in the same location they were before detailed_place? Can you run with blockages but no pdn?

[nchiolino]

Ok, I will file a bug in a separate issue.

It still does not seem to work with PDN off. I have attached the log from DPL. Here is a screen shot from right after floorplan (3_1_place_gp_skip_io).

3_5_place_dp.tmp.log
Stupid question. When executing a new build of the tool, does it update all of the script files? I noticed that the blockage additions that I had made to the floorplan.tcl file was still there after I did the new build. Is there a chance that I am running a new OR tool with previous scripts?

[maliberty]

3_1_place_gp_skip_io is before detailed_place has been run so it is too early in the flow to evaluate. You need to look at 3_5_place_dp

[maliberty]

build.sh updates the OR submodule but does not update ORFS itself.

[nchiolino]

Yea, I see that now. I tried to run the flow with updated ORFS and nothing works so I will need some time to untangle this knot. My apologies.

[nchiolino]

@maliberty , I was able to get a fresh build of ORFS working with the latest OR and unfortunately I am having the same issue. Something is happening during DRT with the obstructions that is breaking it. Have you run this fix with ORFS or just OR under the test directory?

[maliberty]

I suppose you meant dpl not drt. Is this something where you could make an equivalent test case on a public PDK? Its getting hard to make much progress without data.

[nchiolino]

Yes, my apologies, I meant DPL.
I have re-created the issue with the sky130hd technology pointing at the gcd design. Here is how I re-created the issue:

1. Created a POST_PDN file here: /flow/platforms/sky130hd/post_pdn.tcl
   Its contents are:

proc block_stripes {} {
  set block [ord::get_db_block]
      set a [odb::dbBlockage_create $block 29440 18800 41289 73680]
}
block_stripes

2. Added the POST_PDN env viable in the platform config file:
   /flow/platforms/sky130hd/config.mk
   Its contents are:

#--------------------------------------------------------
# Floorplan
# -------------------------------------------------------

# Placement site for core cells
# This can be found in the technology lef
export PLACE_SITE = unithd

# IO Placer pin layers
export IO_PLACER_H = met3
export IO_PLACER_V = met2

# Define default PDN config
export PDN_TCL ?= $(PLATFORM_DIR)/pdn.tcl
export POST_PDN_TCL ?= $(PLATFORM_DIR)/post_pdn.tcl

# Endcap and Welltie cells
export TAPCELL_TCL = $(PLATFORM_DIR)/tapcell.tcl

export MACRO_PLACE_HALO ?= 40 40
export MACRO_PLACE_CHANNEL ?= 80 80

3. run make
   Everything else for the gcd example was unchanged. Here is the result I got:
   
   

[nchiolino]

I dont mean to add to the thread too much here but I had a hunch that I wanted to test. I drastically reduced the size of the blockage and it reduced the number of misplaced gates down to one but still produced the same error as before. However, and this might be very off so bear with me, I realized that since the blockage is being inserted into the core area after floor planning, is there a chance that the core utilization calculation is not calculating properly because its calculating the core area without the blockage? Would that be effecting the DPL script?

[maliberty]

Thanks I am able to reproduce it and will take a look.

[maliberty]

Though I get the same errors I don't have the same layout:

This looks like it has been mostly legalized. Are you showing the input rather than the output?

[nchiolino]

Which file are you loading in the GUI?

[maliberty]

Which file are you loading in the GUI?

Since it fails no file is written. I just ran that step in the GUI.

[nchiolino]

Oh, then I definitely loading the input I suppose. I don't know how to run that step in the GUI unfortunately.

[maliberty]

Oh, then I definitely loading the input I suppose. I don't know how to run that step in the GUI unfortunately.

#2023 should simplify it by writing 3_5_place_dp-failed.odb

[maliberty]

The problem is not in detailed_placement but in improve_placement. Short term you can comment that out in your flow while I work on fixing it.

[nchiolino]

@maliberty , unfortunately I am getting the same result as before.

[nchiolino]

Im so sorry but it looks to be behaving the same. Did I not get the latest version of OR?

[maliberty]

How are you building OR? The output of openroad -version would be helpful

[nchiolino]

I follow the flow build instructions:

git clone --recursive https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
cd OpenROAD-flow-scripts
sudo ./setup.sh
./build_openroad.sh --local

My openroad version is: v2.0-13842-geef07d637