Jonathon (and all), This error message has returned as I'm working with a Xilinx FFT IP core again. I never solved it previously and I cannot seem to solve it now. The error shows up during the 1st testbench test (Flush/Reset) as shown below.
======================================================== TESTBENCH STARTED: rfnoc_block_xfft_256_tb ======================================================== [TEST CASE 1] (t = 0 ns) BEGIN: Flush block then reset it... *Failure: ERROR:add_1 must be in range [-1,DEPTH-1]* Time: 16 ns Iteration: 1 After researching this error, it seems that solutions fall in two categories. First, something to do with clock initializations related to IP cores. Second, having any uninitialized inputs to an IP core. I played around with the testbench clocks with no success. I also verified my inputs to the FFT instance. I don't see any problem. I created a simple project to produce this error using the following steps: - copied "rfnoc-example" folder out of tree (UHD-4.1) and verified that I could create a build folder and run cmake & "make rfnoc_block_gain_tb" successfully (I changed the target to E310 so that it could be run with the Vivado 2019.1 Webpack version) - created a Xilinx FFT IP core xci file "xfft_256.xci" (see attached) to implement a 256 pt pipelined, resizable FFT - created a new rfnoc block definition xml file "xfft_256.xml" (see attached) and then ran rfnoc_create_verilog.py to create the boilerplate rfnoc Verilog & Testbench files - ran the testbench with no modifications: SUCCESS - modified only rfnoc_block_xfft_256.v (see attached) to add the FFT IP instance and modified the make/cmake process to locate & build the IP (using the similar modifications needed in the gain example to include a complex_multiplier IP) - ran the testbench: FAILURE (see above) I have attached to this email the 3 relevant files: xfft_256.xci, xfft_256.xml (rfnoc block definition file), and rfnoc_block_xfft_256.v (modified rfnoc Verilog code with added instance to FFT). The other files needed to reproduce this (such as the testbench) can be auto-generated since I didn't modify them (but I would be happy to provide mine if helpful). All my other changes were to the cmake/make files, and these changes just follow the gain example (but I would be happy to provide them and/or the full OOT directory if helpful). Let me know if you have any suggestions or if you are able/unable to duplicate the issue with the files provided. Rob On Thu, Oct 15, 2020 at 6:16 PM Rob Kossler <rkoss...@nd.edu> wrote: > I'm just using window.v, not the various noc block wrappers. I don't see > any issue with it and when I run the testbench with just the Window enabled > (and FFT IP core disabled), it works fine. > > I'm really struggling with this. The results are bizarre and the > testbench takes forever to run (ok, maybe 5 min) so it is not simple to > change 1 thing and check the result. I can't seem to find any issue with > failing to drive inputs of the FFT core. I've searched the web on this > error and the most common response does indicate a failure to drive inputs, > but I can't find any culprit. > > Could it have anything to do with something like a race condition prior to > the first clock cycle? Or is that just nonsense. I definitely don't have > the experience to even know if that is a possibility. > Rob > > > On Thu, Oct 15, 2020 at 4:23 PM Jonathon Pendlum < > jonathon.pend...@ettus.com> wrote: > >> 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 <rkoss...@nd.edu> 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 < >>> jonathon.pend...@ettus.com> 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 < >>>> usrp-users@lists.ettus.com> 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 >>>>> USRP-users@lists.ettus.com >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>
xfft_256.yml
Description: application/yaml
xfft_256.xci
Description: Binary data
//
// Copyright 2022 Ettus Research, a National Instruments Brand
//
// SPDX-License-Identifier: LGPL-3.0-or-later
//
// Module: rfnoc_block_xfft_256
//
// Description:
//
// <Add block description here>
//
// Parameters:
//
// THIS_PORTID : Control crossbar port to which this block is connected
// CHDR_W : AXIS-CHDR data bus width
// MTU : Maximum transmission unit (i.e., maximum packet size in
// CHDR words is 2**MTU).
//
`default_nettype none
module rfnoc_block_xfft_256 #(
parameter [9:0] THIS_PORTID = 10'd0,
parameter CHDR_W = 64,
parameter [5:0] MTU = 10
)(
// RFNoC Framework Clocks and Resets
input wire rfnoc_chdr_clk,
input wire rfnoc_ctrl_clk,
input wire ce_clk,
// RFNoC Backend Interface
input wire [511:0] rfnoc_core_config,
output wire [511:0] rfnoc_core_status,
// AXIS-CHDR Input Ports (from framework)
input wire [(1)*CHDR_W-1:0] s_rfnoc_chdr_tdata,
input wire [(1)-1:0] s_rfnoc_chdr_tlast,
input wire [(1)-1:0] s_rfnoc_chdr_tvalid,
output wire [(1)-1:0] s_rfnoc_chdr_tready,
// AXIS-CHDR Output Ports (to framework)
output wire [(1)*CHDR_W-1:0] m_rfnoc_chdr_tdata,
output wire [(1)-1:0] m_rfnoc_chdr_tlast,
output wire [(1)-1:0] m_rfnoc_chdr_tvalid,
input wire [(1)-1:0] m_rfnoc_chdr_tready,
// AXIS-Ctrl Input Port (from framework)
input wire [31:0] s_rfnoc_ctrl_tdata,
input wire s_rfnoc_ctrl_tlast,
input wire s_rfnoc_ctrl_tvalid,
output wire s_rfnoc_ctrl_tready,
// AXIS-Ctrl Output Port (to framework)
output wire [31:0] m_rfnoc_ctrl_tdata,
output wire m_rfnoc_ctrl_tlast,
output wire m_rfnoc_ctrl_tvalid,
input wire m_rfnoc_ctrl_tready
);
//---------------------------------------------------------------------------
// Signal Declarations
//---------------------------------------------------------------------------
// Clocks and Resets
wire ctrlport_clk;
wire ctrlport_rst;
wire axis_data_clk;
wire axis_data_rst;
// CtrlPort Master
wire m_ctrlport_req_wr;
wire m_ctrlport_req_rd;
wire [19:0] m_ctrlport_req_addr;
wire [31:0] m_ctrlport_req_data;
wire m_ctrlport_resp_ack;
wire [31:0] m_ctrlport_resp_data;
// Data Stream to User Logic: in
wire [32*1-1:0] m_in_axis_tdata;
wire [1-1:0] m_in_axis_tkeep;
wire m_in_axis_tlast;
wire m_in_axis_tvalid;
wire m_in_axis_tready;
wire [63:0] m_in_axis_ttimestamp;
wire m_in_axis_thas_time;
wire [15:0] m_in_axis_tlength;
wire m_in_axis_teov;
wire m_in_axis_teob;
// Data Stream from User Logic: out
wire [32*1-1:0] s_out_axis_tdata;
wire [0:0] s_out_axis_tkeep;
wire s_out_axis_tlast;
wire s_out_axis_tvalid;
wire s_out_axis_tready;
wire [63:0] s_out_axis_ttimestamp;
wire s_out_axis_thas_time;
wire [15:0] s_out_axis_tlength;
wire s_out_axis_teov;
wire s_out_axis_teob;
//---------------------------------------------------------------------------
// NoC Shell
//---------------------------------------------------------------------------
noc_shell_xfft_256 #(
.CHDR_W (CHDR_W),
.THIS_PORTID (THIS_PORTID),
.MTU (MTU)
) noc_shell_xfft_256_i (
//---------------------
// Framework Interface
//---------------------
// Clock Inputs
.rfnoc_chdr_clk (rfnoc_chdr_clk),
.rfnoc_ctrl_clk (rfnoc_ctrl_clk),
.ce_clk (ce_clk),
// Reset Outputs
.rfnoc_chdr_rst (),
.rfnoc_ctrl_rst (),
.ce_rst (),
// RFNoC Backend Interface
.rfnoc_core_config (rfnoc_core_config),
.rfnoc_core_status (rfnoc_core_status),
// CHDR Input Ports (from framework)
.s_rfnoc_chdr_tdata (s_rfnoc_chdr_tdata),
.s_rfnoc_chdr_tlast (s_rfnoc_chdr_tlast),
.s_rfnoc_chdr_tvalid (s_rfnoc_chdr_tvalid),
.s_rfnoc_chdr_tready (s_rfnoc_chdr_tready),
// CHDR Output Ports (to framework)
.m_rfnoc_chdr_tdata (m_rfnoc_chdr_tdata),
.m_rfnoc_chdr_tlast (m_rfnoc_chdr_tlast),
.m_rfnoc_chdr_tvalid (m_rfnoc_chdr_tvalid),
.m_rfnoc_chdr_tready (m_rfnoc_chdr_tready),
// AXIS-Ctrl Input Port (from framework)
.s_rfnoc_ctrl_tdata (s_rfnoc_ctrl_tdata),
.s_rfnoc_ctrl_tlast (s_rfnoc_ctrl_tlast),
.s_rfnoc_ctrl_tvalid (s_rfnoc_ctrl_tvalid),
.s_rfnoc_ctrl_tready (s_rfnoc_ctrl_tready),
// AXIS-Ctrl Output Port (to framework)
.m_rfnoc_ctrl_tdata (m_rfnoc_ctrl_tdata),
.m_rfnoc_ctrl_tlast (m_rfnoc_ctrl_tlast),
.m_rfnoc_ctrl_tvalid (m_rfnoc_ctrl_tvalid),
.m_rfnoc_ctrl_tready (m_rfnoc_ctrl_tready),
//---------------------
// Client Interface
//---------------------
// CtrlPort Clock and Reset
.ctrlport_clk (ctrlport_clk),
.ctrlport_rst (ctrlport_rst),
// CtrlPort Master
.m_ctrlport_req_wr (m_ctrlport_req_wr),
.m_ctrlport_req_rd (m_ctrlport_req_rd),
.m_ctrlport_req_addr (m_ctrlport_req_addr),
.m_ctrlport_req_data (m_ctrlport_req_data),
.m_ctrlport_resp_ack (m_ctrlport_resp_ack),
.m_ctrlport_resp_data (m_ctrlport_resp_data),
// AXI-Stream Clock and Reset
.axis_data_clk (axis_data_clk),
.axis_data_rst (axis_data_rst),
// Data Stream to User Logic: in
.m_in_axis_tdata (m_in_axis_tdata),
.m_in_axis_tkeep (m_in_axis_tkeep),
.m_in_axis_tlast (m_in_axis_tlast),
.m_in_axis_tvalid (m_in_axis_tvalid),
.m_in_axis_tready (m_in_axis_tready),
.m_in_axis_ttimestamp (m_in_axis_ttimestamp),
.m_in_axis_thas_time (m_in_axis_thas_time),
.m_in_axis_tlength (m_in_axis_tlength),
.m_in_axis_teov (m_in_axis_teov),
.m_in_axis_teob (m_in_axis_teob),
// Data Stream from User Logic: out
.s_out_axis_tdata (s_out_axis_tdata),
.s_out_axis_tkeep (s_out_axis_tkeep),
.s_out_axis_tlast (s_out_axis_tlast),
.s_out_axis_tvalid (s_out_axis_tvalid),
.s_out_axis_tready (s_out_axis_tready),
.s_out_axis_ttimestamp (s_out_axis_ttimestamp),
.s_out_axis_thas_time (s_out_axis_thas_time),
.s_out_axis_tlength (s_out_axis_tlength),
.s_out_axis_teov (s_out_axis_teov),
.s_out_axis_teob (s_out_axis_teob)
);
//---------------------------------------------------------------------------
// User Logic
//---------------------------------------------------------------------------
wire [23:0] fft_config_tdata = 24'd64;
wire fft_config_tready;
reg fft_config_tvalid;
always @(posedge axis_data_clk) begin
if (axis_data_rst) fft_config_tvalid <= 1'b1;
else if (fft_config_tvalid & fft_config_tready) fft_config_tvalid <= 1'b0;
end
wire [7:0] fft_status_tdata;
wire fft_status_tvalid;
wire fft_status_tready = 1'b1;
wire event_frame_started;
wire event_tlast_unexpected;
wire event_tlast_missing;
wire event_fft_overflow;
wire event_status_channel_halt;
wire event_data_in_channel_halt;
wire event_data_out_channel_halt;
wire [7:0] fft_out_tuser;
// this is copied from the Xilinx .veo template
xfft_256 inst_xfft (
.aclk(axis_data_clk), // input wire aclk
.aresetn(~axis_data_rst), // input wire aresetn
.s_axis_config_tdata(fft_config_tdata), // input wire [23 : 0] s_axis_config_tdata
.s_axis_config_tvalid(fft_config_tvalid), // input wire s_axis_config_tvalid
.s_axis_config_tready(fft_config_tready), // output wire s_axis_config_tready
.s_axis_data_tdata(m_in_axis_tdata), // input wire [31 : 0] s_axis_data_tdata
.s_axis_data_tvalid(m_in_axis_tvalid), // input wire s_axis_data_tvalid
.s_axis_data_tready(m_in_axis_tready), // output wire s_axis_data_tready
.s_axis_data_tlast(m_in_axis_tlast), // input wire s_axis_data_tlast
.m_axis_data_tdata(s_out_axis_tdata), // output wire [31 : 0] m_axis_data_tdata
.m_axis_data_tuser(fft_out_tuser), // output wire [7 : 0] m_axis_data_tuser
.m_axis_data_tvalid(s_out_axis_tvalid), // output wire m_axis_data_tvalid
.m_axis_data_tready(s_out_axis_tready), // input wire m_axis_data_tready
.m_axis_data_tlast(s_out_axis_tlast), // output wire m_axis_data_tlast
.m_axis_status_tdata(fft_status_tdata), // output wire [7 : 0] m_axis_status_tdata
.m_axis_status_tvalid(fft_status_tvalid), // output wire m_axis_status_tvalid
.m_axis_status_tready(fft_status_tready), // input wire m_axis_status_tready
.event_frame_started(event_frame_started), // output wire event_frame_started
.event_tlast_unexpected(event_tlast_unexpected), // output wire event_tlast_unexpected
.event_tlast_missing(event_tlast_missing), // output wire event_tlast_missing
.event_fft_overflow(event_fft_overflow), // output wire event_fft_overflow
.event_status_channel_halt(event_status_channel_halt), // output wire event_status_channel_halt
.event_data_in_channel_halt(event_data_in_channel_halt), // output wire event_data_in_channel_halt
.event_data_out_channel_halt(event_data_out_channel_halt) // output wire event_data_out_channel_halt
);
// Nothing to do yet, so just drive control signals to default values
assign m_ctrlport_resp_ack = 1'b0;
assign m_in_axis_tready = 1'b0;
assign s_out_axis_tvalid = 1'b0;
endmodule // rfnoc_block_xfft_256
`default_nettype wire
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
