Connecting I/O PADs to internal routing

[TheGitUser7]

Dear All,

I am working on a simple RTL design and have successfully gone through Placement, PDN generation, CTS and routing. However I notice that the signal pads are not connected to the internal routing structure of the die, even as the tool says the connections are routed.
I am using sky130hd library.

Any suggestions would be highly appreciated.

Regards

[maliberty]

Can you give a test case or at least some screen shots?

[maliberty]

I would expect grt & drt to route it. If you click the route guide button in the inspector do you see guides for this net (grt would create them).

[TheGitUser7]

I believe by guide you mean the visible yellow line that is like highlighting? If so yes, you can see it in the first picture I uploaded above.

More generally speaking, I couldn't find a script of a design in which pads are connected to internal logic in OR database. I checked the test scripts (e.g. src/pad/test) and I couldn't find an example of this. There is rdl_route scripts that route from PADs to Bumps but not PADs/Bumps to internal logic. Also in the full example designs (eg ibex_sky130hd), there are no pads or bumps, the internal logic is routed directly to outside of the die. I would appreciate it if you could let me know in case there is such example and I have mised it somehow.

[maliberty]

No I mean the route guides displayed by clicking the route guides button in the inspector

[maliberty]

The pad module is for constructing the pad ring. Signal nets are handled by grt/drt.

[maliberty]

For example

[TheGitUser7]

Hi @maliberty,

I appreciate your continuous engagement with this thread.

I don't see the Route Guides botton when selecting this net - or other nets that are supposed to route to the PADs. I see it for other nets that have been physically routed.

[maliberty]

It is a top level terminal, the sort of thing found in a terminal list of the top module in verilog

[TheGitUser7]

But this does come from a terminal. This is the net that supposed to be routed from the PAD (terminal) to the internal logic.

[TheGitUser7]

If I upload the mini-project would you have time to check it out ?

[TheGitUser7]

I use this PAD library https://skywater-pdk.readthedocs.io/en/main/contents/libraries/sky130_fd_io/docs/user_guide.html but I don't connect all the pins, only the PAD itself and IN/OUT pins depending on the direction. Could this cause issues ? Although many other pins are VDD/GND related pins. I would think the drt and grt should be able to deal with this without a complete PAD connection.

[maliberty]

Usually the pad has a pin that drives the core, the core is not directly connected to the top level pins.

[TheGitUser7]

Tuns out I had used the place_io_terminals without specifying the names of the PADs of the PADCELLs. The tool lets you get away with it. An error or a warning would be helpful.

[maliberty]

@gadfort do you know where we should put this check?

[gadfort]

If this what you mean: #7853 ?

[TheGitUser7]

Since I use the place_io_terminals command appropriately, the pin_access (whether as part of detailed route or separately) stage takes a long time (1+ hours). Any idea why this is the case ?

[maliberty]

How many threads? How many pins/nets? How long was it beforehand?