New ContributorStratix 10 GSRD Development Issues
Currently working with the GSRD Users Guide from the Rocketboards archives (https://altera-fpga.github.io/rel-24.3/embedded-designs/stratix-10/sx/soc/gsrd/ug-gsrd-s10sx-soc/#partial-reconfiguration_1). Have been attempting to try and better understand the Partial Reconfiguration portion of the design and have made some attempts at trying to modify the design and rebuild from there.
I've walked through the process fully to get the initial build fully developed and working. I then attempted to edit the top level of the design by disconnecting the user LEDs from the Qsys Top and hard coding their values. I went through the entire process again and replaced the ghrd_s10_top.sv with the LED changes before running "make all". Going through the entire rebuild process and the Yocto rebuild, I produced a JIC and SDCard Image which i loaded the same way as the working build. But when I attempt the "dtbt" device tree to apply either Persona, the command gets stuck and pushes a "Stratix10 SoC FPGA manager soc:firmware:svc:fpga-mgr: timeout waiting for svc layer buffers".
Looking for any assistance on the process of applying changes to the design and rebuilding this PR design. Thanks for any assistance
Let’s clarify both the environment separation (Quartus vs. Yocto) and the static region modification concerns in the context of Intel Stratix 10 Partial Reconfiguration (PR):
Environment Separation: Quartus vs. Yocto
Short answer:
It’s perfectly fine to run Quartus (hardware build) and Yocto (Linux image/device tree build) on separate machines, as long as you maintain the integrity and synchronization of the files between them.What must be consistent?
- The actual generation of SOF, RBF, JIC files must happen in one coherent Quartus environment (same project directory and version).
- These generated files (.sof, .rbf, .per.rbf, .jic, handoff files, etc.) are then transferred to your Yocto build machine for inclusion in the Linux image, device tree overlays, etc.
- Do not mix RBFs or JICs from different Quartus projects, or from different versions of Quartus.
- Yocto: Can be run on any machine, as long as it uses the correct hardware files and handoff files from your Quartus build.
Best practice:
After you finish all Quartus builds and have your output files, copy the entire set of relevant outputs to your Yocto machine. Always keep them matched as a set.How to Verify PR Hash Consistency
You can use the quartus_pfg -i command to inspect the PR hash and other metadata in your SOF and RBF files.
The PR hash must match across all images from the same build.Example Commands:
quartus_pfg -i ghrd_1sx280hu2f50e1vgas.sof
quartus_pfg -i stratix10_htile_pr_ghrd.core.rbf
quartus_pfg -i stratix10_htile_pr_persona0.rbf
quartus_pfg -i stratix10_htile_pr_persona1.rbfModifying the Static Region (GHRD_S10_Top.sv and LED Example)
Static Region & PR Interface:
- The static region is the part of your design that does not change during partial reconfiguration.
- The PR region is the area that can be reconfigured at runtime with different "personas" (bitstreams).
Key Rule:
You can change anything in the static region, as long as those changes do NOT affect the boundary/interface between the static region and the PR region.- If your GHRD_S10_Top.sv changes only involve logic or signals that are fully within the static region, and do not touch or alter the ports, signals, or interfaces that connect to the PR region, then it’s fine.
- However, if you change anything at the boundary (for example, change the width, type, or presence of a signal that connects static to PR), you must update every persona and the static region, and keep them all in sync.
You can post a snippet of your changes to GHRD_S10_Top.sv and a block diagram of your static/PR region boundary, and I can help confirm if your changes are safe!
Let me know how it goes when you get back to the hardware!
Thanks.
