> 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. >
Hi Jack! Another good clue! I'll see what we have for latencies in the block. John > 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 >>> >>> >>> >> >
