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 <[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
