I think that there are 2 places where byte ordering occurs: in the FPGA at the Streaming Endpoint (SEP) and in UHD with a particular converter. Assuming a 64-bit CHDR word coming into the SEP, the SEP orders the bytes according to what it thinks the "item" size is (I really don't know how it knows the item size or if/how you can configure it differently). But, in any case, if the SEP thinks that the item size is 4 bytes, it will order the bytes by MSB in order to send across the link (e.g., Ethernet). If the CHDR width is 8 bytes and the item size is 4 bytes, I'm not sure if the SEP will send the lower "item" first or the upper "item" first.
On the UHD side, it will assume an item type based on the rx streamer OTW setting (e.g., "sc16") and will swap bytes if needed for a little endian host. (I do not know if the OTW setting affects the behavior of the SEP on the FPGA but perhaps it does.) Until I understand things better, I have resigned myself to having to assume that both the FPGA and UHD will treat my bytes as an sc16 such that I have to pre-arrange and/or post-arrange any manipulations performed by the SEP and UHD converter. This is not very convenient. Rob On Tue, Mar 14, 2023 at 12:10 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 14/03/2023 10:27, Vermeulen, Bas (Consultant) wrote: > > The problem isn't so much the byteswapping in the int16, but the int16's > being swapped. > > I am sending SC16's (I0 Q0 I1 Q1 I2 Q2 I3 Q3), and expect to receive the > 16 bit values in the same order (Val0 Val1 Val2 Val3). > When using sc8's, I got (I3 Q3 I2 Q2 I1 Q1 I0 Q0) which I didn't expect at > all. > > Regards, > > Bas Vermeulen > > Like i pointed out earlier, X310 doesn't support SC8 data, so I have no > idea what it will do if you try to "force" the issue. > > > ------------------------------ > *From:* Marcus D. Leech <patchvonbr...@gmail.com> > <patchvonbr...@gmail.com> > *Sent:* Wednesday, March 8, 2023 8:46 PM > *To:* Rob Kossler <rkoss...@nd.edu> <rkoss...@nd.edu> > *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> > <usrp-users@lists.ettus.com> > *Subject:* [USRP-users] Re: RFNOC module sending back (or receiving) data > in the wrong order > > Sent by an external sender > ------------------------------ > On 08/03/2023 14:41, Rob Kossler wrote: > > Agreed, but it doesn't seem too much to expect that UHD should natively > supply a "non-swapping" converter so that each user who needs one doesn't > have to develop it. > Rob > > In this case, the RFNOC code is kinda pretending that it's sending int16 > integers, but the actual semantic is somewhat different. > So a non-swapping converter would happen to work in this case, but it's > kind of subverting the "object model" a bit. > > Perhaps some kind of "raw" converter in which there's no implied object > semantics. > > > On Wed, Mar 8, 2023 at 1:45 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > > On 08/03/2023 13:36, Rob Kossler wrote: > > Oh yeah, I forgot. Does this imply that there is no way to keep UHD from > swapping bytes in an rx_streamer (using X310)? If so, this seems like a > problem for RFNoC development since the data coming across the wire can be > in any format the designer chooses. And, swapping in the FPGA is not a > good solution because you don't know the Endianness of the host. > Rob > > The "doctrine" has been to represent data types in their "natural > network-byte-order" on the wire, and the host code > can do whatever it needs to do. This is consistent with practice in > nearly-all other disciplines that send data over > the network (whether that's the Internet or other ethernet networks, > etc). > > For little-endian hosts, UHD has to do the swap. > > But UHD allows you to register your own converter methods. I've never > done it myself, but I don't think it's that hard. > > > > On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > > On 08/03/2023 11:42, Rob Kossler wrote: > > Maybe can you just change the streamer OTW & CPU format to "sc8" such that > no byte swapping will occur? > > I know that on the default X3xx builds, there's no sc8 format implemented > on the USRP end. > > > > On Tue, Mar 7, 2023 at 10:31 PM Wade Fife <wade.f...@ettus.com> wrote: > > You could swap the bytes in your block, or swap them in software on the > host. The data gets rearranged by the streamer depending on the data type > configured (e.g., sc16) and the endianness of the host machine. > > Wade > > On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Hi, > > We are developing an RFNOC module that takes I/Q data, and turns that into > two 8 bit values. > I have a test program that sends data to the RFNOC module, and receives > the modified data. > > The RFNOC module treats the two 8 bit values as one signed 16 bit value. > When I read the data from the test program, I get it in the wrong order: > > Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3 > Receive: Val1 Val0 Val3 Val2 > > Does anyone have any idea how to fix the order of the received values? > > Regards, > > Bas Vermeulen > > ------------------------------ > > > > CONFIDENTIALITY NOTICE: This message (including any attachments) may > contain Molex confidential information, protected by law. If this message > is confidential, forwarding it to individuals, other than those with a need > to know, without the permission of the sender, is prohibited. > > This message is also intended for a specific individual. If you are not > the intended recipient, you should delete this message and are hereby > notified that any disclosure, copying, or distribution of this message or > taking of any action based upon it, is strictly prohibited. > > English | Chinese | Japanese > www.molex.com/confidentiality.html > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > > > ------------------------------ > > > > CONFIDENTIALITY NOTICE: This message (including any attachments) may > contain Molex confidential information, protected by law. If this message > is confidential, forwarding it to individuals, other than those with a need > to know, without the permission of the sender, is prohibited. > > This message is also intended for a specific individual. If you are not > the intended recipient, you should delete this message and are hereby > notified that any disclosure, copying, or distribution of this message or > taking of any action based upon it, is strictly prohibited. > > English | Chinese | Japanese > www.molex.com/confidentiality.html > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
