Cyclone V SoC - Shared Memory Controller

Thanks for the reply thepancake, I have just discovered that the reason waitrequest was high. The preloader file needs to be updated following the change to the HPS component to add the FPGA to HPS SDRAM port to the HPS SDRAM controller configuration. My problem was that the preloader did not correctly re-generate (see below).

Apparently you need to delete the entire spl-bsp directory before generating the pre-loader. When I attempted to make the preloader generating in bsp-editor, then running the makefile in the spl-bsp directory, the generated preloader file (preloader-mkpimage.bin) did not change. Once I deleted the entire spl-bsp folder and re-generated, this time the preloader file was changed. Once I ran using this pre-loader, the SDRAM to FPGA avalon interface appears to work normally (i.e. waitrequest is low until the controller is busy).

However, the problem I am now having is that when I attempt a read from the FPGA I cause the system to crash (terminal freezes and HPS requires a hard reset) and no data is returned to the FPGA (Read Valid is never set) Possibly I am attempting to access an area of RAM that I shouldn't be?

I am not certain of how the HPS SDRAM maps to the avalon interface but the area I am trying to access is the area that I think is being assigned by the rocketboards example module http://www.rocketboards.org/foswiki/.../myfirstmodule

That sounds like the bridge hasn't been opened up. For a master in the HPS (like the CPU) to be able to access anything in the FPGA the following is required:

1 - Bridge needs to be clocked and pulled out of reset

2 - Bridge needs to be enabled in the address map (this is enabled in the GPV of the L3 interconnect)

By default the HPS-to-FPGA bridges are not mapped in after the system comes out of reset so software has to do that.

Taz1984,

Were you able to resolve your issue with DS-5? I have been trying to access the hps sdram from the fpga side using the f2h_sdram interfaces with no success. I'm not sure why, but if I try to access SDRAM from the FPGA side, the DS-5 debugger looses communications with the MPU. This indicates to me that accessing the SDRAM from the FPGA side is locking up the SDRAM controller and crashing the MPU. I'm trying to understand what has to be done in the SDRAM controller to properly configure the f2h_sdram interfaces, and whether this should happen in the preloader or the u-boot process?

I appreciate any insight anyone may have on this issue.

Thanks

-kstolp

Hi kstolp,

I have got a working block in the FPGA that masters transfers from HPS RAM to FPGA RAM. I experienced a similar issue along the way (many times!), the HPS seems to 'hang' so the terminal freezes up and if you are debugging you lose the connection. This happens from my experience for one of two reasons, the HPS is attempting to address a slave bus that is not yet configured (e.g. if the fpga has not been programmed or there is a problem with your FPGA design).

The second reason is if you attempt to access an area of HPS RAM that you're not supposed to (I'm guessing the OS is doing something critical with the data stored in these locations?). I don't know why but accesses to some areas caused my design to crash.

I used the example module http://www.rocketboards.org/foswiki/.../myfirstmodule. This allocates a buffer in HPS RAM and, importantly, you can read the physical address of the buffer. This allows the FPGA to access data that your application copies into this buffer. This is safer since you know that this area in the HPS RAM will only have your data in. In my design I had to divide the physical address by 4 (to make 32-bit aligned) and add an offset of 0x2000 0000 (I don't know why!) to get the physical address of my HPS buffer from the FPGA viewpoint. I found this out mainly by trial and error.

It should be possible to do allocate the buffer using kmalloc() in your code and then get the physical address using virt_to_phys() but I have not been able to get this working due to issues with the compiler, but this is done for you if you use the module anyway.

Also I forgot to add that you need to make sure you re-generate the preloader when you change your HPS to have the F2H SDRAM port in QSYS. I had to delete the entire spl-bsp directory before generating the pre-loader since there is a bug which means it doesn't update some files if they already exist.

If the preloader doesn't know about the F2H SDRAM port it will not be correctly configured and when you attempt to read it crashes (I also experienced this).

Dave,

Thanks for the feedback. I will try your lessons learned in my design. The 0x2000_0000 offset you add is interesting. It would be nice to know why, but for now, I'll give it a try. I assume you are using the address span extender to interface your fpga masters to the F2H SDRAM port (as BadOmen has pointed out). Is this correct?

I was already doing your preloader delete the directory trick. One thing that has not been obvious to me is where the F2H SDRAM port is configured in the software chain. You have indicated that this does get taken care of by the preloader generated by the bsp-editor. Other than the preloader trick, is there anything else that needs to be done to configure the F2H SDRAM port? BadOmen has stated that the bridges need to be taken out of reset. I have not come across such a requirement for the F2H SDRAM port. Is this your understanding as well?

Thanks again,

-kstolp

Hi kstolp,

I did not use the address expander. I prefer to access the Avalon-MM bus directly since I am not connecting to a NIOS on the FPGA but only to my own FPGA logic which can address the memory with no issues. I've found the avalon interface to be pretty user friendly so it didn't take long to write some VHDL to access the port.

I have not had to explicitly take any of the bridges out of reset, although I believe the way to do this is to write directly to the "rstmgr > brgmodrst" registers at 0xFFD0501C (see http://www.altera.com/literature/hb/cyclone-v/hps.html)

I know that the pre-loader does something differently after you enable the F2H SDRAM port since it changes some of the generated software files are changed (e.g. hps.xml <config name='F2SDRAM_READ_PORT_USED' value='1' />). If you don't update the pre-loader then the avalon-MM interface to your F2H SDRAM port will hold "waitrequest" high and so you can't request any reads or writes (maybe because the bridge was in reset?).

I think that the pre-loader must be taking the bridges out of reset since I am not doing this in my application code?

I've been searching for any pointers to enable read / write access of HPS ram from the FPGA but cannot find any example code.

The rocket board link fails (even when I have logged into the rocket board site), could you confirm the link or (big ask) share your project?

--- Quote Start ---

Hi kstolp,

I have got a working block in the FPGA that masters transfers from HPS RAM to FPGA RAM. I experienced a similar issue along the way (many times!), the HPS seems to 'hang' so the terminal freezes up and if you are debugging you lose the connection. This happens from my experience for one of two reasons, the HPS is attempting to address a slave bus that is not yet configured (e.g. if the fpga has not been programmed or there is a problem with your FPGA design).

The second reason is if you attempt to access an area of HPS RAM that you're not supposed to (I'm guessing the OS is doing something critical with the data stored in these locations?). I don't know why but accesses to some areas caused my design to crash.

I used the example module http://www.rocketboards.org/foswiki/.../myfirstmodule. This allocates a buffer in HPS RAM and, importantly, you can read the physical address of the buffer. This allows the FPGA to access data that your application copies into this buffer. This is safer since you know that this area in the HPS RAM will only have your data in. In my design I had to divide the physical address by 4 (to make 32-bit aligned) and add an offset of 0x2000 0000 (I don't know why!) to get the physical address of my HPS buffer from the FPGA viewpoint. I found this out mainly by trial and error.

It should be possible to do allocate the buffer using kmalloc() in your code and then get the physical address using virt_to_phys() but I have not been able to get this working due to issues with the compiler, but this is done for you if you use the module anyway.

--- Quote End ---