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

Extended support of Alveo boards by BSC #150

Open
wants to merge 1,920 commits into
base: openpiton-dev
Choose a base branch
from

Conversation

alekrop
Copy link

@alekrop alekrop commented Jul 12, 2024

Here is a suggested support of 3 types of AMD Alveo boards: U55C, U280, U250. It is based on embedded meep_shell which includes QDMA based PCIe inteface, 2 kinds of supported DRAM: DDR and HBM, support of multi-MC (Memory Controllers) connection to HBM utilizing free NOC ports of edge tiles. Apart of this the contribution includes modified NOC-AXI4 bridge, 100GbE solution based on Ultrascale+ CMAC hard-macro+QSFP and AXI-DMA+SRAM, BSCAN based small JTAG shell. Support of Alveo boards is provided as independent of Vivado versions. The last checked Vivado version is 2024.1. The bitstream built in different configurations and utilizing all above is Linux bootable.

bscabancens and others added 30 commits May 26, 2023 12:54
Extension of 100GbE test app for support of Aurora DMA IP.

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!109
Updated VPU, XBAR, LVRF, ME and SAs

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!107
…nch 'rtl/HV_GC5-L1Ar-V_ACME' into 'production'", This reverts commit c43f1da, reversing changes made to 5c1a7f4.
Update of 100GbE test app to support ping exchange for Aurora.

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!115
Making default 100GbE port QSFP0.

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!117
Update of Eth/Aurora test application.

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!121
MEEP Shell: adding JTAG interface being disabled to accelerator_def.csv.

See merge request meep/FPGA_implementations/AlveoU280/meep_openpiton!122
@alekrop alekrop marked this pull request as ready for review July 12, 2024 15:06
@alekrop alekrop changed the title Support of Alveo boards by BSC Extended support of Alveo boards by BSC Jul 12, 2024
@alekrop
Copy link
Author

alekrop commented Jul 21, 2024

++ @Jbalkind

@Jbalkind Jbalkind mentioned this pull request Jul 21, 2024
@Jbalkind
Copy link
Collaborator

Thanks Alex! This is great :)

There's a lot in here (my browser freezes reading the "files changed" tab) and I'm wondering how we can scale this down to make merging it more manageable. There are also a few things I can see from a quick initial scan that I think we should check over or pare down for the initial merge. Initial comments:

  • The msg_ini_x/y stuff misunderstands how the coherence system works and should be removed. The core that initiated the request should be irrelevant to the order of request processing at a peripheral
  • Most of the ethernet changes are generic but the ones in riscvlib.py are not conditioned - maybe we should give the CMAC a different name so we can more easily parameterise in riscvlib.py? Or maybe for an initial merge we could just remove CMAC?
  • Can we remove multi-MC for the initial merge to simplify things?
  • The readme text is good but should be updated for the merge
  • The patch file for ariane is the whole file rather than a diff - What has been changed in frontend.sv? Do you know what patch would be needed for the version of ariane that openpiton currently points at?

Could we also rewrite the history down to a smaller number of commits? That or I could do a squashed merge when I actually merge the PR into the repo.

@alekrop
Copy link
Author

alekrop commented Jul 21, 2024

Thanks Jon for the feedback.
First sorry for such a big PR. Our openpiton-dev_upst is already rather cleaned-up and a narrowed-down version of a huge MEEP project to what could make sense to contribute. So lets consider further how to squeeze it more for your convenience. Yes, no problem to remove CMAC and multi-MC initially. And normal git patch for Ariane is for sure better than whole changed file, actually 2-3 lines are changed.
Also sorry for a number of commits. Probably extra branch is needed for PR to have them squashed. I thought squash is possible during the PR. The history really doesn't make sense.
So I will deal with sorting out the above things as next step.
Regarding ini_x/y that was an experimental feature and is not active by default. Likely the idea behind requires a separate discussion.

@Jbalkind
Copy link
Collaborator

Ok that all sounds good. I think going for a squash at merge time is reasonable so let's assume that we'll do that.

Thanks!

@alekrop
Copy link
Author

alekrop commented Oct 1, 2024

Hi @Jbalkind , sorry for a delay. Some update is here: now Ariane patching is done through git apply. Here is ariane.patch .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants