Power and Ground Routing Constraint

[soneryaldiz]

Allow user to specify whether power and ground nets should be:

1. routed using dedicated grids,
2. routed without a grid like signals,
3. not routed

Tasks:

• [ ] Enhance the schema for PowerPorts and GroundPorts,
• [ ] Enhance the routing algorithm to respect the new constraints,
• [ ] If a power or ground port is not to be routed, exclude from open check

Option#1:

class RoutePower():
  nets: List[str]
  style: Literal['grid', 'signal', None]

class RouteGround():
  nets: List[str]
  style: Literal['grid', 'signal', None]

Option#2: Combine to a single constraint that can later be extended to specify grid pattern:

class PowerGroundRouting():
  power_nets: List[str]
  ground_nets: List[str]
  style: Literal['grid', 'signal', None]
  h_grid: Grid
  v_grid: Grid

class Grid():
  layer: str
  period: int
  pattern: List[str]     # Repeating pattern. Example: [vss, vcc1, vss, vcc2]

[soneryaldiz]

@Lastdayends , @stevenmburns , let's start baking this enhancement as well. Option#1 is acceptable and easier to start with.

[Lastdayends]

@soneryaldiz

option 1 is good. The description for #option 1 is for user perspective.

We need to discuss what is the inputs to the PnR.

[soneryaldiz]

@Lastdayends

Inputs for the PnR can be as simple as the JSON serialization of the classes. Example:

[
  {'constraint': 'RoutePower', 'nets': ['vccx'], 'style': null},
  {'constraint': 'RouteGround', 'nets': ['vssx'], 'style': 'signal'}
]

Is this sufficient?

[Lastdayends]

@soneryaldiz

This is sufficient to define all pins of a certain net as power/signal pins.

But do we have the requirement, which define part pins of a certain net as power/signal pins?

[soneryaldiz]

@Lastdayends

Not quite sure if I understand your point. Let me try to simplify the enhancement: I think this constraint can be primarily handled by the compiler:

• style == grid => The current behavior when power and ground ports are labeled, no changes.
• style == signal => Compiler can still utilize power/ground net names for constraint generation and these nets are routed as signals (the current behavior w/o power ground constraints).
• style == none => New behavior. Compiler can still utilize power ground net names for constraint generation but these nets are not routed / left open.

Therefore, this constraint is primarily consumed by the compiler. For PnR, we can make introduce an additional constraint:

class DoNotRoute():
  nets: List[str]

where router should ignore the nets in the above list.

Adding @kkunal1408 for input.

[Lastdayends]

@soneryaldiz

So you just want to define whether the original power net (original power net is defined in the verilog file) should be tried as:

1. a power net, and do power routing for all its pins
2. a signal net, and do signal routing for all its pins
3. a power net, but do not route

A power net might include several pins. Our detailed router do the routing for each pins.

[soneryaldiz]

That is correct. 1 & 2 above are already done in the current implementation. 3 is the new feature and can be generalized beyond power nets using DoNotRoute constraint which should be sufficient for the routing algorithm.

[Lastdayends]

@soneryaldiz

I see.

Is there a testcase, so I can implement and do a test?

[soneryaldiz]

I will provide a test case in a few days to get started.

[Lastdayends]

@soneryaldiz

Got that. Thanks!