Unable to create consistently flowing system using VIP suite and CVI w/embedded syncs

[Altera_Forum]

I have created a system with the following flow: 

  HD CVI -> CSC -> HD Sclr -> Switch -> ChResamplr -> FB -> CVO   SD CVI -> Seq -> Deint -> ChRsmplr -> SD Sclr  where the SD scaler is then fed into the switch as well.  In this case, the HD CVI is expecting progressive RGB 4:4:4 with external syncs whereas the SD CVI is expecting interlaced YCbCr 4:2:2 with embedded syncs. I've found that as long as I ensure the switch is set properly prior to flowing data from my ADCs, the above system works correctly and I can make both HD and SD recordings. However, when I try to instantiate another channel with the same setup, I lose my ability in both channels to flow data through the SD paths. A look at SignalTap makes it appear as if the SD CVI block is not working at all.   At this point in time, I am passing the data through a string recognizer that latches data_locked high when it sees an EAV for F1 VBI and then latches data_valid high when it sees the next SAV for F0 active picture.   This inability to consistently flow video data with BT656 embedded syncs has been plaguing me from the beginning. Any help would be greatly appreciated.

[Altera_Forum]

Hi, 

 I am not sure I understand your problem correctly. When you say "instantiate another channel" do you mean that you add an exact copy of you already have (i.e. you now have two HD and 2 SD inputs and two CVO outputs) or do you add two more inputs to the switch (you have two HD and two SD inputs, but still one CVO output and a switch that selects one of the four inputs)?   What exactly are you seeing? Is the CVI not recognizing your BT656 stream, is the FIFO overflowing? What type of de-interlacer are you using in the SD path? Does the de-interlacer buffer data (i.e. does it use double or tripple buffering)? If so, what type of memory are you using and what is the available bandwidth?   Regards, Niki

[Altera_Forum]

Niki, 

 Thank you for your reply. I apologize for taking so long to reply in kind.  By "instantiate another channel", I mean I create an exact copy of what I already have for a different input/output path.   From what I can tell, the CVI is recognizing my BT656 stream as it is able to flow data on occassion. I have actually found that if I begin by flowing data through the HD CVI path and then switch to the embedded sync path, I'm able to flow data without problems...it's only when I try to bring up the system with the embedded sync path (SD) initially.  From looking at my registers, it does not appear that the FIFOs are overflowing. Also, I am using Bob - Scanline Interpolation without buffering for the deinterlacing method.

[Altera_Forum]

Hi, 

 So if you have one instance (with one HD and one SD input and one output), then the system works perfectly. But if you add another instance (which is completely independent form the first instance), then neither instances work correctly? I am asking just to be sure I understand your system and the problems you have been seeing.   If you look at the CVI registers while it is not working as expected (not flowing SD data), can you see that it at least recognises the input video stream? Is the resolution correct? Is it outputting data (is bit 0 of the status register set?). If it is outputting data, and you still see nothing on the output, then the input FIFO in the CVI should overflow. Use SignatTap to look at the video output of each block in the chain, starting at the CVI.   Something else you might look at is the operation of the Switch component. The Switch component only switches between input streams on packet boundaries. I am not 100% sure what it would do if it is initially set to the HD path, but never receives a packet on the HD path before you command it to switch to the SD path. Maybe it assumes that it will always have video present on both inputs and it waits for an end of packet on the HD channel before switching. Change the SoPC system so that SD channel is the default for the switch (i.e. you do not have to change the switch to allow thr SD channel through). See if it will then pass through the SD stream before using the HD stream.    I have had some problems with the CVI block myself in the past. I presume you use two clock domains - the BT656 input clock (27MHz) and your SoPC system clock? What I have seen is tht the CVI can misbehave if you do not provide it with a nice clean contant video input clock. If you abrubtly remove the input clock, or it glitches as it is enabled or disabled, then the state machines in the CVI can enter invalid states. It seems as if there is a fair amount of logic running of the video input clock and if this clock glitches, timing is violated in this logic. If I had to write a CVI I would put no / absolute minimum logic in the video clock domain, immediately go through a dual clock FIFO and do all work in the system clock domain. If I remember correctly (it was some time ago), my biggest problem was that if you suddenly take away the video input (data an clock), the CVI does not recognise that the input is gone and the registers still indicate that stable video is present. I also had other strange behavour until I changed the design to always feed a clock to the CVI. I am not sure if this is a possibility in your system - just be aware that the CVI needs a video clock input to work correctly.   Regards, Niki

[Altera_Forum]

Niki, 

 The additional instance it what would fail to work. It appears that I have found the problem, though. Whereas I had the first channel's SD CVI set to synchronize to F1, the second channel had been overlooked and was set to synchronize to F0. Upon recompiling with both channels set to synchronize to F1, I have not since had trouble flowing data through the system. I'm not certain, but I would suppose having the CVI synchronize to F0 was resulting in an overflow as my datavalid line would not assert until my string recognizer saw a F0 SAV which was perhaps too late for the CVI to sync to and instead, it had to wait through the F1 frame for the next F0.   What with all the problems that this one setting has caused me, I will be sure to keep in mind the data clock issue. Have you found that resetting the SOPC when the CVI enters invalid states is a valid means of handling this problem? I ask as removal of data without losing the entire system is the next issue with which I have to deal.  Thank you very much for your help.  -Jim

[Altera_Forum]

Hi Jim, 

 Glad you found the problem!   I never tried to reset the SOPC system since there were other blocks in there that needed to continue working even if there is no video input. I guess I could have made a separate reset for the CVI, but in the end I changed the way the video decoder was managed to ensure that the output clock never goes away. The problems I had wsa definitely related to interrupting the video clock. Interrupting the data is no problem. I never reaaly had time to go back and setup test cases to isolate the problem and to make it repeatable (does one ever have time?).   I recently also discovered through simulation that if you use the clocked video output, but you do not supply it with a video clock, then writing to any of its registers locks up the Avalon bus - the CVO permanently asserts the wait_request line. There also seems to be some logic that runs off the video output clock and which depends on the clock being present. Again I feel they should have placed all logic in the SOPC clock domain and at the very last stage pass the data (and sync lines) through a dual clock FIFO. It just makes the system more robust.   Good luck with your project! Niki