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

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

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.

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

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

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