Hi Samuel > However, when I combine the two parts (linking the coarse_delay to the > pfb_fir_real block, the simulation fails at the 163rd clock. > Specifically, one single convert_of block in the twiddle block deep in > the fft_wideband_real gets an indeterminate value, and various plots > from scopes don't show anything wrong other than the data flow just > stopping. I've worked on this for a while now and I am now seeking any > advice the group may have. >
Thanks for the good description of the problem. I have seen something similar. Basically, a design using the delay_wideband_prog block builds (and works) fine but causes an error during simulation with an indeterminate value error. I am assuming that you are using this block or something similar. Basically, the RAMs in delay_wideband_prog are generating an undefined value during or just after reset. This value is propagating and does not cause an error when manipulated (added etc) (more undefined values are generated). When it encounters a circuit that uses it in logic (comparison etc) it causes an error. This is why it only triggers the error way further on (and later) in the FFT and not at all in a simple simulation. If you look carefully at your scopes you may see a 'hole' in the data - this is the undefined value. To fix this, go into the delay_wideband_prog block and into the delay_dp blocks. In the mask of the Dual Port RAM blocks, under the Advanced tab, change Write Modes to Read before Write for port A. Alternatively, use Single Port in 'Select type of BRAM' on the top-level mask. I am not exactly sure of the error mechanism here. We are actually reading values from port B and don't feed data back into port A so write mode on port A should not matter...? This will be fixed in the libraries at some point. Compiling with Dual Port is fine and using the Single Port BRAM option works for simulation and compilation. Regards Andrew
