I've got a custom image with CHDR_W=512 and I am using sc8 for both the otw
and cpu formats. In my FPGA simulation, I set the ChdrData with 512 for the
CHDR_W and 16 for the ITEM_W. I am loading a counting pattern with the real
part being incremented every sample, and the imaginary incrementing every
128 samples. In simulation, the 512-bits coming out at the end are:
0x1f001e001d001c00 ... 01000000
In wireshark captures, the Payload shows this counting pattern going up: 00
00 00 01 00 02 00 03 ... as I would also expect.
The ILA shows me a strange swizzle going on the 512-bit bus:
0x010000000300020005000400 ... 1f001e00
It appears like it thinks data items might be 32-bits wide (16-bit I and
16-bit Q) and it's also backwards on the bus (first sample in the ethernet
packet is the upper most sample in the CHDR bus). I am using the
chdr_to_axis_pyld_ctxt with CHDR_W set to 512, ITEM_W set to 16, but the
NIPC is just 512/16 so it's the full 512-in, 512-out - no width translation
there. Also note that the context is perfect - it's just the payload that
is strange.
For the life of me, I can't see where the misconfiguration might be
occurring. As I said, my simulation with the testbench for my block pushes
a counting pattern to a queue of item_t, then I use item_to_chdr() to pack
it and give it to the CHDR BFM. I'd really like to be able to simulate what
might be going on but I am hesitant to try and include the ethernet
transport adapter into my block testbench.
Any pointers on what this might be? Does the wireshark ethernet packet
description sound correct to you for the payload? The lowest bytes in the
ethernet packet should show up as the lowest bytes on the payload bus?
Thanks,
Brian
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
