Honored Contributor
Honored ContributorGlad you got it to work! Some time ago I ran into similar problems with the CVI. Taking away the input source, or changing the input so that it does not contain SAV/EAV codes anymore (I use BT656 / BT1120 with embedded syncs) resulted in the current ST packet just being "left open" with now EOP until the core properly synchronizes again. I did some simulations with the core and could reproduce the results there. But I did not have enough time to document these and raise the issue with Altera. It is possible that this is what you have seen - once the FIFO overflows, the core never fully resynchronizes and the current ST packet is left open with no more EOPs. But then you should have seen a FIFO overflow in the status register.
Both the CVI and CVO, in my opinion, are not robust enough to handle all real world situations gracefully. The CVO has a similar problem: if you take away the video output clock (which is an input to the CVO) then its AvalonMM slave interface (which is on a different clock domain) asserts the WaitRequest forever, freezing the whole Avalon bus if it is accessed! Not very robust. I rewrote the CVO some time ago for this reason - I could not guarentee that the video output clock will always be present. I am seriously contemplating doing the same for the CVI as well. Regards, Niki
