The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.59k stars 551 forks source link

(feature request) make router connect stdcells to power rings #2209

Closed luccareinehr closed 2 weeks ago

luccareinehr commented 2 years ago

In a mixed-signal design from OpenFASoC with two voltage domains (VDD and VIN), I have some cells placed in a VDD grid that must also connect to the other domain's net (VIN). However, when running global_route and detailed_route, there's no route from these cells to the VIN voltage domain ring (generated via pdngen).

The two voltage domains: image

The cells that must connect to VIN (they're already in the VDD grid): image

The resulting route after global_route and detailed_route are run (there is no route from the cells to the VIN ring): image

How to create this connection?

To reproduce the case:

maliberty commented 2 years ago

Power nets are not routed by the signal routers (grt/drt). pdn doesn't create tracks. The description of this problem is very confusing.

maliberty commented 2 years ago

This looks like the enhancement request for sroute that I keep asking for a spec for. Nothing will happen until this project has been properly defined. @msaligane

msaligane commented 2 years ago

I have no bandwidth and I am not great at writing specs.

@luccareinehr can you work on that with @maliberty .

luccareinehr commented 2 years ago

@maliberty Sorry for the confusing description. What I meant was: there's a cell that should connect to a voltage domain it is not in (VIN), but the routing doesn't get generated.

There's a workaround for this where a second VIN net is created exactly in the same place as the original, but with a SIGNAL type (instead of POWER), and this new net gets connected to the cells in the other voltage domain instead. Then routing does get generated automatically, but I doubt this is the intended solution:

image

luccareinehr commented 2 years ago

@msaligane mentioned requesting the addition of a point-to-point router to OpenROAD, is this the enhancement request Matt mentions in his comment?

maliberty commented 2 years ago

Yes, I've had vague mention of wanting a p2p router but I want a specific set of requirements in a spec. It is not a small request.

luccareinehr commented 2 years ago

@maliberty Indeed, I'll reserve time to talk to mehdi and give you a proper spec.

As for this issue, yes it could be solved with a p2p router, but I don't think that's the best solution. Afaik, OpenROAD is intended to be a no-human-in-the-loop flow, but in its current state, if there are multiple voltage domains in a design and a cell which has connections to more than one of them (and is not a level converter), it won't get routed automatically.

Please correct me if I misunderstood something, or if my request is not very clear. And thanks for the support

rovinski commented 2 years ago

Afaik, OpenROAD is intended to be a no-human-in-the-loop flow

From my understanding, OpenROAD is intended to be no-human-in-the-loop for digital designs. It's a lofty goal that still has a lot of work to be done.

if there are multiple voltage domains in a design and a cell which has connections to more than one of them (and is not a level converter), it won't get routed automatically.

For clarity, what you are describing is a special net router and is not typically used in digital flows. The use case for this would be for non-digital signals, as in your case. So as @maliberty said, it's not currently supported and would have to be implemented.

luccareinehr commented 2 years ago

@rovinski Thank you for the clarification!

@maliberty should I close this issue?

QuantamHD commented 2 years ago

You can rename this issue to ask for the for feature.

maliberty commented 2 years ago

The cell is connecting to a power ring not another cell. That is not the normal multi-power domain P&R use model. Even in proprietary tools this is a completely separate router because it is a totally different requirement from signal net routing.

QuantamHD commented 2 years ago

@luccareinehr Could you potentially locate these cells in a third voltage domain and then connect it to the Vin from temperature sensor block?

Beyond the routing issue I'm a little bit confused about how the pdn in the logic area is isolated from the Vin of the tempature block if you connect them together. Is there something I'm missing?

rovinski commented 2 years ago

Some comments on this feature:

I've actually done this before in a taped-out chip when connecting an on-chip voltage regulator to the power rails of the regulated domain. So basically the same use case, but our regulator was a block, not a standard cell.

It becomes a very tricky problem because the main concern is not about DRVs or timing, but the IR drop across/peak current through the routing. We had to estimate the peak current draw by the power domain and size the routing large enough (using multiple connections) to ensure that electromigration and IR drop were minimized.

Such a tool in OpenROAD would be a large undertaking. A simple repurposing of the detailed router to perform NDR connections is possible, but risky from a design perspective because it wouldn't be able to optimize for power integrity.

QuantamHD commented 2 years ago

@rovinski Could we make a small change to the router to have it replicate connections for power purposes as a quick hack? So in @luccareinehr's case we would create N duplicate nets to route to the power ring/grid. That's obviously not optimal, but would at least give designers a lever to be more or less conservative.

We could eventually run IR drop analysis and increase N until we were happy in future improvement.

gadfort commented 2 years ago

In this case, what is VIN supposed to be used for? Is this for a ring oscillator to modulate it's speed? How is VIN generated? I'm just wondering.

rovinski commented 2 years ago

@QuantamHD The best first strategy would be to use a single connection with non default width (non-default routing / NDR). This strategy is still limited by the pin size on the block / cell which is generating the signal (i.e. if the pin is small, there is a practical limitation on how wide the metal route can be).

Creating multiple connections is only necessary if the net resistance requirements can't be met with a single connection (e.g. the desired metal width is greater than the max allowable width, or the width is capped by the size of the source pin). In this case, the power source would need to have multiple pins or a pin which is larger than max width. This only occurs for larger power sinks and is likely not applicable to @luccareinehr's design (my design was a multicore processor).

My concern isn't that there's no quick hack to fix @luccareinehr's problem; the concern is that the tools would not have a way of recognizing and warning the user of potentially chip-breaking mistakes.

It would be possible to use the detailed router to provide a partial solution this problem (such as @luccareinehr's case) but a general solution to the problem (making N connections; verifying power integrity) would likely require significantly different algorithms. For what it's worth, I don't think even commercial tools handle this case automatically. It usually takes significant hand-holding to get the special router to generate clean, quality routing.

luccareinehr commented 2 years ago

@QuantamHD Despite how the pdn looks in the images, only the VSS of both voltage domains are shorted!

@arlpetergadfort Yes that's it, VIN modulates a ring oscillator. It is generated from a voltage drop in VDD after a couple of transistors in subthreshold regime, upon temperature variation (the design in question is a temperature sensor)

gadfort commented 2 weeks ago

Sroute was added