Understanding Gemmini’s Uncached TileLink Path and L1/L2 Coherence Implications

58 views
Skip to first unread message

Fizza Haq

unread,
Nov 18, 2025, 12:06:46 AMNov 18
to Chipyard

Hi everyone,

I’m trying to better understand how TileLink behaves in Chipyard specifically when connecting Gemmini as an uncached client.

From my understanding, Gemmini is typically connected as an uncached TileLink client (via TLUL), meaning it does not participate in the cache-coherency protocol used by the CPU tiles. However, I’m still confused about the exact data path and coherence implications:

  1. When Gemmini is configured as an uncached TileLink client, does its traffic simply pass through the L2 and then go directly to main memory (i.e., truly uncached)?

    • Does the L2 still temporarily store or track this data in any way?

    • Or does the L2 effectively act as a pass-through router for uncached traffic with no allocation?

  2. When a normal CPU tile (cached TL client) accesses the same address range that Gemmini writes to, how is coherence maintained?

    • Does the L2 act as the coherence manager and send probes to L1?

    • Or, for Gemmini’s uncached writes, is there no coherence guarantee, meaning software must avoid overlapping regions or insert flush/fence instructions or there is a specific address range for a gemmini to which it writes ?

  3. In general, I’m trying to clarify:
    If Gemmini bypasses L1 (uncached), how exactly does L2 treat those accesses? And for cached CPU traffic, what maintains consistency between L1 and L2 when Gemmini writes to DRAM?

Any clarification on how Gemmini, TileLink, and the L1/L2 coherence model interact plus pointers to relevant RocketChip/Chipyard documentation or code would be greatly appreciated.

Reply all
Reply to author
Forward
0 new messages