Re: [casper] ROACH 1 DRAM
Hi Marc, Can you expand on this a bit. Are you saying that I should set the top bits of the DRAM address in the FPGA fabric and that will then affect the 256 MB portion of the DRAM that is accessed by the PPC, which is then broken up into the 64 MB chunks described in the block documentation and accessed with the dram_controller register? That seems counter-intuitive. Jason, I looked at the read_dram and write_dram functions, and that's basically the way my code works. I was hoping to see some secret extra register setting I was missing to explain the behavior I'm seeing. Thanks again for the input on this problem. Hopefully I'll figure it out eventually. Glenn On Tue, Feb 25, 2014 at 2:43 AM, G Jones glenn.calt...@gmail.com wrote: Hi Marc, Thanks for the reply. I would have expected that selecting the 64 MB chunk with the dram_controller register as described in the DRAM block documentation on the wiki would get around any such PPC address space limitation. Is that not the case? Glenn On Feb 25, 2014 2:30 AM, Marc Welz m...@ska.ac.za wrote: On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote: Hi, Sorry to repost this. Just curious if anyone has experience using more than 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface. The PowerPC's virtual memory subsystem maps things in 256Mb regions/segments, and only one is used to access the FPGA(*) - so you will probably have to implement some sort of windowing/base+offset scheme. (The address space of the PowerPC is pretty constrained) regards marc
Re: [casper] ROACH 1 DRAM
Corr does this in 1MB chunks for this reason. I suspect a problem in the controller. Glenn, can you access over 256MB from the fabric? Jason On 26 Feb 2014, at 17:13, Marc Welz m...@ska.ac.za wrote: On Tue, Feb 25, 2014 at 7:43 AM, G Jones glenn.calt...@gmail.com wrote: Hi Marc, Thanks for the reply. I would have expected that selecting the 64 MB chunk with the dram_controller register as described in the DRAM block documentation on the wiki would get around any such PPC address space limitation. Is that not the case? I think that should indeed be the case - I had forgotten that the base+offset scheme had already been implemented quite some time ago. A note though: On the other side of the FPGA, there isn't that much memory to go around either - so where possibly try and send it out (or process it) in smaller pieces regards marc
Re: [casper] ROACH 1 DRAM
I'm not 100% sure, as I don't write from the fabric: I load using the PPC interface and then playback from the fabric. I may have found an addressing problem in my design; I'm rebuilding now to check it and will report back. On Wed, Feb 26, 2014 at 10:17 AM, Jason Manley jman...@ska.ac.za wrote: Corr does this in 1MB chunks for this reason. I suspect a problem in the controller. Glenn, can you access over 256MB from the fabric? Jason On 26 Feb 2014, at 17:13, Marc Welz m...@ska.ac.za wrote: On Tue, Feb 25, 2014 at 7:43 AM, G Jones glenn.calt...@gmail.com wrote: Hi Marc, Thanks for the reply. I would have expected that selecting the 64 MB chunk with the dram_controller register as described in the DRAM block documentation on the wiki would get around any such PPC address space limitation. Is that not the case? I think that should indeed be the case - I had forgotten that the base+offset scheme had already been implemented quite some time ago. A note though: On the other side of the FPGA, there isn't that much memory to go around either - so where possibly try and send it out (or process it) in smaller pieces regards marc
Re: [casper] ROACH 1 DRAM
On Tue, Feb 25, 2014 at 7:43 AM, G Jones glenn.calt...@gmail.com wrote: Hi Marc, Thanks for the reply. I would have expected that selecting the 64 MB chunk with the dram_controller register as described in the DRAM block documentation on the wiki would get around any such PPC address space limitation. Is that not the case? I think that should indeed be the case - I had forgotten that the base+offset scheme had already been implemented quite some time ago. A note though: On the other side of the FPGA, there isn't that much memory to go around either - so where possibly try and send it out (or process it) in smaller pieces regards marc
Re: [casper] ROACH 1 DRAM
I haven't used ROACH DRAM in a long while, but I do recall testing it beyond 256MB (not very thoroughly though; wrote a counter from fabric and read back 1024MB... took many minutes) when I implemented the read_dram function in corr: def read_dram(self, size, offset=0,verbose=False): Reads data from a ROACH's DRAM. Reads are done up to 1MB at a time. The 64MB indirect address register is automatically incremented as necessary. It returns a string, as per the normal 'read' function. ROACH has a fixed device name for the DRAM (dram memory). Uses bulkread internally. @param selfThis object. @param sizeInteger: amount of data to read (in bytes). @param offset Integer: offset to read data from (in bytes). @return Binary string: data read. According to my notes, DRAM represents a 64MB chunk of the 256MB FPGA block. An offset (indirect page address register) is auto-incremented by this python function as needed. So you should be able to read beyond 256MB. You can tell this function's old though... it pre-dates the whole logging infrastructure! YMMV. Jason On 25 Feb 2014, at 9:30, Marc Welz m...@ska.ac.za wrote: On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote: Hi, Sorry to repost this. Just curious if anyone has experience using more than 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface. The PowerPC's virtual memory subsystem maps things in 256Mb regions/segments, and only one is used to access the FPGA(*) - so you will probably have to implement some sort of windowing/base+offset scheme. (The address space of the PowerPC is pretty constrained) regards marc
Re: [casper] ROACH 1 DRAM
Hi, Sorry to repost this. Just curious if anyone has experience using more than 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface. Thanks, Glenn On Wed, Feb 12, 2014 at 12:44 PM, G Jones glenn.calt...@gmail.com wrote: Hi, I'm using the ROACH 1 DRAM for a lookup table for waveform generation with the DAC. Everything has been working well and as I expected, until I tried to use more than 256 MB. It looks like the ROACH has a single sided 1 GB DRAM module in the FPGA DRAM slot, but I don't have the exact part number (it came as shipped from Mo). I figured I might only be able to use 512 MB because of the caveat listed on the DRAM wiki page: Many ROACHs have been shipped with 1 GB dual rank DIMMs by default. The current DRAM controller is not able to handle multiple ranks, so when a dual-rank DIMM is installed on the board, only half the memory is available. In order to use the full 1 GB, a single rank DIMM is needed, or in principle a dual rank 2 GB module. But I was surprised to have issues passed 256 MB. Has anyone seen anything like this before? Is it a known issue? Thanks, Glenn
Re: [casper] ROACH 1 DRAM
On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote: Hi, Sorry to repost this. Just curious if anyone has experience using more than 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface. The PowerPC's virtual memory subsystem maps things in 256Mb regions/segments, and only one is used to access the FPGA(*) - so you will probably have to implement some sort of windowing/base+offset scheme. (The address space of the PowerPC is pretty constrained) regards marc
Re: [casper] ROACH 1 DRAM
Hi Marc, Thanks for the reply. I would have expected that selecting the 64 MB chunk with the dram_controller register as described in the DRAM block documentation on the wiki would get around any such PPC address space limitation. Is that not the case? Glenn On Feb 25, 2014 2:30 AM, Marc Welz m...@ska.ac.za wrote: On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote: Hi, Sorry to repost this. Just curious if anyone has experience using more than 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface. The PowerPC's virtual memory subsystem maps things in 256Mb regions/segments, and only one is used to access the FPGA(*) - so you will probably have to implement some sort of windowing/base+offset scheme. (The address space of the PowerPC is pretty constrained) regards marc
