Re: [casper] Optimized software registers
Hey Henry. I think they will be little difference in practice. Perhaps a cycle less latency, but that is hard to say as I'm not really sure what was going on in the OPB-IPIF bridge. In principle the OPB-IPIF bridge might support bursting(for DMA) a little better. But I'm pretty sure DMA isn't used on software registers or anywhere else for that matter (certainly not on ROACH). The difference should only be in utilization. I've had a close look at the extra features in the old software registers and they are entirely superfluous. These could be removed on iBOB on BEE2 base package for a little extra saving there. Cheers, David On 21 April 2010 22:12, Henry Chen hche...@ssl.berkeley.edu wrote: Hi Dave, Those are some nice savings! Do you have a feel for whether there are any performance impacts, for better or worse, or should it be about neutral? Thanks, Henry On 4/19/2010 8:26 AM, David George wrote: Hi Aaron. Nice work! Are there any tantalizing details you might be able to pass along as to what changes made the difference? I always like the lessons-learned section... Sure, there were two things optimized: The first was an unnecessary OPB to IPIF bridge. This was an artefact from using the EDK GUI to create OPB modules. Rather than using this mechanism, I wrote the module with a direct OPB connection (which is simpler and easier to follow in my opinion) The other optimization was to trim the extras that were accessible from software (these included locks and status bits). I'm not sure that these features were ever used and are definitely not required for BORPH. I think that the registers are now as simple as they could be. Cheers, David On Mon, Apr 19, 2010 at 7:34 AM, David George david.geo...@ska.ac.za mailto:david.geo...@ska.ac.za wrote: Greetings All. I've done some optimization on the ROACH software registers and it has turned out to be pretty fruitful. The powerpc to simulink register utilization has been reduced from 99 to 26 slices (3.8x less). The simulink to powerpc register utilization has been reduced from 72 to 25 slices (2.9x less). This should help out with utilization if you use a lot of software registers (eg the packetized correlator). These changes apply from svn revision 2945. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za mailto:david.geo...@ska.ac.za -- Aaron Parsons 510-406-4322 (cell) Campbell Hall 523, UCB -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za mailto:david.geo...@ska.ac.za -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
[casper] 6 GS/s Spectrometer
Hi all. Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s ADC boards on a ROACH? I seem to recall someone doing something of the sort, but I don't recall any details. Thanks for any info! John
Re: [casper] 6 GS/s Spectrometer
Hi John, I don't think anyone has been able to get a spectrometer working at the full 3GS/s interleaved yet. The best Suraj and I have been able to do is about 2.4Gs/s before we start running into serious timing issues. We do have plans to meet soon with a Xilinx timing expert in the hopes of resolving our issues. Mark On Thu, Apr 22, 2010 at 2:12 PM, John Ford jf...@nrao.edu wrote: Hi all. Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s ADC boards on a ROACH? I seem to recall someone doing something of the sort, but I don't recall any details. Thanks for any info! John
Re: [casper] 6 GS/s Spectrometer
Hi John, I don't think anyone has been able to get a spectrometer working at the full 3GS/s interleaved yet. We are able to digitize and plot raw ADC data at full speed. We run into timing problems when the chip becomes more full, i.e. with an FFT. One possible solution we are (I am) exploring is pre-routing the ADC core (as this is where the router fails). If anyone knows how to pre-route a core for V5 I'd appreciate the help--the Xilinx documentation isn't all that helpful. -Suraj
Re: [casper] 6 GS/s Spectrometer
suraj is planning on hardening the yellow block cores so that their routing/timing is locked down, independent of what else is running in the fpga. Please don't make this the default behaviour. On designs that are nearly fully packed (99%), you need to be able to twiddle every part of the design to make it fit, and sometimes that means re-arranging the yellow blocks' innards. Part of the BEE2 DRAM controller was hard- routed and it caused complications when the chip got full. Jason On 4/22/2010 2:57 PM, Mark Wagner wrote: Hi John, I don't think anyone has been able to get a spectrometer working at the full 3GS/s interleaved yet. The best Suraj and I have been able to do is about 2.4Gs/s before we start running into serious timing issues. We do have plans to meet soon with a Xilinx timing expert in the hopes of resolving our issues. Mark On Thu, Apr 22, 2010 at 2:12 PM, John Ford jf...@nrao.edu wrote: Hi all. Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s ADC boards on a ROACH? I seem to recall someone doing something of the sort, but I don't recall any details. Thanks for any info! John
Re: [casper] 6 GS/s Spectrometer
Yes, I think a parameter is a good idea. Maybe just a radio-box or a drop-down-selection in the mask. Multiple cores will confuse users (like everyone gets confused by the multiple FFT blocks) and will probably become an admin nightmare down the road. Jason On 23 Apr 2010, at 07:40, Dan Werthimer wrote: hi jason, perhaps we can have different yellow block cores, one hardened for people that need high speed input, one not hardened, or better yet - a parameter that selects whether the routing is hardened or not? dan On 4/22/2010 10:32 PM, Jason Manley wrote: suraj is planning on hardening the yellow block cores so that their routing/timing is locked down, independent of what else is running in the fpga. Please don't make this the default behaviour. On designs that are nearly fully packed (99%), you need to be able to twiddle every part of the design to make it fit, and sometimes that means re- arranging the yellow blocks' innards. Part of the BEE2 DRAM controller was hard-routed and it caused complications when the chip got full. Jason On 4/22/2010 2:57 PM, Mark Wagner wrote: Hi John, I don't think anyone has been able to get a spectrometer working at the full 3GS/s interleaved yet. The best Suraj and I have been able to do is about 2.4Gs/s before we start running into serious timing issues. We do have plans to meet soon with a Xilinx timing expert in the hopes of resolving our issues. Mark On Thu, Apr 22, 2010 at 2:12 PM, John Ford jf...@nrao.edu wrote: Hi all. Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s ADC boards on a ROACH? I seem to recall someone doing something of the sort, but I don't recall any details. Thanks for any info! John
