Forum Discussion

RLambdin92's avatar
RLambdin92
Icon for New Contributor rankNew Contributor
8 months 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...
Hps Boot
Hps Debug
Sw Development
  • TienFong_Altera's avatar
    TienFong_Altera
    8 months 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.

TienFong_Altera's avatar
TienFong_Altera
Icon for New Contributor rankNew Contributor
8 months ago

The error you’re seeing:

      Stratix10 SoC FPGA manager soc:firmware:svc:fpga-mgr: timeout waiting for svc layer buffers

is a common symptom of a design or flow mismatch, especially in the context of Partial Reconfiguration (PR) on Intel/Altera devices. Here’s a breakdown of what’s likely happening and how to address it.

Key Points with Stratix 10 Partial Reconfiguration

  1. Static/PR Region Interface Consistency
    • The interface (ports, connections, parameterization) between the static region and the PR region must remain absolutely unchanged between personas and after modifications.
    • Any change to the interface (even disconnecting signals or hardcoding values) can cause PR bitstreams to be incompatible or cause the system to hang (as you are seeing).
  2. Device Tree and Bitstream Pairing
    • The Device Tree Blob Overlay (dtbo) and bitstreams must match the actual hardware design. If you change the hardware, you must regenerate all PR personas, the static region, and update the device tree accordingly.
  3. Firmware Service Layer Timeout
    • This timeout typically means the FPGA manager tried to apply a PR bitstream, but the hardware (static+persona) is not compatible, or the handoff between Linux and the FPGA manager is broken due to mismatched or corrupted images.

Recommendations for Your Flow

  1. Ensure Interface Consistency
    • Do NOT change any port widths, names, or remove connections between the static region and the PR region. If you must hardcode LED values, do it inside the PR region (persona) rather than at the static top level.
    • The static region must be identical for all personas and for the base image.
  2. Rebuild Everything
    • After making changes, re-run the full Partial Reconfiguration flow
      • Re-generate the static region (base image).
      • Re-generate all PR personas.
      • Re-export the Qsys/Platform Designer system.
      • Rebuild the device tree with updated hardware descriptions.
  3. Check Qsys/Platform Designer Connections
    • If you disconnect signals in Qsys, make sure you do so only within the PR region.
    • The handoff files used for PR must match the actual design.
  4. Bitstream and Device Tree Synchronization
    • Make sure the bitstreams (.rbf, .per.rbf, etc.) and the device tree overlay you are applying are both built from the same version of the hardware design.
  5. Test Static Region First
    • Program only the static region (no PR) and boot Linux. Verify that the system is stable and accessible before attempting to load a PR persona
    • If the system fails at this stage, the issue is likely with the static region modification.

 

Thanks.