Data Transfer from FPGA-to-HPS

There are basically two options.

First, you could hook up the FPGA to HPS bridge and carve out some DDR3 RAM to be used for storage purposes. The FPGA to HPS bridge has the master on the FPGA side and the slave in the HPS side. So, the FPGA side is the one issuing write requests, those requests have to go into some virtual memory space, and it might as well be RAM (unless it is a HPS-side peripheral.) You could write into RAM through the FPGA->SDRAM bridge, but that is not guaranteed to maintain cache coherency (so, as I understand, HPS-side memory reads may result in old data, even after the transfer, if it happens to be in the cache.) FPGA->HPS is slower than FPGA->SDRAM, but should be plenty fast enough for your task.

Alternately, you could go the other way around. In Qsys/Platform Designer, instantiate an altera_hps, an altera_avalon_onchip_memory2, and an altera_avalon_mm_bridge. Hook them up like so:

altera_hps.h2f_axi_master -> altera_avalon_onchip_memory2.s1

altera_avalon_mm_bridge.m0 -> altera_avalon_onchip_memory2.s1

Export altera_avalon_mm_bridge.s0.

Now you have some on-chip RAM (the amount configurable through altera_avalon_onchip_memory2's properties) that you can write on FPGA side through the pins you just exported and read on HPS side starting at the address 0xC0000000. The downside is that you don't have a whole lot of RAM to work with (your entire chip has something like 300 kbytes worth of M10Ks) so you need to be frugal.

P.S. I'm basically learning this as I go along myself, so take this with a grain of salt.

--- Quote Start ---

There are basically two options.

First, you could hook up the FPGA to HPS bridge and carve out some DDR3 RAM to be used for storage purposes. The FPGA to HPS bridge has the master on the FPGA side and the slave in the HPS side. So, the FPGA side is the one issuing write requests, those requests have to go into some virtual memory space, and it might as well be RAM (unless it is a HPS-side peripheral.) You could write into RAM through the FPGA->SDRAM bridge, but that is not guaranteed to maintain cache coherency (so, as I understand, HPS-side memory reads may result in old data, even after the transfer, if it happens to be in the cache.) FPGA->HPS is slower than FPGA->SDRAM, but should be plenty fast enough for your task.

Alternately, you could go the other way around. In Qsys/Platform Designer, instantiate an altera_hps, an altera_avalon_onchip_memory2, and an altera_avalon_mm_bridge. Hook them up like so:

altera_hps.h2f_axi_master -> altera_avalon_onchip_memory2.s1

altera_avalon_mm_bridge.m0 -> altera_avalon_onchip_memory2.s1

Export altera_avalon_mm_bridge.s0.

Now you have some on-chip RAM (the amount configurable through altera_avalon_onchip_memory2's properties) that you can write on FPGA side through the pins you just exported and read on HPS side starting at the address 0xC0000000. The downside is that you don't have a whole lot of RAM to work with (your entire chip has something like 300 kbytes worth of M10Ks) so you need to be frugal.

P.S. I'm basically learning this as I go along myself, so take this with a grain of salt.

--- Quote End ---

First off thanks!

Now going off what you said I think the F2H bridge is the best option for me so I don't have to worry about the cache coherency issues of the SDRAM bridge. Speed I don't believe should be an issue since I only need 80Mbitps transfer speeds, and I saw in another forum post that the bridge has 133 MHz frequency and I know it can support 128-bit width so that would give 2.12Gigabytes per second? In the case that I use the F2H bridge to setup DDR3 writes how would that look? I have found plenty of examples of H2F and the H2F lw, but none of the F2H except for the Altera one, which I can't seem to get to work on my DE0-Nano-SoC since it was written for the Cyclone V dev board.

Thanks again for all your help!

--- Quote Start ---

First off thanks!

Now going off what you said I think the F2H bridge is the best option for me so I don't have to worry about the cache coherency issues of the SDRAM bridge. Speed I don't believe should be an issue since I only need 80Mbitps transfer speeds, and I saw in another forum post that the bridge has 133 MHz frequency and I know it can support 128-bit width so that would give 2.12Gigabytes per second? In the case that I use the F2H bridge to setup DDR3 writes how would that look? I have found plenty of examples of H2F and the H2F lw, but none of the F2H except for the Altera one, which I can't seem to get to work on my DE0-Nano-SoC since it was written for the Cyclone V dev board.

Thanks again for all your help!

--- Quote End ---

Re: bandwidth, 2 GB/s would be only achievable with burst transfers. When writing one word at a time, it may be less (possibly much less). Not sure.

As in my first example, instantiate an altera_hps and an altera_avalon_mm_bridge. Connect bridge.m0 -> hps.f2h_axi_slave. Export bridge.s0. Now you have access to signals:

mm_bridge_0_s0_waitrequest

mm_bridge_0_s0_address

mm_bridge_0_s0_writedata

mm_bridge_0_s0_write

When you have data to send, essentially, put 1 into 'writedata', put your data into 'write', and put the physical address of RAM where you want to write into 'address', and wait for 'waitrequest' to go down. See https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/manual/mnl_avalon_spec.pdf (it's rather complicated).

--- Quote Start ---

Re: bandwidth, 2 GB/s would be only achievable with burst transfers. When writing one word at a time, it may be less (possibly much less). Not sure.

As in my first example, instantiate an altera_hps and an altera_avalon_mm_bridge. Connect bridge.m0 -> hps.f2h_axi_slave. Export bridge.s0. Now you have access to signals:

mm_bridge_0_s0_waitrequest

mm_bridge_0_s0_address

mm_bridge_0_s0_writedata

mm_bridge_0_s0_write

When you have data, you wait till 'waitrequest' is 0, put 1 into 'writedata', put your data into 'write', and put the physical address of RAM where you want to write into 'address'.

--- Quote End ---

Ok so I got that, now the channel width is only 128 Bits, would I write 128 Bits to the mm_bridge_0_s0_write multiple times advancing the physical RAM address by 128 each time? Or could I write the full say 37KBits into write data at once and the mm bridge will take care of the streaming? Sorry for my lack of knowledge on this, I really do appreciate the assistance

--- Quote Start ---

Ok so I got that, now the channel width is only 128 Bits, would I write 128 Bits to the mm_bridge_0_s0_write multiple times advancing the physical RAM address by 128 each time? Or could I write the full say 37KBits into write data at once and the mm bridge will take care of the streaming? Sorry for my lack of knowledge on this, I really do appreciate the assistance

--- Quote End ---

You can adjust the width of the bridge through its parameters. Looks like it won't go higher than 4096 though (and I'm not sure if it would even work if you tried to set it wider than the physical channel). It's really just an adapter to let you deal with the Avalon-MM protocol instead of the considerably more complex AXI protocol. (You could in principle just export hps.f2h_axi_slave and write into that.) So, yes, you write X bits at a time, advance the pointer and repeat.

Why would you even want to write 37 kilobit at once, anyway? That means 37000 physical wires on the FPGA, all feeding into some IP component that tries to squeeze all that data through a 128-wire bus. You can probably figure out a way to do that, but I can't see it being very efficient. On the FPGA side, most of the data should be stored in M10Ks, which are relatively "deep" but "narrow" (each M10K can store 256 32-bit words, and produce at most 2 of them per clock.) That works well if you want to pull them out one by one and send them on their way. If you want to access all your data at once, the compiler can't use M10Ks, it has to use regular registers, so your logic utilization goes through the roof. Your chip only has 60K registers across its entire surface.

--- Quote Start ---

You can adjust the width of the bridge through its parameters. Looks like it won't go higher than 4096 though (and I'm not sure if it would even work if you tried to set it wider than the physical channel). It's really just an adapter to let you deal with the Avalon-MM protocol instead of the considerably more complex AXI protocol. (You could in principle just export hps.f2h_axi_slave and write into that.) So, yes, you write X bits at a time, advance the pointer and repeat.

Why would you even want to write 37 kilobit at once, anyway? That means 37000 physical wires on the FPGA, all feeding into some IP component that tries to squeeze all that data through a 128-wire bus. You can probably figure out a way to do that, but I can't see it being very efficient. On the FPGA side, most of the data should be stored in M10Ks, which are relatively "deep" but "narrow" (each M10K can store 256 32-bit words, and produce at most 2 of them per clock.) That works well if you want to pull them out one by one and send them on their way. If you want to access all your data at once, the compiler can't use M10Ks, it has to use regular registers, so your logic utilization goes through the roof. Your chip only has 60K registers across its entire surface.

--- Quote End ---

Eugene, or anyone else that happens to be looking at this. I've hit a wall was wondering if you could offer some advice. Pretty much I have it set up I think the right way where for now the FPGA should be writing a 128 bit value to an address in memory, and I am trying to read it with the HPS but I am having 0 luck. Here is my QSYS setup: https://alteraforum.com/forum/attachment.php?attachmentid=15591&stc=1

I have also attached my top level code for the verilog modules: https://alteraforum.com/forum/attachment.php?attachmentid=15592&stc=1 https://alteraforum.com/forum/attachment.php?attachmentid=15593&stc=1 https://alteraforum.com/forum/attachment.php?attachmentid=15594&stc=1 . In this case I am just trying to write the debug value of 128'b1. My C Code is taken from: https://digibird1.wordpress.com/playing-with-the-cyclone-v-soc-system-de0-nano-soc-kitatlas-soc/ . I use his code for the SGDMA to try to read from 0x32000000. However I haven't had any luck. Any advice?

Make sure that you have mm_bridge_0_s0_byteenable set to all 1's.

If that does not help, make sure that you have the right preloader in the HPS.

--- Quote Start ---

Make sure that you have mm_bridge_0_s0_byteenable set to all 1's.

If that does not help, make sure that you have the right preloader in the HPS.

--- Quote End ---

Thanks eugene, I didn't have the byteenable set, so that's one issue. Also this may be a stupid question, but when do you need to remake the preloader and uboot? Everytime you change anything in your Quartus project? Or only when you change something in Qsys? Thanks