User Profile
Wincent_Altera
Regular ContributorJoined 5 years ago
User Widgets
Contributions
Re: VVP Protocol Converter Not work
Hi JLee25 , From your screenshots, the selected conversion direction looks correct for Altera Streaming Video Lite to Avalon Streaming Video, and your software is writing width, height, interlace, color settings, and the start bit. The biggest thing that stands out is that the GUI screenshot shows Memory mapped control interface not enabled, while your software is writing Protocol Converter registers through the base address. In the user guide Document: Video and Vision Processing Suite IP User Guide (UG-20344 | 2026.03.03) Section: 7.5 Protocol Converter IP Registers , access to the register map requires the Avalon memory-mapped control interface to be turned on. If the screenshot matches the actual compiled instance, that is the first thing I would check. Also, for the Lite-to-Avalon direction, the converter needs CPU-side frame information because AXI4-Stream video does not carry the geometry metadata needed on that side. The documented registers for Lite input are width, height, and interlace, which is consistent with what you are trying to program. From the waveform, av_st_vid_out_ready is high and axi4s_vid_in_tvalid is high, but av_st_vid_out_valid remains low and axi4s_vid_in_tready remains low. That suggests the downstream side is ready, but the converter itself is not accepting the incoming stream yet. I would suggest checking the following: Confirm the compiled IP really has the Avalon-MM control interface enabled. If not, the register writes may not actually control the core. Read back the status/debug registers and confirm the core reports running, has received a field, and whether the last field was marked broken. Verify the programmed frame info exactly matches the incoming stream: 3840 x 2160 and the correct interlace value. Verify the color-format settings. Your GUI shows YCbCr 4:4:4 color swap enabled, and the guide notes that the converter may swap Y and Cr planes for YCbCr 4:4:4 depending on the selected color-space/chroma settings. If your actual source is RGB or a different YCbCr format, the settings may not match the stream. Check that the AXI4-S Lite source is producing correct frame-boundary signaling consistently, since the converter should not keep tready low once configuration and format are valid. My first suspicion is the control-interface setting mismatch between the GUI and the software access path. My second suspicion is a stream-format mismatch, especially around the YCbCr 4:4:4 swap and color-format assumptions. So in short, this does not look like downstream backpressure. It looks more like the converter is not becoming operational because either the control interface is not really enabled in the compiled IP, or the programmed input format does not match the actual AXI4-S Lite video. I would strongly suggest you to try out our example design if you haven't, it will give you some tips where to start on. Regards, Wincent_Altera0Views0likes0CommentsRe: Cyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hi SharmaUmesh278 , Can you please try out below design https://docs.altera.com/r/docs/683541/current/an-456-pci-express-high-performance-reference-design/software-requirements You can download via PCI Express High-Performance Reference Design in Cyclone IV GX Devices If SignalTap shows correct data only during the valid window, your main problem is probably handshake/timing at the AVMM read interface, not the idle 0xFFFFFFFF itself. Regards, Wincent_Altera5Views0likes0CommentsRe: VVP Scaler Coeff
Hi JLee25 , For a reference code/design like the old VIP suite that shows on-the-fly coefficient generation: No — I did not find that in the documents/URL we read. The old example page only says the design scales video; it does not show coefficient-generation logic. For whether VVP Scaler supports runtime coefficient updates: Yes — the user guide says that if runtime coefficient updates are enabled, you can write coefficient values to the coefficient memory via the Avalon-MM interface. Regards, Wincent_Altera16Views0likes0CommentsRe: Cyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hi SharmaUmesh278 , Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity? >> In our user guide mentioned that, the RX logic processes requests from the root complex, and that the Avalon-MM RX master issues the corresponding Avalon-MM read/write transactions into the FPGA fabric. It also states that some bridge register regions are typically intended for access by PCI Express processors only, and that the PCI Express root complex typically requires write/read access to certain mailbox registers. So the guide supports the idea that root-complex-originated accesses are normal >> detail please refer to IP Compiler for PCI Express User Guide Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP? >> Our PCIe IP is following PCI-SIG compliance >> As long as the Laptop is PCI-SIG compliance, by right it shall be no problem. >> But in your case, I would suggest to switch to another different host and check if the error is follow. I suspect is individual host issue. Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1? >> Are you using Gen1 design if I understand correctly ? >> I would suggest to set the BIOS PCIe speed from "auto" into "gen1", I did experience certain brand of host actually cannot perform auto negotiation. Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver? >>From what I understand , the RX block processes requests from the root complex, passes header information to the Avalon-MM master, and the RX master generates the corresponding Avalon-MM transactions to the connected slaves. Regards, Wincent_Altera10Views1like2CommentsRe: mipi csi2 tx, upper limit of video width
Hi yumada , I've had problems getting the sim to run in that config, as the sim wasn't really designed to handle such long lines, it was only intended to demonstrate data flow I believe. As I can see a simple way to fix the main place it struggles. However, I don't see the issue that you reporting in that configuration - I can get 7680 pixel lines through CSI Tx in the stated configuration without seeing the input stall. In RAW8 each pixel has 8 bits, which in the VVP streaming protocol is carried using 16-bits per pixel. So 4-PIP RAW8 requires a 64-bit wide data bus. But the cfg_pkg image and waveforms show a 96-bit data bus, which at 4 PIP implies 24-bits per pixel. Unfortunately, the image of cfg_pkg was cropped to hide the data type. For example, mine for the above was: Regards, Wincent8Views0likes1CommentRe: mipi csi2 tx, upper limit of video width
Hi yumada , Can you please try to .zip the file and share it again ? IF not , do appreciate if you can help to provide the IP configuration, and especially the data type that you are using, Meanwhile, I am trying to replicate the issue --> get back to you soon as I have any finding. Regards, Wincent_Altera33Views0likes1Comment