Re: [casper] strange problem in the FFT
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 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 > > >
Re: [casper] strange problem in the FFT
Hi Glen The mirror_spectrum script was rewritten in commit 50416. I basically copied it exactly. The problem was that this was with a newer version of System Generator where the default latency was 0 for Relational blocks. So the generated logic was incorrect and I fixed this in commit b37f8d4. We figured out why eventually and then explicitly set the latencies for other Relational blocks. commit 504a6 would work if you were using an older version of System Generator. You can go in and change the latency to 1 and see the difference in the output (the error every 1/8th of a spectrum). I am pretty sure the current setup is correct but it might be some System Generator versions combined with some library versions do not work. Cheers Andrew 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 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
Re: [casper] Error Xilinx Block / ISE 10.1
Hi Wesley I'm using the following: Hardware IBOB/QUADC Software - Matlab/Simulink (R2007b) - Xilinx System Generator v10.1.3.1386 - Xilinx EDK v10.1.03 - Xilinx ISE v10.1.03 - MSSGE libraries ( https://github.com/ska-sa/mlib_devel/releases/tag/mlib_devel-2010-09-20) SG, EDK and ISE all updated What do you think? The Xilinx blocks error can be produced by the version of the CASPER libraries? Best Regards Rolando Paz 2013/10/25 Wesley New > Hi Rolando, > > What repository are you using? Assuming that you are targeting an ibob, > mlib_devel has a tag for last support of the ibob and bee2. Are you using > this? > > Wes > > Wesley New > South African SKA Project > +2721 506 7365 > www.ska.ac.za > > > > > On Thu, Oct 24, 2013 at 7:41 PM, Rolando Paz wrote: > >> Hi all. >> >> I achieved install a virtual machine windows XP SP3, on a machine with >> ubuntu 13.04. >> >> I install Matlab R2007b >> ISE, EDK, SG 10.1, with respective updates. >> >> By double clicking on any block of Xilinx, a get the following error. >> >> Can anyone help? >> >> Best Regards >> >> Rolando Paz >> > >
