Hi Ken, There is no completely trivial way to do this. I think the most complete bypass you can get is to expose the PS GEM interface FIFOs to the PL and then wire up the PL 1GbE output to these ports on the MPSoC block in IP Integrator. I have streamed data through a PS 1GbE port like this before (though not within the CASPER build environment), and I have some slightly modified versions of the CASPER 1GbE block so that it can interface with the GEM FIFOs. I started trying to merge this work into mlib_devel -- https://gitlab.com/realtimeradio/casper/mlib_devel/-/commit/a0075e13ded1ac24a6feb5f8310eaba17ce0757b -- in such a way that if you dropped down a 1GbE block on the 4x2 it would automatically do the right thing. Then I moved on to simply pulling the data through the PS because that was fast enough for my purposes. There are a fair few knock on effects to deal with in supporting the fifo interface -- eg, the core has a wishbone, not axi interface, so you have to bundle that conversion in somewhere and deal with the wishbone address management. All doable, but the devil is in the details. If you wanted to continue this work that'd be great, and I'd be very happy to walk you through what I've done. Full disclosure, I've no idea what the interplay is when you want to use the 1GbE port via the FIFO interface but also want the Linux IP stack to use it. Maybe it will just work, or maybe it will be disastrous. I suppose if you were desperate, you could use the PS 1GbE to stream data and then use a USB RJ45 dongle for the PS control.
Cheers Jack On Tue, 25 Nov 2025 at 19:20, Ken Semanov <[email protected]> wrote: > Hello Jack, > > Thank you for the help. I had a short question about this. In > principle, is it possible to have the FPGA fabric talk directly to the RJ45 > ethernet port on a RFSoC4x2, bypassing the PS side completely? > > On Monday, November 10, 2025 at 6:51:11 AM UTC-5 Jack Hickish wrote: > >> Hi Ken, >> >> I believe this is (or is close to) supported if you are using a QSFP -> >> SFP adapter to send 1GbE out the QSFP port. If it compiles without error, >> it's probably supported. >> If you're expecting the block to utilise the RJ45 port to which the PS is >> connected then this won't work (though I did a bit of work recently >> thinking about supporting this which I can point you to in case it is >> useful) >> >> Cheers >> Jack >> >> On Fri, 7 Nov 2025 at 22:29, Ken Semanov <[email protected]> wrote: >> >>> We are going to attempt to use the one_gbe block with an RFSoC4x2. >>> >>> Is this board supported? Should we modify anything in the platform >>> yaml for the board? Are there any other changes we should consider before >>> compiling, or during deploy, regarding clocking or constraints? Thank >>> you. >>> >>> >>> -- >>> 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 visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/da9b6537-a80f-417d-b108-973438893356n%40lists.berkeley.edu >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/da9b6537-a80f-417d-b108-973438893356n%40lists.berkeley.edu?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 visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmRRvK%2BzpdP8HTODnosXupxy1XDJTG_DKOhpzjsRK4oag%40mail.gmail.com.
