Wincent_AlteraRegular ContributorJoined 4 years ago1277 Posts37 LikesLikes received70 SolutionsView All Badges
ContributionsMost RecentMost LikesSolutionsRe: Regarding the TX settings of MIPI CSI2 IP Hi STATEABC , Can you please check if you configured the CSI Tx control registers for each virtual channel in use - these must be configured at run-time, or the IP cannot produce an output. As a single-VC example from the loopback example design testbench: //0 width csi2_tx_control.master_write('h160, vvp_iip.Width + 1); //1 height_f0 csi2_tx_control.master_write('h170, vvp_iip.Height + 1); //2 height_f1 csi2_tx_control.master_write('h180, 0); //3 line_blanking csi2_tx_control.master_write('h190, LINE_BLANKING); //4 frame_blanking csi2_tx_control.master_write('h1A0, 2); //5 csi_ls_le_enabled | interlaced csi2_tx_control.master_write('h1B0, 'b10 | VC0_INTERLACED); The width and height registers take the exact pixel and line counts respectively (e.g. for full HD these would be 1920 and 1080). Line blanking specifies a blanking period between sending each video line. The simulation uses 64, but this may need to be higher for reliability, e.g. 200. Frame blanking specifies an inactive period between the end of one frame and start of the next. The simulation uses 2, but this may need to be higher for reliability, e.g. 25. The final control register has two active bits. [1] when set enables insertion of the optional line start and line end short packets. [0] enables interlaced video mode, so should be set to 0 for progressive video. CSI Rx does not require any configuration from a host. Hope this clarified, Let me know if you still unable to get it. Regards, Wincent_Altera Re: Regarding the TX settings of MIPI CSI2 IP Hi STATEABC , I would like to ask if there are any working examples of MIPI CSI2 TX that I can refer to? >> I check with our development team , but unfortunately we do not have at the moment. >> IF you business value is able to justify , I do suggest to go directly to Altera FAE to get this feature to be enable. >> At the moment the closer that we have is MIPI CSI-2 TX design example (without TPG) - but that only available for simulation purpose only >> you may get it via Quartus IP catalog >> Regards, Wincent Re: Regarding MIPI CSI 2 TX Hi Sai, If you looking at only simulation purpose, you may generate one from Quartus IP catalog There will have a testbench that you can try it out. Let me know if you unable get it. Regards, Wincent Re: Regarding the TX settings of MIPI CSI2 IP Hi STATEABC , Does this mean the input data resolution and the video stream's width and height are mismatched, resulting in no CSI2 TX output? >> Based on all the evidence you provided , it seen like yes to me as the CSI2 TX's axi stream tready signal ability is high - I assume the design is working well after your last modification >> If VC0_MODE_MATCH stays 0 after programming width/height and enabling the stream, the core is not recognizing the input as a valid, consistently framed video. >> Most implementations will not packetize or enter HS data transmission in that case, resulting in no CSI-2 output. What typically keeps VC0_MODE_MATCH at 0 Line framing mismatch - tlast not placed exactly at the end of each line (after “width” pixels). Format/packing mismatch - Incorrect bytes-per-pixel calculation vs. AXI data width (e.g., 24-bit pixels on 32/64-bit bus without correct packing). Wrong dimensions or units - Programming sequence: width/height set after enabling, not before. Perhaps you can check from those parameter. Regards, Wincent_Altera Re: Video Clock Output to SDI II in Agilex 5 Hi aucamera1 , I check with our design team - the VVP for GTS SDI II connection is available in newer release of Quartus v25.3.1. So that features is supported in v25.3.1 for GTS SDI II - Agilex 5. You just need to create a design based on Agilex 5 OPN number, By right the connection shall be ready there. Let me know if you still no getting it. Regards, Wincent Re: Regarding MIPI CSI 2 TX Hi Sai, There is a weird things to do if you just try the design via two IP. Because the MIPI design cross related with other IP as well such as ISP , Frame Buffer and other etc. To ensure its functionality and signal triggering. IF you just want to purely run the simulation - I suggest to generate one from the design example. You may get it from the IP catalog under Quartus. That could be a good start for you. Regards, Wincent Re: Regarding the TX settings of MIPI CSI2 IP Hi STATEABC , Initially the MIPI CSI2 TX axi stream ready signal remains low, and it doesn't process axi stream data from the TPG. After modification, CSI2 TX's axi stream tready signal ability is high, TPG->CSI2 TX's number is normal. >> Do you mind to share with me what change had been make to enable back the TX AXI signal ? >> Just wondering what could potential make the image lost However, this is also a new problem that has appeared, CSI2 T2X IP good image has been lost, but the reason is that the reason is that the signal tap is taken and the waveform is shown. >> Do you means in previously before modifying , when the MIPI CSI2 TX axi stream ready signal remains low, the image look good ? Sorry I am bit confuse , just trying to understand better the problem so that I can provide an accurate answer to your queries. Looking forward to hear back from you soon. Regards Wincent Re: Regarding the TX settings of MIPI CSI2 IP Hi, From your description and the SignalTap capture: AXI-Stream tready toward CSI-2 TX is now asserted “high ability” (i.e., backpressure looks cleared and TPG→CSI2 TX throughput is normal). Despite that, the CSI-2 TX IP no longer outputs a “good image.” The waveform shows HS word clocks toggling, but most of the CSI-2 TX control/status signals (e.g., word-valid, hs requests, lane enables) appear stuck low, and stop-state lines look static. That suggests the CSI-2 TX isn’t entering HS transmission, or packetization isn’t being triggered. Below are checks that typically isolate CSI-2 TX “no output” behaviors after AXI-side changes. There is few things I suggest to check First and the fastest way is to compare with the example design that I provided earlier. Else you may check the AXI-Stream side - ensure that it is match AXI input width to CSI-2 TX configured data width and pixel format. CSI-2 packetizer - Set correct data type (RAW/YUV/RGB) and virtual channel and heck status registers for underrun/overflow and frame/line detected. Resets/clocks - ensure the CDC/FIFO widths and enables correct. Regards, Wincent_Altera Re: Regarding MIPI CSI 2 TX Hi Sai, It is very hard for me to narrow down what doing wrong with such limited information. Plus that is custom design - I am not sure if there is another IP who can intercross the functionality of the signal. I would strongly suggest you to cross check with the design example itself and see what else is missing from your custom design vs the example design. That could give you better idea where is missing. Hope that work for you. Let me know if there is anything else you think I can better assist you Regards, Wincent_Altera Re: Regarding MIPI CSI 2 TX Hi Sai, May I know which design that you are using ? is it custom design or the design generated from the design example ? From your description, I understand that mipi_dphy_0/LINK0_CK_Stopstate stays high throughout simulation. AXI-Stream ready goes high briefly (three cycles) then deasserts and stays low. You’re sending test pattern data over AXI-Stream to MIPI CSI-2, which then connects to MIPI D-PHY (link_0). These symptoms typically indicate that the D-PHY high-speed (HS) clock lane never leaves Stop State, so the D-PHY never transitions to HS transmission, and upstream flow-control (through CSI-2 and AXI-Stream) stalls. AXI tready deasserting after a few cycles is consistent with small internal FIFOs filling while the downstream interface (D-PHY) is not transmitting. Based on the description - please check on proper resets, clocking, enabling continuous HS clock, and performing the required configuration writes in your simulation testbench. Once the D-PHY clock lane begins toggling HS, LINK0_CK_Stopstate should go low, and tready should remain asserted under normal flow. That could be a good start to check with. BUT that will be take time as it might be hard to narrow down the problem Quick way that I would recommended will be to compare your design with the our design example https://github.com/altera-fpga/agilex-ed-camera-ai That could help you to narrow down the problem faster if checking those parameter/ setting/ Regards, Wincent_Altera