You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add High Bandwidth Memory (HBM) support to the memory traffic generator (mem_tg) sample used to exercise and test available memory channels, which currently supports DDR memory only.
For DDR, each memory channel accesses an independent memory bank, each starting from offset 0. For HBM, each memory channel has access to the entire memory space and must therefore access memory from different locations when reading or writing on multiple channels simultaneously to avoid collisions.
When running multiple traffic generators in parallel, e.g., using the option -m all to select all available memory channels, each generator should operate on a non-overlapping memory address range. For the purpose of this sample, it should be sufficient to add a new option to specify a single, relative address offset that is multiplied by the channel number to obtain an absolute address offset.
The 64-bit address offset for each traffic generator is written to a pair of 32-bit registers, TG_SEQ_START_ADDR_RD_{L,H} for reads and TG_SEQ_START_ADDR_WR_{L,H} for writes. For the purpose of this sample, the same value may be used for both reads and writes.
As a reasonable default, the address offsets could be determined by partitioning the available HBM memory. This would require detecting the presence of HBM memory (as opposed to DDR) and the total size of the memory. At least the latter is already exposed in hardware through EMIF_MEM_CAPABILITY, which is part of the EMIF feature register set in its DFH entry. However, the existing dfl-emif kernel driver does not expose this register as a sysfs entry. As an alternative, the required information could be exposed to userspace through additional registers in the AFU that are directly read in the mem_tg sample.
The sizeof() operator returns the size of an object or type in bytes,
not bits. Instead of calculating the number of bits using, e.g.,
CHAR_BIT * sizeof(), hard-code 64 since it is close to the declaration.
This is a prerequisite for HBM support with up to 32 channels.
Link: #3137
Fixes: 7bf96dc ("mem_tg test multichannel")
Signed-off-by: Peter Colberg <[email protected]>
The sizeof() operator returns the size of an object or type in bytes,
not bits. Instead of calculating the number of bits using, e.g.,
CHAR_BIT * sizeof(), hard-code 64 since it is close to the declaration.
This is a prerequisite for HBM support with up to 32 channels.
Link: #3137
Fixes: 7bf96dc ("mem_tg test multichannel")
Signed-off-by: Peter Colberg <[email protected]>
Add High Bandwidth Memory (HBM) support to the memory traffic generator (
mem_tg
) sample used to exercise and test available memory channels, which currently supports DDR memory only.For DDR, each memory channel accesses an independent memory bank, each starting from offset 0. For HBM, each memory channel has access to the entire memory space and must therefore access memory from different locations when reading or writing on multiple channels simultaneously to avoid collisions.
When running multiple traffic generators in parallel, e.g., using the option
-m all
to select all available memory channels, each generator should operate on a non-overlapping memory address range. For the purpose of this sample, it should be sufficient to add a new option to specify a single, relative address offset that is multiplied by the channel number to obtain an absolute address offset.The 64-bit address offset for each traffic generator is written to a pair of 32-bit registers,
TG_SEQ_START_ADDR_RD_{L,H}
for reads andTG_SEQ_START_ADDR_WR_{L,H}
for writes. For the purpose of this sample, the same value may be used for both reads and writes.As a reasonable default, the address offsets could be determined by partitioning the available HBM memory. This would require detecting the presence of HBM memory (as opposed to DDR) and the total size of the memory. At least the latter is already exposed in hardware through
EMIF_MEM_CAPABILITY
, which is part of the EMIF feature register set in its DFH entry. However, the existing dfl-emif kernel driver does not expose this register as a sysfs entry. As an alternative, the required information could be exposed to userspace through additional registers in the AFU that are directly read in themem_tg
sample.Cc: @fpgamatt, @robert-purcaru, @nanditha-intel
The text was updated successfully, but these errors were encountered: