Re: [casper] Spectrum woes
For the benefit of the casper list From: Andrew Vdb [mailto:avd...@gmail.com] Sent: 19 September 2016 14:19 To: Michael D'Cruze Subject: Re: [casper] Spectrum woes Hi Michael, Sure - it's the FFT BRAM optimization. The coefficient bug was that we were incorrectly applying the coefficients when the data is streamed - it was subtle, but enough to prevent the ~60dB out of channel rejection in the PFB we were expecting. Hope that helps. regards, Andrew On Mon, Sep 19, 2016 at 1:01 PM, Michael D'Cruze <michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>> wrote: Hi Andrew, Thanks for the tip – but you could clarify please whether the BRAM optimisations you are referring to are the Xilinx RAM block optimisations I was making, i.e. to change the block from optimising for Area to Speed, rather than the FFT BRAM optimisation option? Were you able to determine what caused the bug re: the PFB coefficients? I took a look at what the ROM block was calling and it looked ok; was it calling the file incorrectly at compile time? Thanks Michael From: Andrew Vdb [mailto:avd...@gmail.com<mailto:avd...@gmail.com>] Sent: 19 September 2016 07:55 To: Jack Hickish Cc: Michael D'Cruze; casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> Subject: Re: [casper] Spectrum woes 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<mailto: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.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@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<mailto:jackhick...@gmail.com>] Sent: 18 September 2016 22:27 To: Michael D'Cruze; casper@lists.berkeley.edu<mailto: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.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@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<tel:%2B27%2083%20312%207392> Email: a<mailto
Re: [casper] Spectrum woes
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
Re: [casper] Spectrum woes
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.dcr...@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.dcr...@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 > > > > > >
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.dcr...@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 > > > > >
[casper] Spectrum woes
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
