Hi Wade, Thanks, that has made things a lot clearer now! (I see context header manipulations being done in other rfnoc blocks, of which I hadn't realized the importance.)
Regards, Kevin On Wed, 28 Sept 2022 at 21:11, Wade Fife <[email protected]> wrote: > Hi Kevin, > > The BFM for CHDR does some checks to make sure packets are formatted > correctly. The error message means the "Length" field in the CHDR header > doesn't match the length of the AXI-Stream packet. > > The chdr_to_item call is giving a warning because it's expecting a > multiple of 32-bits (ITEM_W = 32, or 4 bytes per item) but num_bytes is not > a multiple of 4. > > Wade > > On Wed, Sep 28, 2022 at 5:24 AM Kevin Williams <[email protected]> wrote: > >> Hi Guys, >> >> What does the following mean? >> >> I am getting packets sent to an IP core I generated, and this is the >> result of a blk_ctrl.recv_items() in my testbench. >> >> The first few packets are correct. >> >> I can see that 64-bit CHDR words are correctly unpacked, and 2 x 16-bit >> I/Q samples are injected into the core, and vice-versa, which leads me to >> believe I have the buses mapped correctly etc. >> >> Regards, Kevin >> >> >> Error: ChdrPacket::axis_to_chdr: Incorrect CHDR length >> >> Time: 2445 ns Iteration: 0 Process: >> /PkgChdrBfm/ChdrBfm(CHDR_W=64,USER_WIDTH=1)::get_chdr File: >> /home/kwilliams/rfnoc/uhd/fpga/usrp3/sim/rfnoc/PkgChdrBfm.sv >> >> Warning: ChdrData::chdr_to_item: num_bytes is not a multiple of items >> >> Time: 2445 ns Iteration: 0 Process: >> /PkgChdrIfaceBfm/ChdrIfaceBfm(CHDR_W=64,ITEM_W=32)::recv_items File: >> /home/kwilliams/rfnoc/uhd/fpga/usrp3/sim/rfnoc/PkgChdrIfaceBfm.sv >> >> -- >> Kevin Williams >> _______________________________________________ >> USRP-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- Kevin Williams
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
