This used to make sense when we used MemTraceCores which never blocks
the response channel, but now that we're integrating with Vortex cores,
we cannot make the same assumption on the core's actual pipeline
behavior (although it is unclear why a core would ever block receiving
responses.)
With sourceWidth = 1, we hit an unsynchronized vx_wspawn bug, where the
previously spawned warps get killed and overridden by a new vx_wspawn
call before all the warps complete execution. Setting sourceWidth = 1
somehow slows down the progress of the spawned warps in relation to warp
0 (presumably because fetch stalls, but not sure why they would slow
down more than warp 0) and results in this bug. sourceWidth = 4 seems
to work for vecadd.
Previously VortexBundle was being instantiated using the parameters of
the TileLink bundle from VortexTile. This results in tight coupling
between Vortex interface parameters and downstream TileLink parameters.
This change adds a standalone Bundle used by the VortexCore wrapper
and is independently instantiated from the TL params, i.e. different
source widths. Ideally we want to move away from using TL-like
structures for VortexBundle and handling adapter logic completely
outside the core blackbox.
This fixes sourceId collision that occurs when naively re-using tag bit
of a Vortex dmem request as TL source, which happens because Vortex core
does not allocate a new LSU entry for writes.
`VortexSourceGen` module acts as a Vortax tag <-> new TL source ID
converter, where it allocates a new ID for every new Vortex request, and
restores its original tag bits from the metadata embedded in the
SourceGenerator module.
TODO:
- Decouple sourceWidth of downstream TL nodes from Vortex's tag bit
width; they are set to be the same for convenience as of now
- Apply this to imem requests as well
Hansung Kim