Hello Nitish, So I'm going to play devil's advocate and say that while you could do the byte swapping in the FPGA, it would be morally wrong ;-)
Ideally, all data that goes out on a network will be network order, and you use the ntohl or htohs functions to get it in host format. That way the code stays more portable - if you one day find yourself on a big-endian system, it would work without modification. (https://en.wikipedia.org/wiki/Endianness#Networking) Sometimes for performance reasons you may have to make these kinds of compromises, and if you do you should document them well! But most modern servers should have no issue with 10Gb/s datarates. You could probably even do the swaps in the GPUs using Nvidia's primitives. Regards, James On Tue, Aug 18, 2020 at 1:28 PM Nitish Ragoomundun < [email protected]> wrote: > Hi, > > Thanks a lot Jack. It makes sense. > And thank you very much for the note on the 2x32-bit pair. It is exactly > how our data is formatted. > Ok, we will go with an FPGA correction instead of a CPU byteswap. I am > guessing it will be faster this way. > > Thanks again. > Cheers > Nitish > > > On Tue, Aug 18, 2020 at 4:47 PM Jack Hickish <[email protected]> > wrote: > >> Hi Nitish, >> >> To try and answer your first question without adding confusion -- >> >> If you send a UFix64_0 value into the 10GbE block, you will need to >> interpret it on the other end via an appropriate 64-bit byte swap if your >> CPU is little-endian. >> If you send a 64-bit input into the 10GbE block where the most >> significant 32 bits are the value A, and the least significant bits are >> value B, you should interpret the 64-bits on your little endian CPU as the >> struct >> >> typedef struct pkt { >> uint32_t A; >> uint32_t B; >> } pkt; >> >> where each of the A and B will need byteswapping before you use them. >> >> To answer your second question -- >> Yes, you can absolutely flip the endianness on the FPGA prior to >> transmission so you don't have to byteswap on your CPU. You can either do >> this with a bus-expand + bus-create blocks, using the first to split your >> words into bytes, and then flipping them before concatenating. The Xilinx >> "bitbasher" block would also be good for this, using the Verilog (for a >> 64-bit input): >> >> out = {in[7:0], in[15:8], in[23:16], in[31:24], in[39:32], in[47:40], >> in[55:48], in[63:48]} >> >> If your 64 bit data streams are not made up of 64-bit integers (eg, they >> are pairs of 32-bit integers) then you should flip the 4 bytes of each >> value individually, but leave the ordering of the two values within the 64 >> bits unchanged. >> >> Hopefully that makes sense.... >> >> Jack >> >> >> On Tue, 18 Aug 2020 at 13:28, Nitish Ragoomundun < >> [email protected]> wrote: >> >>> >>> Hello, >>> >>> We are setting up the digital back-end of a low-frequency telescope >>> consisting of SNAP boards and GPUs. The SNAP boards packetize the data and >>> send to the GPU processing nodes via 10 GbE links. We are currently >>> programming the packetizer/depacketizer. >>> I have a few questions about the 10gbe yellow blocks and endianness. We >>> observed from the tutorials that the data stored in bram is big-endian. I >>> would like to know how the data is handled by the 10gbe and in what form is >>> it sent over the network. >>> Our depacketizers run on Intel processors, which are little-endian. We >>> are aware that network byte order is big-endian, but we noticed that >>> integer data can be sent from one Intel machine to another via network >>> without ever calling ntohl( ) or htonl( ) and the data was preserved. So, >>> we would like to know if we need to correct the endianness when receiving >>> the data from the SNAP. >>> >>> If we need to perform this correction, is there a way we could possibly >>> correct the endianness on the FPGA itself before input to the 10gbe block? >>> >>> Thanks, >>> Nitish >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cOZhVBUvUfs1phQ2csuRnewowZkQ8PzjjBU62LUa0js%3Dw%40mail.gmail.com >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cOZhVBUvUfs1phQ2csuRnewowZkQ8PzjjBU62LUa0js%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSkaEebTXH0X6xiDt6DLHiEy7WUW5xb%3D7w%2BYUJHB3GB7-w%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSkaEebTXH0X6xiDt6DLHiEy7WUW5xb%3D7w%2BYUJHB3GB7-w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cMNM0hC1oOwq3mHT%3DO8teO_MGKy9sjUnbKC2fJH2yNUPg%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cMNM0hC1oOwq3mHT%3DO8teO_MGKy9sjUnbKC2fJH2yNUPg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D365VFetwDP%2BX80xn%2BuNmf11BTGfK3jia2%3DEOiX%3Ds1VfBw%40mail.gmail.com.
