Crazy cool finding for the Kria SOM: if you save the settings from simulation of another GTH capable Zynq MPSOC (Like say the ZCU104 or ZCU106), you can load the GTH on the Kria SOM with these settings via dynamic reconfiguration, and have it working without issue. The lagging problem I was having with my CoaXPress link was actually from the Basler camera, not the Kria SOM interface. Here is a short snippet of video of me getting CXP 12.5Gbps interface with GTH on Xilinx Kria SOM. The weird redness of the video is due to me not updating/setting gamma manually, and the Basler doing it automatically. Will most likely fix these settings in software when I get to the Ubuntu creation from source.

The steps to achieve the above are:

• Setup GTH transceiver in SIM and pull regbase for linerate above 10.3125Gbps
• In hardware, setup some trigger from AXI4 Lite interface to initiate this transfer
• ????
• Profit as we run at a linerate that Xilinx said was unsupported for the Kria SOM.

This is exciting for a multitude of reasons, the most important being that we surpassed what was considered the "max" speed that the Xilinx Kria K26Cs stated they can handle in the Vivado 2022.2 GUI. I had the stream stable overnight, so I'm not sure why they rate limited this interface. The work around is present for all enthusiasts that need the full bandwidth mentioned on Xilinx documentation.

On an also exciting note, I have gotten both MIPI interfaces tested working in a 2 lane implementation utilizing a barely changed project from @gtaylormb. Next step is to prove a 4 lane implementation with the IMX477 to completely prove out the Aper-Oculus's D-PHY supported capabilites. If I get some interest, I'll also release a DSI example design with a Raspberry Pi Touch Screen.

To blatantly state my modifications, I had no use for the TPG, and did not connect the enables to the VTC and AXI4S to Video Out since they are technically unnecessary. The I2C expansion channel, and address were also changed to ensure that they matched with the Aper-Oculus.

The fork that I used for single lane implementations can be found here to generate on your Aper-Oculus. More detailed instructions will come in a separate post, but the nuts and bolts include:

1. Create a new Vivado project
2. Source the block diagram script in the github, and copy in the xdc file
3. Compile and export hardware as an *.xsa
4. Launch Vitis, and create a workspace called 'SW' somewhere in your directory. Launch and create a platform project using *.xsa generated on step 3.
5.  and create the software project from the bitfile, using a platform project. Any of the IMX219 variants should work with @gtaylormb's code, but I specifically have this version.

Next is getting a PetaLinux build, and an Ubuntu build from source to support the Mali GPU on the board, and then finally SLVS-EC.