Model an Interconnect for Olympia

[arupc]

Develop an API for Interconnect model and implement an example Interconnect microarchitecture.

Please see https://github.com/riscv-software-src/riscv-perf-model/issues/60#issuecomment-2187718768 for more details

[shivampotdar]

Hi Arup

Is there an existing plan for this issue or someone is planning to pick it up? I would be able to spend few weeks with a group and would like to know the requirements.

[ghost]

There are no plans nor volunteers at this time to take on this task -- you're the first to ask!

To start the discussion, here's my thinking (feel free to augment/add):

1. Add support for TileLink
2. Add support for AMBA AXI and ACE
3. Integrate Olympia with existing simulation infrastructures/models (SysC models, Gem5, etc)

The important development task is building the appropriate gaskets to allow Olympia's BIU (also needing development to support multiple outstanding requests + instruction requests) to "bolt" to ... whatever is on the other side. For example:

 MSS Request -> BIU -> ACEGasket      -> ACE Interconnect model
 MSS Request -> BIU -> TileLinkGasket -> TileLink Interconnect model

In this example, the BIU has no idea what it's connected to -- and it never should.

[sequencer]

Hi, @knute-sifive FYI, The TileLink is updated to 1.9.3

I'm really curious about the methodology of designing SoC/interconnection performance model.

We actually give a shot for Sparta this Q1, See here, However what I found is the Sparta scheduler is not suitable for interconnection/SoC modeling, since the handshake logic from Sparta doesn't support Decoupled(which is a common use in interconnection designs). Thus I don't think Sparta is a good idea here.

My current idea is providing a SystemC based BFM for TileLink/CHI, and use Diplomacy + Verilator to construct the SoC to work around from the Sparta scheduler.

I'm not sure about if this is a correct way:( but I'm still open minded to Sparta, if there are some better examples.

[ghost]

We actually give a shot for Sparta this Q1

Fantastic! Be interesting to see what unfolds...

since the handshake logic from Sparta doesn't support Decoupled(which is a common use in interconnection designs)

Not sure what you mean by "decoupled." Are you referring to disparate clock domains? Sparta's scheduler coupled with SyncInPort and SyncOutPort should work. Can you elaborate on the issue you have here?

I can confirm (without giving too much detail 😉 ) that Sparta has been used to model extremely complex interconnects with success.

If you continue with the SystemC route, that's definitely feasible with Sparta (see SystemC Modeling and Sparta). In this mode, Sparta scheduler is slave to SystemC. Note that this modeling direction is significantly slower.

[sequencer]

Hi, Knute,

We actually give a shot for Sparta this Q1

Fantastic! Be interesting to see what unfolds...

We take these assumption:

• Hierarchy between model and RTL should be aligned;
• Sparta only care about the performance events;
• In Chisel, we use Probe API to probe performance events out and align with the Sparta performance model.

Here are issues we encountered:

• we use Chisel and diplomacy to construct the hierarchy and negotiate the parameter for each module;
• The hierarchy can only be extracted after RTL elaboration, including the connection. While, Sparta uses yaml for hierarchy construction, I thought about using code gen or even the reflection, but I'm not sure if this is correct;
• Chisel elaborated Port has parameters(width, field, etc...), passing those parameter to sparta is yet another problem, we are thinking using Object Model, but still uncertain about it.

So basically the issue is: while Chisel+diplomacy provides a full flexibility, I didn't find a good way in Sparta to align Sparta model and Chisel. I know in SiFive you guys made it possible, but I'm curious:

• is ehe interconnect hierarchy/parameter constructed by Sparta or by diplomacy? How to align them?
• Is Sparta providing the Bus Functional Model which can be linked to verilator? Or Sprata only provide a TLM-level modeling, while RTL gives trace to Sparta to make Sparat providing the performance result, so can detect the performance bug in SoC.

since the handshake logic from Sparta doesn't support Decoupled(which is a common use in interconnection designs)

Not sure what you mean by "decoupled." Are you referring to disparate clock domains? Sparta's scheduler coupled with SyncInPort and SyncOutPort should work. Can you elaborate on the issue you have here?

I mean the ready-valid interface in RTL design, which is call Decoupled in Chisel, however in this situation, model should peek the ready and valid signal from each other to decide the event in THIS cycle, I think in this case, the Sparta scheduler doesn't support it well(fall back to step by step triggering the clock). Thus I don't have a good idea to align interface between Sparta and Chisel. Maybe I may need to seek some help from the community.

I can confirm (without giving too much detail 😉 ) that Sparta has been used to model extremely complex interconnects with success.

LOL, I know, that's the reason why our group are trying to use Sparta, rather than GEM5 ;p

If you continue with the SystemC route, that's definitely feasible with Sparta (see SystemC Modeling and Sparta). In this mode, Sparta scheduler is slave to SystemC. Note that this modeling direction is significantly slower.

Yes, so I have been wondering what's the best practice here.

[arupc]

Assigning to @jeffnye-gh to complete the description of the issue, per discussion in weekly.

[jeffnye-gh]

A NOC related project proposal for Olympia.

Olympia is a scalable trace driven performance model which focuses on enabling investigation. For new areas typically an API is developed and a use case is written as proof of principle.

Providing Olympia an API for the investigation of NoC topology and behavior would be an important addition to Olympia's capabilities. As part of this project a NoC centric API would be developed and we propose exercising the API with a TileLink or Garnet 2.0 network model.