Hi John, I doubt this is your problem if it doesn't show up in simulation, but in the past I've had problems when using the cmult_dsp48 multiplier block (in addition to what danny mentioned). I don't know about the current CASPER libraries, but I've seen some FFT-related blocks in the past configure incorrectly when choosing multiplier/adder latency settings which don't match the latency of the cmult block, which is fixed.
Cheers, Jack On 18 July 2013 22:50, Danny Price <[email protected]> wrote: > Hi John > > I have had similar problems in the past. At the time I switched back to our > 'stable' 11.x library and used that to compile. > > We now think it's because our cmult_dsp48 broke during an overly adventurous > git merge: > https://github.com/oxfork/mlib_devel/commit/b8279fe777ce2aefa6111986092cc3cb3e8913f1 > > But we assumed this was confined to Oxfork. MIght be worth a look though... > > Cheers > Danny > > > > John Ford wrote: >> >> Hi all. >> >> We are building several new pulsar and spectral line personalities, and we >> have a weird problem with the FFT block. No matter how many channels we >> configure a block for, the last channel in each 1/8th of the spectrum is >> getting lost. For instance, if we have a 64 channel personality, channel >> 0-6 is fine, channel 7 is not fine, channel 8-14 is fine, 15 is not fine, >> etc. >> >> You can see this by placing a sine wave into the ADC corresponding to bin >> 6. Bin 6 shows a healthy spike in the output FFT. Life's good. >> >> Now change the frequency of the sine wave and put it into channel 7. The >> line (very nearly) goes away in the output. Move the frequency again to >> channel 8, and the line pops back up as it should. >> >> This happens no matter how many channels you build, the last channel in >> each 1/8 of the band is corrupted this way. >> >> This is using snap blocks to read the data straight from the FFT block, >> btw, so there's no other cruft in the test. >> >> Has anyone seen this? It seems to simulate correctly from what we can >> see, which is even more mysterious. >> >> We're using the casper library: >> >> [ptcs@ptcs /export/home/ptcs/scratch/guppi2/libraries/mlib_devel]$ git log >> -1 >> commit 6050c725f770f0bdb776fae107dc4fe26f7fce51 >> Merge: f50084e 0c15bf7 >> Author: Andrew Martens<[email protected]> >> Date: Mon May 20 10:59:32 2013 +0200 >> >> Merge branch 'master' of https://github.com/ska-sa/mlib_devel >> >> Copied new bitsnap block into separate module and added it by hand in >> casper >> Made the change of BRAM to bram in the snapshot block in >> casper_library_scop >> >> Conflicts: >> casper_library/casper_library_misc.mdl >> casper_library/casper_library_scopes.mdl >> >> >> Thanks. >> >> John >> >> >> >
