Tile PRCI Domain Wrappers

[hcook]

Tiles are now instantiated inside of a wrapper whose purpose is to contain logic related to their Power, Clock, Reset and/or Interrupt domain. In particular:

• The layer has a diplomatically-derived clock and reset, which are used to drive the tile clock and reset.
• The portion of TileLink clock crossings that are supposed to be in the tile clock domain are instantiated in this layer.
• Interrupt synchronizers are instantiated in this layer.
• Boundary buffers and isolation cells related to hierarchical P&R are to be instantiated in this layer.
• In the future core-local interrupt handlers could be instantiated in this layer.

Related issue:

Type of change: other enhancement

Impact: API modification

Development Phase: implementation

Release Notes

• All tiles are now instantiated inside of a wrapper that contains logic related to their power, reset, clock and interrupt domain. This change adds a level to the module hierarchy path to the tile.

[rmac-sifive]

I think the answer is "yes" based on my read but want to confirm: this supports injecting unique sequences of clock nodes per tile, right?

[rmac-sifive]

Also, hierarchically where do the injected clock nodes reside?

[hcook]

Yes, and they reside in the new wrapper that is hierarchically now the parent of each tile.

[rmac-sifive]

it seems desirable that someday we might want to support more than 1 tile per PRCI domain wrapper

[hcook]

I certainly wouldn't rule that out, but if those tiles share some resources like e.g. a shared cache probably all three of them live inside a ClusteredTilesWrapper, which might either have its own clock sink node or just be wrapped in one of these clock domain wrappers itself. Alternatively we can always (configurably?) make wrappers around these wrappers... put another way, maybe this wrapper is just a DevicesSubsystem with a single tile "device" inside it, if you upstreamed that and we re-expressed it that way :)

[ernie-sifive]

Tests are successful.