Unable to complete IO pad placement

[vijayank88]

Subject

Describe the bug

With latest ICeWall, using FOOTPRINT_TCL unable to complete floorplan stage for sky130hd/coyote_tc. Reference example took from here coyote_pad.tcl is footprint Tcl file.

Expected Behavior

Complete floorplan with pad placement

Environment

[WARNING] Your current OpenROAD version is outdated.
It is recommened to pull the latest changes.
If problem persists, file a github issue with the re-producible test case.
kernel: Linux 3.10.0-1160.49.1.el7.x86_64
os: CentOS Linux 7 (Core)
cmake version 3.24.2
CMake Error at CMakeLists.txt:110 (message):
  Insufficient gcc version.  Found 4.8.5, but require >= 8.3.0.


-- The CXX compiler identification is GNU 4.8.5
-- 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-8118-gb95ce9901
-- Configuring incomplete, errors occurred!

To Reproduce

Due to file size limit uploaded here: https://slack-files.com/T01699QAZBQ-F058MLGKLLU-6723759577 floorplan_coyote_tc_sky130hd_base_2023-05-19_08-10.tar.gz

Relevant log output

--------------------------------------------------------------------------
Warning: There is 1 input port missing set_input_delay.
Warning: There are 5 unclocked register/latch pins.
Warning: There are 255 unconstrained endpoints.
number instances in verilog is 167002
[WARNING IFP-0028] Core area lower left (210.000, 210.000) snapped to (210.220, 212.160).
[INFO IFP-0001] Added 1535 rows of 10390 site unithd with height 1.
Error: floorplan.tcl, 67 key "types" not known in dictionary
Elapsed time: 0:22.71[h:]min:sec. CPU time: user 21.71 sys 0.99 (99%). Peak memory: 1002776KB.
make: *** [results/sky130hd/coyote_tc/base/2_1_floorplan.odb] Error 1

Screenshots

No response

Additional Context

No response

[maliberty]

@gadfort do you have time to look at this?

[gadfort]

@maliberty without running it, I think the issue is the call to the old PDN: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/0f102f7f4f30d4cb77076ec372bb00fa4cd9617c/flow/scripts/floorplan.tcl#LL66C3-L66C21

[maliberty]

@vijayank88 would you remove that line and try again.

[vijayank88]

@maliberty @gadfort If I remove initialize_padring flow completes with updated PDN_TCL. But getting following warnings

[WARNING PDN-0189] Supply pin vdd of instance u_coyote.r2f.rocket.RocketTile.icache.icache.tag_array.mem.macro_mem.macro_mem is not connected to any net.
[WARNING PDN-0189] Supply pin gnd of instance u_coyote.r2f.rocket.RocketTile.icache.icache.tag_array.mem.macro_mem.macro_mem is not connected to any net.
[WARNING PDN-0189] Supply pin DRN_HVC of instance vzz_0 is not connected to any net.
[WARNING PDN-0189] Supply pin SRC_BDY_HVC of instance vzz_0 is not connected to any net.
..........
[WARNING PDN-0110] No via inserted between met1 and met4 at (3805.4700, 1599.1200) - (3805.5800, 1599.6000) on VSS
[WARNING PDN-0110] No via inserted between met1 and met4 at (3805.4700, 1811.2800) - (3805.5800, 1811.7600) on VSS

Seems need update for supply pins vdd, vss, DRN_HVC, SRC_BDY_HVC in latest pdn.tcl

[vijayank88]

Now it's got stuck at below error during GPL

[ERROR GRT-0042] Pin clk_i does not have geometries in a valid routing layer.
Error: global_place.tcl, 51 GRT-0042
Elapsed time: 9:53.48[h:]min:sec. CPU time: user 587.98 sys 5.29 (99%). Peak memory: 1667008KB.
make: *** [results/sky130hd/coyote_tc/base/3_3_place_gp.odb] Error 1

[maliberty]

what layer(s) are the geometries of that pin on?

[vijayank88]

@maliberty In old strategy there is option pin_layer met5 to select layer for the pin. With latest pad placement how do we set? Here is the IO placement ODB file: https://slack-files.com/T01699QAZBQ-F059M9NTHC3-dbbdcb35f5

[maliberty]

@gadfort would you answer "In old strategy there is option pin_layer met5 to select layer for the pin."

[gadfort]

my guess is this is because there are no overlaps (bondpads) placed in the padring, so there are no pins created.

[vijayank88]

Facing following error with updated files.

Floorplan check_setup
--------------------------------------------------------------------------
Warning: There is 1 input port missing set_input_delay.
Warning: There are 5 unclocked register/latch pins.
Warning: There are 255 unconstrained endpoints.
number instances in verilog is 167002
[WARNING IFP-0028] Core area lower left (210.000, 210.000) snapped to (210.220, 212.160).
[INFO IFP-0001] Added 1535 rows of 10825 site unithd with height 1.
[ERROR PAD-0002] u_rocc_mem_resp_data_o_56_.u_io/AMUXBUS_A (u_rocc_mem_resp_data_o_56_.AMUXBUS_A) and u_rocc_mem_resp_data_o_57_.u_io/AMUXBUS_A (u_rocc_mem_resp_data_o_57_.AMUXBUS_A) are touching, but are connected to different nets
Error: skywater130_coyote_tc.tcl, 235 PAD-0002
Elapsed time: 0:34.27[h:]min:sec. CPU time: user 33.13 sys 1.12 (99%). Peak memory: 1003248KB.
make: *** [results/sky130hd/coyote_tc/base/2_1_floorplan.odb] Error 1

