Forum Discussion

RLambdin92's avatar
RLambdin92
Icon for New Contributor rankNew Contributor
1 month ago
Solved

Stratix 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...
  • TienFong_Altera's avatar
    1 month ago

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

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