Hi Andrea! Adding my comments and questions inline below...
> 1) I would like to implement a first FFT (512 overlapped channels), The "overlapped" statement makes me nervous! Are you using the standard CASPER toolflow? This does not support multiple clock domains. Or were you planning to just increase the bin width? Note that you will then have aliasing within the channel. One way to do this might be to have two FFTs, with one having the time domain signal mixed up by 0.5 channels. It uses twice the resources, and doubles the datarate, but this is the easiest way to get overlapping channels in the standard CASPER 'flow. > send the data to a corner-turner implemented in the HMC and read-back one > channel at time by performing another 512 channels FFT in order to achieve a > 250k channels spectrometer. I have read this Jason Manley presentation > (http://www.tauceti.caltech.edu/casper-workshop-2017/slides/15_manley.pdf) > and slide 18 says that the Corner-Turner (matrix transpose) is available as a > Higher-level HMC block in DSP library, however I did not found it, can you > point out me where I can find it? Ah, sorry about this: It is not currently in the library. I have created a ticket to have it placed there. In the meantime, you can grab it directly from our fengine design linked below... The one we're currently using actually uses two HMC memories, one per polarisation, to guarantee the throughput under all conditions. The reason for this is that the HMC memory internally actually uses an array of 16 "vaults" of DRAM. To achieve their throughput claims, you have to stripe your data over all 16 vaults linearly. Of course, that's easy for any one operation of the CT, but then the other gets the worst possible situation: if you write into it linearly, then the read operation will hit one vault a lot before hitting the next vault. So we halve the datarate by using two memories. I'm not sure this is really needed, but we're playing it safe. The HMC-CT then has a bit of logic to realign the data from the two memories before outputting the data. If you're only using one HMC memory then you can rip this out. The CT also has some slightly more complicated features, like being able to offset the reads (this allows each Fengine to send its data to a different Xengine at any moment in time, to avoid switch bottlenecks). You can ignore these registers for your application and just set 'em to zero. There are also some limitations, like it's hard-coded to accept 4 channels (complex values) from two polarisations simultaneously. But I'm sure you'll figure these out. > 3) Are the FPGA designs used for Meerkat available? Perhaps I can re-use part > of those for our designs, please let me know whether or not they are open > source and where I find them. Yes, they are open source and available for you to use. Have a look in the feng_wide and xeng_wide folders here: https://github.com/ska-sa/mkat_fpga/tree/devel/source I suggest you start with the 1k model (s_c856m1k.slx). We actually uncovered a bug in the parameterisation of the HMC-CT just before we left for the conference that is preventing the 4k design from working (s_c856m4k.slx). Andrew Martens will be looking at that soon. But in the meantime, you can take a look at the 1k design. Jason -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
