Custom TileLink Topology & visibilityNode Handling for a Custom Tile (with Internal Custom Bus/Protocol) in Chipyard

[萨斯给]

Dear Chipyard Development Team Experts,

I am a developer currently using Chipyard for an SoC design that includes a highly custom "Tile" (let's call it MyAdvancedTile). This Tile has specific internal characteristics and external connectivity requirements, and I would greatly appreciate your professional advice on the feasibility and best practices for implementing its desired TileLink topology within the Chipyard framework.

Core Features of MyAdvancedTile:

• Internal Custom Bus & Protocol: MyAdvancedTile contains a CPU core that utilizes a custom bus protocol. It also features an internal custom bus matrix.
• High-Speed On-Tile Memory Access: A custom memory block is connected directly to this internal bus matrix, allowing the CPU core to access this memory at high speed using the custom protocol.
• External Connectivity Requirement: From this internal bus matrix, MyAdvancedTile needs to expose three independent TileLink master ports. These ports are the primary interfaces for MyAdvancedTile to interact with the broader TileLink world.

My primary design goals for the system topology are as follows:

1. Independent, Dedicated Peripheral Bus (PBUS) Connections:

   • I plan to instantiate three independent Peripheral Buses (PBUS1, PBUS2, PBUS3) at the Subsystem level.
   • MyAdvancedTile's three TileLink master ports will connect directly to these three dedicated PBUSes respectively. This connection will involve a custom interface conversion logic (custom protocol <-> TileLink). While this might introduce some performance overhead, it's intended for communication with slower TileLink peripherals in the system.

2. MyAdvancedTile Core's External Path for Peripherals:

   • All external accesses from MyAdvancedTile's internal CPU core to external TileLink low-speed peripherals will occur exclusively through these three master ports (after protocol conversion) and their connected dedicated PBUSes. The core will no longer require the traditional SBUS path (i.e., via an inherited visibilityNode if extending BaseTile) for these specific external low-speed peripheral interactions.

3. Handling MyAdvancedTile's visibilityNode:

   • Since the core will not use the visibilityNode (if MyAdvancedTile extends BaseTile) for its primary data interactions with SBUS, my current plan is to connect this inherited visibilityNode to a minimal "dummy" slave node, mainly to satisfy Diplomacy's connection integrity requirements.
   • However, I would like to explore this further: For a Tile like MyAdvancedTile, where its core completely bypasses the traditional SBUS path via visibilityNode for all its communications, is there a more concise or officially recommended way to handle this inherited node? For instance, without extensively rewriting BaseTile functionalities, is it possible to have it "diplomatically inactive" or entirely remove its impact? Or, in such a scenario, would it be more advisable for the custom Tile to inherit directly from a more fundamental LazyModule instead of BaseTile, thereby avoiding this unused node altogether?

4. Standard Tile Connections:

   • If other standard Tiles (e.g., Rocket cores) exist in the system, they should still connect their visibilityNode to the SBUS in the conventional manner.

5. Bus Independence (Key Point):

   • I intend for these three PBUSes dedicated to MyAdvancedTile to have no preset, direct diplomatic master-slave connections with SBUS, CBUS (Control Bus), or each other at the system level. This means SBUS will not actively access devices on these three PBUSes; communication on these PBUSes will be solely initiated by MyAdvancedTile's corresponding master ports. Similarly, CBUS will have no direct connections to these PBUSes (unless initiated by a Tile).

My Current Envisioned Implementation Approach:

• Define three new TLClientNodes in my MyAdvancedTile class (which currently extends BaseTile) to serve as its master ports, also handling the internal custom protocol to TileLink conversion. These new TLClientNodes effectively provide MyAdvancedTile with multiple parallel "visibility outlets" to different dedicated PBUSes. If the Chipyard framework has specific design patterns, recommended node types, or naming conventions for a Tile exposing multiple independent master ports (rather than a single visibilityNode), I would appreciate your guidance.
• Explicitly instantiate the required SBUS, the three PBUSes, CBUS (if needed by other parts of the system), and a "dummy slave bus" (containing a simple TLRAM) within the Subsystem.
• Utilize a custom topology parameter class (e.g., my project's NewPrjBusTopologyParams, inheriting TLBusWrapperTopology) to declare the instantiation of these project-specific buses (PBus1-3, CBus). Its connections list will be Nil, reflecting the lack of direct inter-connections between these buses and SBUS relevant to MyAdvancedTile's access.
• Define a dedicated topology connection class (e.g., MyAdvancedTileSpecificTopology) to be applied last in the Config's TLNetworkTopologyLocated(InSubsystem) sequence. This class will be responsible for all Tile-to-bus connections:
  • Connecting MyAdvancedTile's three master ports to the three PBUSes respectively.
  • Connecting MyAdvancedTile's inherited visibilityNode to the dummy slave bus.
  • Connecting other standard Tiles' visibilityNode to SBUS.
  • Handling Tile-to-CBUS connections (if required).

My Main Questions Are:

1. Does the Chipyard framework natively support, or can it readily facilitate, the kind of topology I've described? Specifically, a Tile with an internal custom bus/protocol for on-tile high-speed communication, which then uses protocol conversion to connect multiple independent master ports to different dedicated TileLink PBUSes for interaction with slower peripherals, where these dedicated PBUSes are relatively isolated from other main system buses like SBUS.
2. For such a design, particularly concerning the custom protocol to TileLink conversion and the management of multiple master ports from a single Tile, are there official best practices, specific Chipyard features/APIs to be aware of, or relevant examples that I could reference?
3. Regarding the handling of MyAdvancedTile's visibilityNode (e.g., connecting to a dummy node or other preferred solutions) while ensuring standard Tiles still connect correctly to SBUS, are there any potential pitfalls or special configuration techniques I should consider?
4. Concerning bus clocking: If these PBUSes and CBUS do not derive their clocks from SBUS (e.g., DriveClocksFromSBusKey is set to false in the Config), is my understanding correct that the Subsystem must then explicitly connect them to independent clock sources? In this scenario, what becomes the primary role of the ClockCrossingType settings within SubsystemCrossingParams (e.g., sbusToP1BusXType) – would they primarily define logical crossing relationships for potential future diplomatic connections between these independent clock domains, rather than for direct clock derivation from SBUS?

Thank you very much for taking the time to read my detailed inquiry. Your expert guidance on these matters would be invaluable to my ongoing design efforts.

Sincerely,

A Chipyard Developer

Sasigei