AXI4 Master Read SDRAM

Hi @John,

I've gone through your screenshots carefully and I can see exactly what's happening. Good news is your write implementation looks solid - that's why it's working. The read hanging issue is something I've seen before with the Cyclone V f2h SDRAM interface, and I think I've spotted the problem. Looking at your working write test: * You're writing to address 0x10000004 * Using wr_len = 1 (single word transfer) * It completes successfully

Looking at your read test that hangs: * You're trying to read from address 0x10000004 * Using rd_len = 1 (single word transfer) * Then writing that value to another location * Processor hangs during the read operation

Here's the issue: while your simulation with the AXI4 Random Access Memory works fine with rd_len = 1, the actual Cyclone V SDRAM controller often has minimum burst requirements that the simulation block doesn't enforce. From the forum posts and documentation I found, the f2h SDRAM interface can be picky about burst lengths - particularly for reads. So, try this first, change your rd_len from 1 to something like 2, 4, or 8. I know you only need to read one value, but the SDRAM controller may not respond properly to single-beat read bursts.

Here's what to do:

1. Set rd_len to a constant value of 2 (or higher) 2. Keep everything else the same 3. When rd_dvalid goes high, just take the first data word and ignore any subsequent words

The reason writes work with wr_len = 1 but reads don't is that write and read channels can have different timing requirements in the SDRAM controller - reads often need longer bursts to pipeline properly. Now, looking at your interface mapping, it looks correct:

• read_slave (Input) -> f2h_sdram0 Read -> Read Slave to Master Bus
• data_in (Input) -> f2h_sdram0 Read -> Data
• wr_ready (Input) -> f2h_sdram0 Write -> Write Slave to Master Bus
• read_master (Output) ->f2h_sdram0 Read ->Read Master to Slave Bus
• Data (Output) -> f2h_sdram0 Write -> Data
• Write Master to Slave bus (Output) -> f2h_sdram0 Write

This all checks out, so the mapping isn't your issue. I did notice that you are using address 0x10000004, which is 4-byte aligned. That's good for a 32-bit interface. But just to be safe, verify:

 * Your data width in the SDRAM interface configuration matches what you specified (uint32 = 32 bits)

 * The address is definitely within your accessible memory region

So the reason your simulation is working but hardware does not is because of AXI4 Random Access Memory block in simulation is very forgiving - it responds to any valid transaction. The actual Cyclone V SDRAM controller has real hardware constraints:

• Minimum burst requirements for efficient operation
• Pipeline depth considerations
• Internal buffering requirements

These don't show up in simulation because the test block doesn't model them. So, here is step by step fix to try:

1. First test: Change rd_len from constant(1) to constant(2) in your read logic (Image 3, top section where you have the constant '1' connected to rd_len)

2. If that works: Try rd_len = 4 or rd_len = 8 to see if higher bursts are more stable

3. If it still hangs with rd_len = 2: Then we need to look at whether rd_dvalid is even asserting. This would mean the SDRAM controller isn't responding at all, which points to a different issue (like the bridge not being properly enabled or configured)

4. Debug visibility: If you have access to SignalTap or can add some LED indicators, monitor:

    * Is rd_aready going high? (tells you the controller is ready for requests)

    * Is rd_dvalid ever going high? (tells you if data is coming back)

    * What state is your read FSM in when it hangs?

References for the burst length stuff

• MathWorks HDL Coder AXI4 Master documentation (the section on rd_len): https://www.mathworks.com/help/hdlcoder/ug/model-design-for-axi4-master-interface-generation.html

• This RocketBoards thread about similar Cyclone V read issues (see the comment about burst requirements): https://forum.rocketboards.org/t/fpga-to-sdram-cyclone-v-can-write-but-cannot-read/2796

So, start by changing rd_len to 2 or higher. I'm hoping this will fix it. The SDRAM controller is probably waiting for more data requests before it starts the pipeline, and with rd_len = 1, it's just sitting there forever.

Let me know what happens when you try the higher burst length. If that doesn't fix it, we'll dig into whether the read channel is configured properly in your Qsys system.

Hi @John,

The Qsys screenshot shared by you confirms that `f2h_sdram0` (AXI-3, 32-bit) and the clocks are routed correctly, so the topology looks fine. Since `rd_aready` and `rd_dvalid` never assert in SignalTap, this points to a runtime issue — most likely the F2H SDRAM bridge isn’t actually enabled, or there’s an `rd_dready`/address-mapping problem, rather than an RTL wiring error. Try capturing `rd_avalid`, `rd_aready`, `rd_dvalid`, and `rd_dready` in SignalTap, and double-check the HPS handoff (u-boot or device-tree) to make sure the bridge is fully enabled.

Hi @John,

Your device tree snippet appears correct, enabling the FPGA-to-SDRAM bridge requires more than just including it in the device tree. Here's a step-by-step guide to ensure it's fully enabled:

1. Device Tree Configuration Your device tree entry for the bridge looks correct:

       dts
       fpgabridge@3 {
         compatible = "altr,socfpga-fpga2sdram-bridge";
         linux,phandle = <0x64>;
         phandle = <0x64>;
       };

   * Ensure this node is included in your final `.dtb` file and is accessible at boot time.

2. U-Boot Handoff

   * In U-Boot, use the following command to enable the bridge:

       bridge_enable_handoff

   * This command safely enables the bridge by applying the necessary configurations and releasing resets. 

https://www.intel.com/content/www/us/en/docs/programmable/683360/18-0/access-hps-sdram-via-the-fpga-to-sdram.html

3. Apply Configuration (APPLYCFG)

   * After programming the FPGA, ensure the bridge's configuration is applied:

        devmem 0xFFC2505C 32 0xA

   * This writes `0xA` to the `APPLYCFG` bit in the `STATICCFG` register, which latches the configuration. 

support.criticallink.com

4. Release FPGA Port Reset

   * Once the configuration is applied, release the FPGA ports from reset:

         devmem 0xFFC25080 32 0xFFFF

• This ensures the ports are active and ready for communication. support.criticallink.com

• Use SignalTap to monitor the following signals:

* `rd_avalid`: Indicates a valid read address.

* `rd_aready`: Indicates the read address is ready.

* `rd_dvalid`: Indicates valid read data.

* `rd_dready`: Indicates the read data is ready.

• If `rd_aready` and `rd_dvalid` never assert, it suggests the bridge isn't fully enabled or there's an issue with the configuration.

Let me know how it goes.