> > > hi John, > > you asked about SPEAD FPGA implementations: > > Jason added SPEAD to the packetized correlator. > i'm appending Jason's November 26 update on correlators, > which includes a section on SPEAD. > > also, i think a recent pocket correlator, developed by Zaki, > uses SPEAD. Zaki and Aaron have also developed code to > read and process SPEAD packets.
Thanks, Dan. This is just what I needed to know. Jason, I'd like to take you up on the offer (in the attached mail below) to email model files that use SPEAD on ROACH. Thanks! John > > best wishes, > > dan > > > Hello correlator mailing list > > There have been a number of correlator developments since the last update > (some of which you may have heard about at the CASPER workshop): > * Switch to all ROACH design. > * Integrated 10GbE cores into the F engines and done away with the > complicated XAUI loopback (though this is still supported if you want > this optimisation). > * The X engines now output SPEAD over 10GbE natively (no more > corr_tx.py on the PPCs and automated start/stop/sync without user > intervention). > * The X engines process contiguous frequency channels (though the old > interleaved mode is still supported). > * Fringe rotation and delay compensation is now fully functional. > * Support for iADC and KATADC. > > Known bugs: > * Upon intialisation (FPGA reprogram) the ADC clock demuxes come up in > different clock offset states (all the pocket correlators and any > current packetised system also have this same bug). They can be up to > four clock cycles out of sync. So you'll need to do a delay calibration > every time you reinit the system. We have a plan to fix this and should > have it ready in the next week or so by using the infrastructure for > the existing coarse delay block. > > > CORR > ==== > The Python correlator control package, corr, has matured nicely and is in > daily use at KAT for debugging. Although probably not deployment quality, > it is a nice simple way to test new features and fiddle with the design. > We have released it on PyPI herehttp://pypi.python.org/pypi/katcp. > Development has moved out of the CASPER SVN RCS and I hope to get it into > git soon. I have attempted to keep backwards compatibility from version > 0.5.0 onwards but I am no longer actively working on certain > configurations, so YMMV if your setup is different to mine. I welcome any > support to add features, clean up code and fix bugs. We have moved to > using the iniparse package for reading the config file. You might need to > install this python package if you upgrade your corr package from a very > early version. > > > SPEAD > ===== > Since version 0.4.0, corr has relied on KATCP for control communications. > You can always get the latest version of KATCP > here:http://pypi.python.org/pypi/katcp > Experimental support for the SPEAD protocol was added in version 0.5.x and > is now fully supported since version 0.6.0. This protocol is used for high > speed UDP data exchange (completely separate and complimentary to the > TCP/IP-based KATCP for control and monitoring). > > SPEAD will be the native data format for all future KAT instruments and > I'd encourage you to take a look at the spec (attached) for any future > instruments you may build. It is highly flexible and of course all open > source. SPEAD is a self-describing format suitable for propagating data > across network links or for on-disk storage of data. It is supports > complex structures and multidimensional arrays of such structures, > including on-the-fly resizing and redefinition of data products along with > machine and human readable descriptions allowing the receiver to not only > reassemble, but also interpret the data without any additional metadata. > The protocol is able to receive data from multiple sources simultaneously. > It was designed with high efficiencies in mind and so only changes in data > products are propagated across data links and these done with little > header overhead. A subset of the protocol is also simple enough to > implement on low-level logic devices such as FPGAs and 8bit > microprocessors. PAPER and KAT7 are already using it and it will also be > used for inter-node transport in AIPY. The reference implementation of > SPEAD is still experimental but is functional. It is not yet in PyPI but > you can get it from Simon's GIT repo:http://github.com/sratcliffe/PySPEAD > Included are a few examples in the "tests" directory showing you how to > use it. > > As a reference receiver, corr now includes two new corr_rx scripts > (depending on your system's output configuration). They capture SPEAD > heaps and stores them to disk in HDF5 format using existing Python > libraries. It can optionally send realtime signal display data to another > computer too, mating to an external package, katsdisp, for realtime signal > visualisation. > > FUTURE > ====== > Until we figure out what do with with the revision control system, I can > email individuals the lastest ROACH model files or bitstreams if you want > them. If you have 16 ROACH boards and a 10GbE switch, you can assemble a > duplicate of our system to play with or scale it up or down to suit your > needs. This reference 16 FPGA version is mostly empty (about 50% full), > processing 512 channels over 400MHz bandwidth, full stokes. So there's > lots of room to add features and things. It has 10GbE output and can do > high speed dumps (well below 100ms) or up to about 1min integrations > before integer overflows. Note that our F engines expect KATADCs. You > might need to recompile for iADC and update the config file as > appropriate. > > Next year we will be adding beamformers to the X engines. > > > Jason > > > > On 11/29/2010 8:12 AM, John Ford wrote: >> Hi all. >> >> Do any of you have any xilinx designs that implement SPEAD protocol >> packets over 10 GbE? >> >> John >> >> >> > > > >
