Hi all, We (SKA-SA) saw similar behaviour with our PFB and found it was a combination of things - one being to *not* select BRAM optimisations, and another was a bug in the coefficient use in the PFB. Give the ska-sa/mlib_deve <https://github.com/ska-sa/mlib_devel>l repo a spin - we pushed our fixes a few months back.
Andrew On Mon, Sep 19, 2016 at 1:00 AM, Jack Hickish <jackhick...@gmail.com> wrote: > Hi Michael, > > Hmmm. Can you link the repo you're using and a reference design? > > Thanks > Jack > > On Sun, 18 Sep 2016 at 15:05 Michael D'Cruze <michael.dcruze@postgrad. > manchester.ac.uk> wrote: > >> Hi Jack, >> >> >> >> To implement the change in optimisation I altered the delay_bram init >> script. Line 84 which configures the Xilinx ram block, I changed the >> parameter ‘optimize’ from ‘Area’ to ‘Speed’. No other changes were made, >> so, I think this is the former case? >> >> BW >> Michael >> >> >> >> *From:* Jack Hickish [mailto:jackhick...@gmail.com] >> *Sent:* 18 September 2016 22:27 >> *To:* Michael D'Cruze; casper@lists.berkeley.edu >> *Subject:* Re: [casper] Spectrum woes >> >> >> >> Hi Michael, >> >> >> >> Is this actually the optimisation parameter of the xilinx bram block, or >> an optimisation of a casper block which completely changes some underlying >> circuit (eg by doing a bunch of fanout control and instantiating multiple >> small brams instead of one big one)? >> >> If the latter, are you sure it's not a bug in the casper implementation? >> Perhaps a mismatch of latency on various things being fanned out? >> >> >> >> Trust nothing. >> >> >> >> Jack >> >> >> >> On Sun, 18 Sep 2016 at 14:21 Michael D'Cruze <michael.dcruze@postgrad. >> manchester.ac.uk> wrote: >> >> Dear all, >> >> >> >> I’ve been chasing the cause of some nasty artefacts in my spectra >> recently. The first turned out to be a known bug in the Xilinx compiler, >> activated when the BRAM_sharing optimisation in the FFT is checked, however >> the artefacts I’m seeing since seem to be activated by the RAM blocks in >> the delay_bram block being configured for “Speed”, and not the default >> “Area”. >> >> >> >> Below are links to two spectra. They were both recorded from the Lovell >> telescope’s L-band receiver while the telescope was pointing at the zenith. >> The logic used in both cases is identical, with the exception that the >> delay_brams in the first spectra are configured for Speed, and in the >> second they are configured for Area (default). All operating parameters >> were the same in both cases. >> >> >> >> https://dl.dropboxusercontent.com/u/38103354/figure_1.png >> >> https://dl.dropboxusercontent.com/u/38103354/r13a_libs_18-09_2207.PNG >> >> >> >> Aside from how ugly the first spectrum looks (there are signals in there >> which simply don’t exist), even the accumulated power is different. The >> vertical scale is logarithmic so this is a factor 100 or so higher with the >> brams configured for Speed. I don’t understand how they could be so >> different, nor why configuring the brams for Speed should make any >> difference at all, not least a difference of this magnitude. >> >> >> >> The most worrying thing for me now is that configuring the brams for >> Speed was key to getting my larger designs (16k and 32k channels) to meet >> timing. If I need to reconfig for Area, I’m going to have to brawl with Par >> and PlanAhead all over again… It actually took a few goes to get just that >> 4k channel design to compile. >> >> >> >> I’d appreciate ideas/suggestions! >> >> Thanks >> >> Michael >> >> >> >> >> >> -- Dr Andrew van der Byl Mobile: +27 83 312 7392 Email: a <andrew.vander...@gmail.com>vd...@gmail.com
