0x1f001e001d001c00 ... 01000000

Hey Aki, Correct regarding the X440. My block expects sc8 coming in through CHDR, but I made no other changes to the RFNoC core or to UHD itself regarding the data. Is this something I need to do? I tried finding all the places where ITEM_W was defined anywhere outside of my block but this still occurs. For the CHDR format, the lowest byte of the payload (i.e. the first byte of the payload as seen in wireshark) should also be the lowest byte in the payload as presented to my block, correct? Thanks, Brian On Fri, May 9, 2025 at 12:21 AM Tomita, Aki <Aki.Tomita@emerson.com> wrote: > Hi Brian, > > Just for background information, this is for the X440, like in your other > posts? Are you adding in the sc8 support in your custom image? Out of the > box, an sc8 for otw isn't supported for that device. There is FPGA code to > handle sc8, like the b2xx, but they're operating on the Legacy CHDR format. > > Aki > ------------------------------ > *From:* Brian Padalino <bpadalino@gmail.com> > *Sent:* Wednesday, May 7, 2025 8:04 PM > *To:* USRP-users@lists.ettus.com <usrp-users@lists.ettus.com> > *Subject:* [EXTERNAL] [USRP-users] RFNoC Payload Mismatch > > 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 >

 0x1f001e001d001c00 ... 01000000

We do actually communicate the data format to the SEP, and also provide an option to swap byte order if the host and device endianness differ. However, we expect that to be a rare occurrence because most archs are little endian these days, and so is the FPGA. That means the lowest byte in the payload is also the least significant byte of the first sample. However, you can check if something's going wrong (are we swapping bytes? Is the type correct?): https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/mgmt_portal.cpp#L415-L457 --M On Fri, May 9, 2025 at 2:29 PM Brian Padalino <bpadalino@gmail.com> wrote: > Hey Aki, > > Correct regarding the X440. My block expects sc8 coming in through CHDR, > but I made no other changes to the RFNoC core or to UHD itself regarding > the data. Is this something I need to do? > > I tried finding all the places where ITEM_W was defined anywhere outside > of my block but this still occurs. > > For the CHDR format, the lowest byte of the payload (i.e. the first byte > of the payload as seen in wireshark) should also be the lowest byte in the > payload as presented to my block, correct? > > Thanks, > Brian > > > On Fri, May 9, 2025 at 12:21 AM Tomita, Aki <Aki.Tomita@emerson.com> > wrote: > >> Hi Brian, >> >> Just for background information, this is for the X440, like in your other >> posts? Are you adding in the sc8 support in your custom image? Out of the >> box, an sc8 for otw isn't supported for that device. There is FPGA code to >> handle sc8, like the b2xx, but they're operating on the Legacy CHDR format. >> >> Aki >> ------------------------------ >> *From:* Brian Padalino <bpadalino@gmail.com> >> *Sent:* Wednesday, May 7, 2025 8:04 PM >> *To:* USRP-users@lists.ettus.com <usrp-users@lists.ettus.com> >> *Subject:* [EXTERNAL] [USRP-users] RFNoC Payload Mismatch >> >> 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-leave@lists.ettus.com >