Hi, Andrew, On Jul 23, 2013, at 10:03 PM, Andrew Martens wrote:
> Well, I am certainly glad that there is a rational explanation. Me, too! > So the FFT has not been broken for ~2 years or so, just since anyone upgraded > their tools. Yes, it only affects people using the 14.x System Generator with an FFT that uses the mirror_spectrum block (i.e. only the fft_wideband_real and fft_biplex_real_4x blocks, I think). >> 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. Thanks for the fast fix. I'm not sure that we should go overboard setting every possible parameter explicitly, but latency and possibly a few other key ones probably should be. I totally agree that script changes between toolflow version is not cool! It's somewhat ironic that the problem was discovered in an xBlocks block since I thought xBlocks was supposed to shield us from this very type of problem (though maybe I misunderstand the purpose of xBlocks). >> 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. I will push the script that I used to create a file containing the default latencies of all Xilinx blocks. This makes it easy to compare the default latencies of different versions. Thanks for all your work on this, Dave
