Since we do source generation independently for each lane, if we use TL
source for filtering, it becomes possible that lane 0's source happens
to match lane 1/2/3's source even when they don't belong to the same
warp. Since Vortex uses dcache req ID that is unique across
instructions, using that for filtering prevents this bug. A better
solution would be to do source generation for all lanes at a time
though.
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
