Cyclone V SoC F2SDRAM Read Interface Ready cmd_ready_0 Not Asserting

[JFrye7]

Hello, I am trying to develop a simple design with an Altera DMA Controlelr Core IP (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/nios2/n2cpu_nii51006.pdf) that reads from the HPS SDRAM, then writes back to another location in the SDRAM.

I have enabled a 32-bit wide AXI SDRAM interface in the Platform Designer menu for the IP. 

It seems in the generated RTL, the DMA has a master Avalon interface, that is then connected to an interconnect that converts it to AXI, then the AXI signals are packed an unpacked and wired directly to the SDRAM interface primitive.

It seems the SDRAM interface primitive has signals, whose naming convention would suggest they map to two interfaces, one for read, which is connected to the AXI read signals and one for write, which is connected to AXI write signals. 

The AXI ARREADY siganal is connected to a port on the primitive called cmd_ready_0. This signal never asserts.

During my test, I program the DMA core over the H2F_LW_AXI_MASTER . I see the AXI_ARVALID signal assert. This signal is connected to the primitive signal cmd_valid_0 (read valid). The transaction then stalls since the ready is not asserting.

Why is the ready never asserting?

[EBERLAZARE_I_Intel]

Hi,

Can you check if you have set the correct base addresses of the slaves in your design that is connected to the HPS AXI master bridge?:

https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html

[JFrye7]

HPS AXI has already been verified. I have software that can read and write the registers in my address map. I can write the DMA registers with my Linux user space application and read them back.

That offset in my software is 0xFF200000. I use /dev/mem to open and read the HPS AXI register space.

As far as FPGA2SDRAM bridge goes, I do have an update. By performing these two writes in U-Boot, I can at least get the address address ready signals for ports 0 and 1 (read and write ports for AXI) to assert. 

# fpga-sdram bridge
mw FFC25080 00000311
mw FFC2505C 00000004

After the interface appears to accept the read address requests coming from the DMA master interface, it never asserts the signal on the port that corresponds to AXI RVALID and the kernel freezes, then the thing reboots.

Not sure what this might be. My guess is one of two things

1. Interface registers are still not configured correctly

2. Platform Design HPS block has wrong DDR timing configurations.

If the HPS is set up with the wrong DDR timing parameters, would the ARM still be able to perform load/store instructions (because it obviously since it is successfully able to run u-boot and the OS)? 

[JFrye7]

Also worth noting my board is DE1-SoC, so it might have different timing parameters than your board for the DDR.

[EBERLAZARE_I_Intel]

Hi,

Is this your own design image? It may boot up with wrong DDR timings but it is never recommended, you may need to follow the timing specs of the DDR that you are using and set it correctly in Platform Designer, have you try running with the exact timing specs yet?

[JFrye7]

I have gotten the FPGA2SDRAM interface to work with updated version of both embedded_command_shell and u-boot-socfpga.

My next question (maybe I need to open another ticket about this) is about addressing. I have a similar design with an address space extender IP with which I attempt to write to the SDRAM interface through the fabric. 

Essentially as I understand it, by writing to the IP window register, I can get access to certain windows in the master address space "expanded master". I can then initiate transactions to the address span extender slave address space windowed_slave to trigger corresponding transactions on the extender_master interface based on what is programmed into the offset register.

In u-boot I attempt to write to addresses in the SDRAM using an address space extender. This address is within the first GB of the SDRAM. I then try to read back the address via the u-boot md command, but the data displayed is inconsistent with what was written through the fabric via address span extender. When I read back using address span extender, it matches what was written.

How addresses look different from perspective of FPGA2SDRAM interface vs from the HPS?

[EBERLAZARE_I_Intel]

Hi,

What was the output that you are seeing? 

You may refer below for on Address span extender usage:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-platform-designer.pdf#page=319