HPS DDR3 in Cyclone V

[Altera_Forum]

Hello, 

 Suppose we have a properly designed PCB with a Cyclone V SOC and DDR3 (routed to the HPS pins). I know that the HPS part is be able to load properly without any FPGA logic programmed and access its DDR3 successfully...  So what's the purpose of the SDRAM tab in QSYS (when creating the HPS)?

[Altera_Forum]

Hi,  

 I assume your refer to the SDRAM tab in the Qsys component "Cyclone V/Arria V HPS" (or something similar). This tab allows you to specify the memory parameters for the External Memory Interface that the HPS connects to. In the HPS, there is a dedicated SDRAM controller and it needs to know the type, speed, calibration settings, that will be used when setting up this interface. Once you compile the design, the details in this tab will be used as part of the hardware-software handoff folder. Then, when you use the bsp-editor tool to create the preloader, information from this folder will be used so that the preloader will be able to calibrate this interface successfully.  If you are able to start the HPS successfully (and access the DDR3), I assume that your preloader has been loaded onto the SD Card/QSPI and you did not change/modify it. Thus, even if you recompile your design for the FPGA, as long as the preloader remains untouched, the HPS DDR3 calibration will still be successful

[Altera_Forum]

--- Quote Start ---  I assume that your preloader has been loaded onto the SD Card/QSPI and you did not change/modify it. Thus, even if you recompile your design for the FPGA, as long as the preloader remains untouched, the HPS DDR3 calibration will still be successful  --- Quote End ---    That's correct. So even if I program the FPGA with a new RBF - as long as I don't update the files on the SD card - the newer SDRAM parameters won't take effect ? I.E: these SDRAM parameters aren't manifested in the RBF in any way ?

[Altera_Forum]

Yes, the HPS SDRAM parameters aren't manifested in the rbf (so does most HPS parameters such as HPS PLL counter settings, HPS Pin Mux, etc). One important thing that do manifest in the rbf is the availability of the HPS-FPGA bridges (and the IPs connected to them). For example, if you remove the HPS-FPGA bridges in your design and reprogram the FPGA part only, the HPS doesn't know that the bridges are no longer visible - thus attempt from HPS to access the FPGA memory space will result in hang. 

 Then, there're also other signals such as FPGA-HPS interrupts, FPGA-HPS resets, etc. If you do use these signals then yes, you need to make sure that the FPGA rbf and HPS related files (bootloader, device tree) are updated.