Hi Dave
Thanks for sending your test model. Since it was saved using a newer Simulink version, I had to simulate it using a newer toolflow version.
Sorry about that.
Doing so did indeed show the FFT problem you described. I then re-simulated my test model in the newer Simulink version and it also showed the problem even though it simulated fine last Friday using an older version of the toolflow! I even re-simulated today using the older version and confirmed that it simulated fine. So it looks like the FFT bug you fixed is toolflow version specific. Yuck!
The confusion I have is that the bug is a logical error in the init script for the mirror_spectrum block. There is no way that the logic, if drawn as specified in the script, could produce logic that would give the correct output. There is also no way that data and sync could be aligned such that the output would be correct i.e some other block cannot be compensating.
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. 2. The xBlock system somehow switched latencies of Delay1 and Delay2, or got them wrong in a convenient fashion. 3. Maybe the logic was correct at some point, and the init script is never called from the mask when using the new toolflow (software triggering logic generation never runs maybe). Maybe the xBlock system has a significant change?
Could you check that the logic in mirror_spectrum generated by the old mirror_spectrum script matches the logic generated with the newer toolflow?
Regards Andrew
