Forum Discussion
Hi,
I can verify that AGIB027R29A1E1VB works with the OFS 2024.1 environment and oneAPI 2024.0 compiler.
The AGIB027R29A1E1VB board has 2 on-board 8GB component memory and 2 external DIMM slots. The board comes with a single 16 GB RDIMM module upon purchase. However, OFS was verified using 2x8 GB UDIMMs for the external slots.
To get the board to work:
- Swap the RDIMM for 2 UDIMMs (you can get the board to work without the external DIMMs, but for such an expensive board you might as well spend another $100. If you are unable to, let me know and I can share the workaround)
- If you are using OFS 2024.1 or OFS 2024.2, change the Agilex Device Number following the instructions here: PCIe Attach I-Series (2xR-Tile, F-Tile) - OFS
- Following the previous instructions, update the pinout constraints by updating the files
$OFS_ROOTDIR/syn/board/iseries-dk/setup/emif_loc.tcl and $OFS_ROOTDIR/syn/board/iseries-dk/setup/top_loc.tcl. I took the constraints from OFS 2024.3
It turns out that in OFS versions newer than 2024.3, they use the exact same device number AGIB027R29A1E1VB instead of the Early Silicon sample. They also tell you which Micron UDIMMs they used so you can buy the exact same model. Check out the explanation here PCIe Attach I-Series (2xR-Tile, F-Tile) - OFS
I am working on verifying the board with the OFS 2024.2 environment and oneAPI 2025.0. I am also interested in trying OFS 2024.3 with oneAPI since it uses our exact board, even though oneAPI is only officially supported up to OFS 2024.2.
Out of curiosity, do you mind me asking what you are using oneAPI for?
Hello,
Apologies for my absence, I've been busy with the end of a semester and creating/defending my PhD proposal.
Thank you for sharing this information! I'll go ahead and see about swapping out the memory sticks and following your steps to see if I can get them to work as well.
For clarity, I follow those first two steps you lay out, copy the "emif_loc.tcl" and "top_loc.tcl" from the OFS 2024.3 Github and replace the pre-existing ones, then build the FIM and ASP? Or are the other 10 steps you outlined previously (removing north/south I/O, modifying the board_spec.xml, etc.) still needed?
We're interested in using oneAPI for acceleration architectures on this FPGA, since oneAPI is (as far as I'm aware) what Altera is using for their HLS toolkit at this time.
Best,
James
- jchecmu1 month ago
New Contributor
I understand. I am also in the midst of proposing my PhD thesis haha. It is cool to see another group using OFS, and I would be interested in having a chat :)
Yes, copy emif_loc.tcl and top_loc.tcl to update the pinouts for the device. The FIM and ASP should build and run with the few steps I listed in the most recent reply. The previous steps that I listed are not needed.
- jjb1696 days ago
Occasional Contributor
Best of luck with your preparation and studies! I'm more than happy to have a chat sometime as well, I would be interested to hear your experience with these tools and platforms, and all that you've used them for.
I've gone ahead and followed your brief three steps and am now building the FIM (fingers crossed) now that my schedule has calmed down a bit. I'll be sure to report back as to how things go, but I again greatly appreciate everything you've done!
- jjb1694 days ago
Occasional Contributor
Hello,
I followed the steps you laid out in your previous response: using 2 UDIMM modules, changing the Agilex 7 part number, copying over the emif_loc and top_loc files, then building the FIM and ASP. I ran into an initial problem caused by the hssi, where errors were thrown during FIM compilation regarding its source files, so I removed it from the final build. Additionally, the default configuration (1x16 1PF/1VF I believe) produced errors in the oneAPI ASP step, so I changed that to 2x8 with 1PF/1VF. My complete compilation command is as follows:
./ofs-common/scripts/common/syn/build_top.sh -p --ofss tools/ofss_config/pcie/pcie_host_2link_1pf_1vf.ofss iseries-dk:no_hssi
Upon running "aocl diagnose acl0", however, I am seeing the same DMA errors I was encountering some time ago. The output will be attached to this response, but it is interesting to note that the number of VTP L2 hits and misses are not consistent across iterations of this command. As such, I am unsure where to go moving forward, really, since this issue went unresolved in my initial interactions with the Altera team in this forum post.
Another interesting note is that I have to run this command as the root, otherwise I get the following errors:
"Error allocating DMA buffer"
"Error allocating write_fence buffer"I am curious if I messed up my system configuration, somehow, but I will look further into this.
Do you have any advice on how to maybe alleviate the diagnosis errors that I'm seeing? Did you follow a similar pattern for building your FIM?
Thank you!
JamesEdit: I see now on the Altera site that oneAPI is discontinued in favor of their similar, SYCL-based "HLS IP Gen Compiler" (link)...
- jchecmu1 day ago
New Contributor
I have not tested the iseries board with HSSI. In OFS 2024.1 (the only version I have tested), I think both PCIe Gen4 1x16 and PCIe Gen5 2x8 should work. In this OFS version, I don't think PCIe Gen5 1x16 is officially supported.
I am also curious about your system configuration. Did you also set up huge pages?
I have run into DMA issues before but only because of custom edits I made to the shell. And still, I have not been able to diagnose where the problem lies from the error messages unfortunately.
I also plan on testing the HLS IP Gen Compiler soon.
- jjb16915 hours ago
Occasional Contributor
Thanks for the clarification on what you've tested!
My system OS is RHEL 8.8 with huge pages info and intel_iommu active as defind in the docs: intel_iommu=on pcie=realloc hugepagesz=2M hugepages=200.
OFS_ASP_ENV_NUM_HUGEPAGES is also set to 2048.
I was running into "AER: Uncorrected" errors for a while, too, pointing at my PCIe port, but I think I fixed that by adding pcie_aspm=off to my grub config.
It is certainly tricky to figure out where these errors are coming from, and I'll keep that in mind when making any custom edits moving forward, too. I am running into a new error now, however. It seems all data is writing properly to the FPGA, but reading back the elements is not working correctly. The new error log will be attached to this post - did you encounter anything like this? It's interesting that the lowest three numbers are as expected, but there is a "4" added to the first digit in the sequence. The transfer speeds also seem awfully low, so that is a point of concern as well.
I appreciate your help and any insight you may have once more! I'll keep digging into things on my end.