Trying to clock the FPGA at 320MHz will be tricky, so I'd suggest just demux again and run it at 160MHz. I believe that you should have enough resources to do this with at least a 4-tap PFB and 1024 channels. 2-inputs at 800MHz is equivalent to 4-inputs at 400MHz in terms of processing load. The only catch I can think of now might be in the bitwidth of the output BRAMs; I think tut4 requantises.
I'd suggest you try it and see how you go. The new libraries let you trade off BRAM for logic resources in the FFT, so you should be able to pack that FPGA quite tightly. Jason On 29 Aug 2012, at 11:32, Tom Kuiper wrote: > On 08/29/2012 02:30 AM, Jason Manley wrote: >> If you take a look at the pocket correlator design (tutorial 4), you'll find >> that it does four inputs of 400MHz bandwidth (800Msps). I think it has 4-tap >> PFBs with 1024 channels by default, which fits into a ROACH-1. If you >> forfeit two of the inputs, you should be able to get at least twice the >> channel resolution. If there's BRAM left over, you should be able to get >> even more. >> > I forgot to mention that we need a bandwidth of at least 640 MHz. > > Tom >> Jason >> >> On 29 Aug 2012, at 11:19, Tom Kuiper wrote: >> >> >>> Thanks for that, Jason! It is very timely. The reason I went down this >>> path is because I have a spectrometer design, by Joseph Trinh, which takes >>> a slightly different approach to bram access and so I could not use the >>> katcp_wrapper which I'd been using with your 16K spectrometer. He'd >>> offered to modify it but I thought it cool to try the file access I/O. I >>> think as a result of this exchange, I'll ask Joseph to modify his design >>> and I'll start using pyro. >>> >>> I hope he can squeeze it into a ROACH-1. He's got a 2x1024 spectrometer >>> design for me now but had to drop the PFBs because of insufficient >>> resources. I'm asking him to try 2x512 with PFBs. Does anyone already >>> have something like that? >>> >>> Next time around we'll use ROACH-2 but at the time we placed the orders we >>> weren't sure that the support for that would evolve fast enough to meet our >>> deadline (next month). >>> >>> Cheers >>> >>> Tom >>> >>> On 08/29/2012 01:09 AM, Jason Manley wrote: >>> >>>> On 29 Aug 2012, at 02:44, Adam Barta wrote: >>>> >>>> >>>>> You could also try an ssh port forward to the katcp port ssh -vNL >>>>> 7147:roach:7147 gateway >>>>> Then use the katcp interface to read / write the registers. There is a >>>>> katcp_wrapper.py in the corr library >>>>> >>>>> >>>> I would like to re-inforce this suggestion if you need SSH tunnelling >>>> through a firewall. A general word of warning to the CASPER community, >>>> which we also explained at the recent workshop... >>>> >>>> MeerKAT will not be supporting filesystem-level access in future boards >>>> (quite possibly starting with ROACH-2 already) and so, unless someone else >>>> in the collaboration picks it up, you'll be on your own if you write >>>> custom software to run on the PPC/BORPH because new platforms might not >>>> even run BORPH at all. There are a number of reasons for this decision, >>>> one being that we've run into performance limitations with BORPH, but also >>>> that it's a big overhead to port and debug and to keep it running reliably. >>>> >>>> The only interface supported by SKA-SA will be through KATCP. So if you >>>> start using the KATCP interface now, you'll have a transparent upgrade >>>> path to future boards. I'd suggest you don't worry yourself too much with >>>> the low-level detail... this is part of what CASPER tries to abstract away >>>> to ease your life as an instrument designer. >>>> >>>> If you don't want to write your own KATCP interface (and who does?!), >>>> consider using one of the existing ones. The best developed ones are in c >>>> (which includes a command-line executable for a single-line, ipython-like >>>> interactive experience from the shell prompt if you just want to call a >>>> shell script with a bunch of commands), available at >>>> https://github.com/ska-sa/katcp_devel, or a number of CASPER collaborators >>>> are using the python wrapper from corr if you want to build a higher-level >>>> GUI application. You can find a one-page getting started guide here: >>>> https://casper.berkeley.edu/wiki/Corr >>>> >>>> Jason >>>> >>>> >>>> >>> >>> -- >>> I or me? http://www.oxforddictionaries.com/page/145 >>> >>> >>> >> > > > -- > I or me? http://www.oxforddictionaries.com/page/145 > >
