Question: What is the correct allignment in SKY130? Intermediate Pins are not connected to the grid. Likely user mistake.
c-93 opened this issue · 10 comments
Describe the bug
Some pins are not connected to the routing grid. In more detail, sometimes zero, one, or two intermediate pins are not connected.
Could be user error.
Version
OpenRAM 1.2.48
OpenLane 2
To Reproduce
- Modify LEF to 1000 microns database unit as described here.
- Instantiate a macro in openlane2, connect it, run synthesis, and fail at the verification step.
- Macro is not connected to the power grid, yet.
I reproduced this bug using two different macros and locations. Different pins were disconnected. So, I guess no explicit conf file needs to be reproduced.
Expected behavior
Successfully connecting all pins to the memory macro.
Logs
Notice the pattern. Sometime zero skips, then one or two skips.
[DRT-0418] Term my_openram_macro/din0[0] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[3] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[6] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[8] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[9] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[11] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[12] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[14] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[15] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[17] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[18] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[20] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[21] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[23] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[26] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[29] has no pins on routing grid
[DRT-0418] Term my_openram_macro/din0[31] has no pins on routing grid
Additional context
However, in the OpenRoad GUI in step 44-odb-reportdisconnectedpins ALL pins are visually connected:
Notice that there is a difference in HalfGrid access points for connected and non-connected pins.
Non-functional:
Functional:
Questions:
- Does the macro need to be manually aligned to a specification?
- Or is this due to the 2:1 LEF unit scaling?
At the top level, we make large pins so that they will fall on the routing grid. It is likely that the grid size changed (or something else), so we might need to increase our pin size and/or spacing. This would be done in the code relative to DRC dimensions.
Did you manually fix the lef size? (It was only an error in this unit and not the other dimensions.) Does the lef/layout look correct in the final design?
Please feel free to submit PRs if you fix any of these.
Matt
Your image suggests the LEF and connections are fine. I'm not sure what the issue is in the router.
Thanks for your quick response.
Yes, I noticed the connections are not always 100% centered within the pin area. But they look connected.
For example pin 0 does not look "perfect" (still visually looks connected). However, it raises the error.
Pins 1 & 2 look fine and are connected. Pin 3 looks fine, but is not connected.
I manually changed only the database microns in the LEF. I did not modify other values. The LEF and instantiation looks good to me.
I can send the exact positions if this helps.
Yes, making the pins a bit bigger might ensure that all pins align in the center and the router doesn't give this error. Though, it seems like it should be a warning.
Thanks again for your feedback.
I am still not sure what is really happening.
Another pin seems to be more offset, but does not raise an error.
I agree: Increasing pin size in GDS2 and LEF will be the resonable next step.
Just a sidenote: DFFRAM provides pins on another layer and connects without error.
I would also confirm with the router people why the error is there. These seem like perfectly good connections.
It would be helpful to turn on the routing grid in your images.
Instantiate a macro in openlane2, connect it, run synthesis, and fail at the verification step.
Is too vague. Please make a standalone routing test case that shows the problem.
Thanks for the suggestion! I will prepare a standalone test, but need some days.
I activated the grid view in openroad, but I need to double-check if the grid settings correspond to the router grid settings from openlane2.
As suspected in the initial issue, I discovered this was a user error. Thanks for the responses so far.
My solution/approach:
-
The red macro connections to the macro are on the
metal 4 layer. I have seen this in the openroad gui. -
The non-modified default settings from the
openlane2'sopenroad-globalrouting.logare:
[INFO GRT-0088] Layer li1 Track-Pitch = 0.4600 line-2-Via Pitch: 0.3400
[INFO GRT-0088] Layer met1 Track-Pitch = 0.3400 line-2-Via Pitch: 0.3400
[INFO GRT-0088] Layer met2 Track-Pitch = 0.4600 line-2-Via Pitch: 0.3500
[INFO GRT-0088] Layer met3 Track-Pitch = 0.6800 line-2-Via Pitch: 0.6150
[INFO GRT-0088] Layer met4 Track-Pitch = 0.9200 line-2-Via Pitch: 1.0400
[INFO GRT-0088] Layer met5 Track-Pitch = 3.4000 line-2-Via Pitch: 3.1100
-
The
Track-pitchis defined as the minimum distance from track-center to track-center. -
By moving the macro: The center of the leftmost pin is now at X-Position 138,46, which makes
138,46 / 0,92=150,5, matching the grid. The error is solved.
If my explanation is correct:
Maybe we should add this alignment explanation to the openlane2 and/or the OpenRAM documentation?
Moving the macro to the correct pin coordinate works only if the pins on the upper and lower sides both match to the routing grid. However, this does not always seem to be the case. Thus, the lower side io pins connect, but some upper side pins raise an error - as they mismatch the grid.
Yes, making the pins a bit bigger might ensure that all pins align in the center and the router doesn't give this error.
I am not sure which place is correct for implementing this modification.
As the add_io_pin function instantiates a power_pin, this looks like the correct place.
However, modifying it for example from
min_area = drc["minarea_{}".format(self.pwr_grid_layers[1])]
to
min_area = drc["minarea_{}".format(self.pwr_grid_layers[1])] *2
only scales all internally existing IO pins (marked in red), but does not scale the desired pins that actually connect the macro to the surrounding world (marked in blue).
How can I scale the "outer-world-pins"?