If we provide space between the IO pads also getting same error. Test case attached here: https://slack-files.com/T01699QAZBQ-F05AYSH6L8Y-92c48377aa

[gadfort]

@vijayank88 When you call connect_by_abutment the command is attempting to complete the signals in the ring, but in this case you have two different signal names connected together, so either you are missing a splitter cell or you have an issue in your RTL that needs to corrected.

[vijayank88]

@maliberty @gadfort For IO pads which cells to use? Pad cells from efabless https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/f6ccc16bc0c7147f67a39284788ad4c770881f09/flow/designs/sky130hd/coyote_tc/config.mk#LL36C40-L36C76 or from sky130hd https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/pad/test/skywater130_io_fd/lef ?

[vijayank88]

@vijayank88 When you call connect_by_abutment the command is attempting to complete the signals in the ring, but in this case you have two different signal names connected together, so either you are missing a splitter cell or you have an issue in your RTL that needs to corrected.

@gadfort Can you provide splitter cell name?

[gadfort]

Contributor

I used sky130_ef_io__bare_pad but the IO library is a little inconsistent, so that took me some trial and error to get the bondpads placed correctly https://github.com/siliconcompiler/zerosoc/blob/main/openroad/padring.tcl

[gadfort]

@vijayank88 When you call connect_by_abutment the command is attempting to complete the signals in the ring, but in this case you have two different signal names connected together, so either you are missing a splitter cell or you have an issue in your RTL that needs to corrected.

@gadfort Can you provide splitter cell name?

@vijayank88 I cannot, for the testcase in OpenROAD, it wasn't needed and I don't see one. I think it might be a good idea to take a look at the design you are trying to enable and make sure it doesn't contain any problems, otherwise you will have to work around those first before assembling the padring.

[vijayank88]

@gadfort I jsut checked the unit test netlist and latest flow generated netlist. Found following difference with the connections

Latest netlist connection

    .AMUXBUS_A(\u_rocc_mem_resp_data_o_56_.AMUXBUS_A ),
    .AMUXBUS_B(\u_rocc_mem_resp_data_o_56_.AMUXBUS_B ),

Unit test connection

.AMUXBUS_A(AMUXBUS_A ),
    .AMUXBUS_B(AMUXBUS_B ),

How the unit test netlist got generated? Which netlist need update here?

[gadfort]

@vijayank88 the pads cannot be connected to uniquely named buses without the use of breaker cells. If you look at the "latest" that naming seems to imply that each net is it's own bus, which is probably not correct. I do recall now that I needed to update the unit test to remove the use if these nets since they yield a nonsensical design. I was not the original designer of this circuit, so the best I can suggest would be to use the pad ring from the unit test since that would avoid this wire mess all together.

[vijayank88]

@maliberty What's your suggestion? Is that possible to fix source RTL or we can remove the coyote_tc design from Makefile until we fix it?

[maliberty]

@gadfort would you summarize what is wrong with this case? I don't follow your description above. I think the point was to have a public design with a padring as an example. If it is 'nonsensical' then it doesn't make a good example.

[gadfort]

@maliberty AMUXBUSA and AMUXBUSB are busses in the padring. Unless they are broken by a splitter cell, there is only one net that makes up the bus. In the example, there is a net per pad instance, which implies the ring is split at each cell (which would not work), so therefore, I think the example is incorrect as all those nets will physically be tied together, while logically appearing as different nets. The example should be corrected to account for this, otherwise the presence of this would only add to confusion about how to build a padring in SKY130.

[vijayank88]

@gadfort Any work going on the back-end for the fix? Thanks

[gadfort]

@vijayank88 I'm not working on this, I'll let @maliberty chime in about the proper path forward.

[maliberty]

Too many things ahead of this in the priority list. I'll look when I can but if you can investigate Peter's comments that would be good.

[vijayank88]

Contributor

I used sky130_ef_io__bare_pad but the IO library is a little inconsistent, so that took me some trial and error to get the bondpads placed correctly https://github.com/siliconcompiler/zerosoc/blob/main/openroad/padring.tcl

I tried to use the same with

place_bondpad -bond sky130_ef_io__bare_pad -offset "-5 99" u_*_in
place_bondpad -bond sky130_ef_io__bare_pad -offset "-5 -5" u_*_io

But throwing below error:

[ERROR PAD-0011] sky130_ef_io__bare_pad is not of type COVER, but is instead BLOCK
Error: pad.tcl, 74 PAD-0011

[gadfort]

I changed the type to COVER.

[nchiolino]

Hello. I apologize for not being able to follow along completely to what the actual issue seems to be. Is there an issue with the netlist (AMUXBUS...etc) or is the issue in the pad.tcl file? Is there an update to the pad.tcl file that has the fix? I am simply looking for a working example that demonstrates how the ORFS can place and route a core with IO pads and finish a full chip. Is there another example that might be working? Thank you and I apologize for the lengthy post.

[maliberty]

The main working examples we have are in proprietary PDKs. The skywater pads are poorly documented and its been hard to set one up with confidence. It might be better to switch to gf180 if they provide better information.

[nchiolino]

Thank you for the quick response. I understand what you are saying with the skywater pads but it looks as though there is not a working example in gf180 that includes place and route of I/O cells and a core. All examples are just cores and pins. I am curious as to why the skywaterhd example exists if it not working. Is there a particular reason for that? Or is the issue being fixed currently with the skywater example?

[maliberty]

This was created as a work in progress to make a public example. Unfortunately it never got completed before the original author left the project. I've left it around on the hopes that someone would finish it up but it hasn't happened. At this point it might be better to just remove it.

[nchiolino]

Understood.