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?


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.


On Sun, 18 Sep 2016 at 14:21 Michael D'Cruze 
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 


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!


Reply via email to