Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HBM support to mem_tg #3137

Open
pcolberg opened this issue Jul 19, 2024 · 0 comments
Open

Add HBM support to mem_tg #3137

pcolberg opened this issue Jul 19, 2024 · 0 comments
Assignees

Comments

@pcolberg
Copy link
Contributor

pcolberg commented Jul 19, 2024

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.

Cc: @fpgamatt, @robert-purcaru, @nanditha-intel

pcolberg added a commit that referenced this issue Jul 19, 2024
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]>
@pcolberg pcolberg self-assigned this Aug 19, 2024
pcolberg added a commit that referenced this issue Aug 19, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant