Hi Andrew, I'm dredging up this old thread because I think the fix you comitted for this problem: https://github.com/ska-sa/mlib_devel/commits/master/casper_library/mirror_spectrum_init.m b222bd is not correct; I think the relational latency in mirror_spectrum should also be set to 1 explicitly. I don't have hard evidence for this, but I think that designs I've compiled where the relational latency was 1 had good spectra, whereas those with relational latency of 0 have a glitch in one bin every 1/8th of the spectrum, where the 1/8th comes from the number of parallel inputs in the system. Can anyone else verify this?
Glenn On Wed, Jul 24, 2013 at 1:03 AM, Andrew Martens <[email protected]> wrote: > Hi Dave > >>> The only way that the script could generate logic that would result in >>> correct data would be correct if; >>> 1. The Relational block could get a latency of 1 when no latency was >>> specified i.e default operation has latency of 1 in that toolflow version. >> >> You're right! That's exactly the problem. In System Generator version >> 13.3.4175 (at least in the copy of it that I use), the Relational block has >> a default latency of 1. In System Generator version 14.2.4415 (at least the >> copy of it that I use) the Relational block has a default latency of 0. > > Well, I am certainly glad that there is a rational explanation. So the FFT > has not been broken for ~2 years or so, just since anyone upgraded their > tools. > > >> I looks like the mirror_spectrum_init function is one of a few places in >> the casper libraries where a Relation block is placed without explicitly >> setting its latency. This will result in different latencies (and therefore >> overall behavior) for such blocks depending on which version of the System >> Generator is used. >> >> I only found two other places where this happens: >> >> 1) address_gen_vacc_v2_mask,m - This will affect the dram_vacc block. >> >> 2) delay_wideband_prog_init.m - This affects the delay_wideband_prog >> block, but only when it is configured to use Single Port BRAM. >> Unfortunately, I think that block might have other issues because I could >> not get a test model to function as expected for either System Generator >> version. >> >> It looks like your updates to the mirror_spectrum_init script still leave >> the latency of the Relational block unspecified. It would be great if you >> could add an explicit latency value to that block. That would make your >> update compatible with both older and newer versions of System Generator. > > I will fix this immediately. I guess that we should really explicitly set > every parameter that affects generated logic (latencies, number of bits, > arithmetic types etc) in light of this, script behaviour changing between > toolflow versions is not cool. > > >> I just compared the latencies of all the Xilinx blocks between 13.3.4175 >> and 14.2.4415. Only the Relational block had a change in latency so no >> other problems of this nature are likely to be lurking out there. > > That is a relief, thanks for taking the time to work through this. > > Regards > Andrew > > >
