Honored Contributor
Honored ContributorHi Thomas,
I was able to circumvent my problems in one way or another, but I was never able to solve the core problem. What I had found was that if you remove the video clock input to the CVI, then the CVI internal logic stops working correctly - the status register does not indicate a loss of lock and it is impossible to disable the core (writing a 0 to the control register never caused bit 0 of the status register to be cleared). Also, if the input clock "glitched", the core could become stuck and I had to apply the global reset to recover. My guess is that there is significant logic / state machines that run of the video clock and without a valid clock the core does not function. I solved this by using the CVI core in "single clock mode" and adding my own dual clocked FIFO between the video input and CVI. One side of the FIFO runs from the video input clock and the other from the system clock. The system clock then becomes the CVI video clock input. The FIFO output goes directly into the CVI and the inverted FIFO_EmptyFlag is basically the data_valid input to the CVI (add small amount of logic to account for pipeline delay). The advantage is that the CVI always sees a nice clock. I then also added some logic to detect a "loss of clock" condition, which then drove the vid_locked input. I can send you the code if you want (VHDL). This solved most of my problems. The one remaining problem was that if I interrupted the video stream, the CVI would not terminate the current video frame until I applied a new video stream and it had re-synced. In my case this was a problem since I had the Switch component which I wanted to switch from the video source to the blue screen in just such a case and it would only switch on a frame boundary. So to solve this I wrote my own switch component which would normally wait for a frame boundary to switch, but if after a timeout no end-of-frame was received, it would force a switch to the internally generated blue screen. This solved all my problems (although not very elegantly!) I must add that this was done on version 9.1SP2. I have sinve moved to version 11, but I have not checked to see of the CVI behaviour is still the same. Also, the source code of the CVI (in Verilog) is available in the Quartus/IP/Altera folder, so it would be possible to fiddle with it (or at least look at it). You do not say anything about the "downstream" path. Have you checked in what state the Avalong-ST output of the CVI is once it gets stuck? What are the levels of the Valid and Ready lines? I have written a simple "pass-through" component that you can instantiate to monitor the Avalon-ST link. The component has an Avalon-MM interface through which you can read back current status and some statistics (like number of video packets / control packets, last resolution, etc.). I can send this to you as well if you think it will help. Regards, Niki
