Extended support of Alveo boards by BSC

[alekrop]

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, 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.

[alekrop]

++ @Jbalkind

[Jbalkind]

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]

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]

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]

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

[Tiago-R]

Hi @alekrop, I'm very much interested in running OpenPiton on the U55C. What is the current status of this project?

[alekrop]

Hi @alekrop, I'm very much interested in running OpenPiton on the U55C. What is the current status of this project?

Hi @Tiago-R , Despite that the source branch of this PR is already behind the openpiton-dev branch, it is healthy, supports 3 kinds of Alveo Ultrascale+ boards and also contains other extensions (please read the PR description). You may may try it according to the updated Readme.