The issue could be with the Window block then. Maybe it isn't getting
properly initialized or something changed from RFNoC 3 to RFNoC 4.

On Thu, Oct 15, 2020 at 3:44 PM Rob Kossler <[email protected]> wrote:

> OK. I'll check again.  One thing that's weird is that if I comment out
> either the Window or the FFT (and insert appropriate assign statements to
> replace the commented item), I don't get the error.  The error only occurs
> if both are in place.
> Rob
>
> On Thu, Oct 15, 2020 at 3:42 PM Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hey Rob,
>>
>> I've ran into that issue when simulating Xilinx IP that use DSP48s. From
>> what I can tell, they don't handle X and U signal states properly. Try
>> double checking that all your signals are all properly driven.
>>
>> Jonathon
>>
>> On Thu, Oct 15, 2020, 15:08 Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>> I am getting this error (from the subject line) in a custom block I
>>> created that is effectively just the combination of a window block and a
>>> xilinx fft ip core. I am using UHD-4.0 (and Vivado 2019.1).
>>>
>>> After searching the user's list, I found some old posts from Jonathan
>>> Pendlum that indicated that this was a known issue related to the Xilinx
>>> FFT IP core.  The solution in the previous posts was to copy a "wave.do"
>>> file from the Ettus in-tree FFT tb folder.  I didn't find such a file in
>>> UHD-4.0 and so I'm wondering if there is a solution that works for UHD-4.0.
>>> Rob
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to