VIP Clocked Video Input Malfunction?

[Altera_Forum]

Hi, 

 I am experiencing problems with the VIP clocked video input core and would like to know if anybody has seen similar issues. I use the core to receive various video formats - from SD serial 4:2:2 to HD parallel 4:2:2, all with embedded syncs (AV codes). If I remove the video source from the input at random times (plugging the cable out and in), the core sometimes goes into a state where it permanently reports a FIFO overflow. You can clear the FIFO overflow bit (by writing 0x0200 to the video status register) but it gets set again immediately.    Here is a more detailed sequence of events / actions after entering this state: 1. I read 0x03f9 from the status register. So it registers a FIFO overlfow, but is still outputting data.  2. I write 0x0200 to the status register, but when I read back the status register, it is still 0x03f9. 3. I stop the core by writing 0 to the control register. The status register now reads back 0x03f8. So it has stopped outputting data. 4. I write 0x0200 to the status register and read back 0x01f8. The overflow bit is now cleared.  5. I start the core again by writing 1 to the control register. Immediately I read 0x03f9 from the status register. The overflow bit is again set.   On the output of the core I have a custom core which permanently drives the Ready line of the Avalon ST interface high - so there is no backpressure that could cause a FIFO overflow. My system clock is 90MHz and I make timing. This state occurs even with low data rate modes (like SD PAL/NTSC) so it is not data rate dependent. The only way to recover from this state is to reset the FPGA (driving the global reset high and low again).   I have also noticed that while in this state, the core outputs data, but the data is garbled. (Further down the line I have frame grabber with which I can inspect the data and I get a totally garbled frame in this state).   I can only speculate that the removal and re-application of the input video stream causes the internal state machine(s) to enter an invalid or lock-up state. Since I have no control over how and when the data stream gets applied or interrupted I need this module to be able to recover from any kind of error on the input.   Has anybody seen anything similar? Or have any ideas of what might be wrong?   Thanks! Niki

[Altera_Forum]

1 - Which device family are you using? 

2 - How deep did you make the FIFO inside the clocked input block? 3 - Have you checked the box that allows recovery of SD? 4 - Are you certain you have properly constrained timing on the input side of the clocked video input block? Where is the input coming from? (IC, SDI receiver core, etc.). All of the logic inside the CVI block is clocked using the video clock and not the system clock. So all the word and line counters, the VIP control packet insertion, everything is run from that clock. If it's not stable or properly constrained, you'll have problems. Also, I would make sure the "vid_locked" signal is truly getting set to 0 when you remove the video. You might need to add some logic to ensure that it does. 5 - I would signaltap the Avalon streaming interface out of the clocked input block. 6 - I would signaltap the core itself. Unlike the other Video IP cores, you actually have access to the source code for the clocked input block. Look in your database directory (db) for a file called alt_vip_Vid2IS.v or just Vid2IS.v. This is the source code for the clocked input block.  I have not seen this particular problem and I have used the core under the same conditions as you (SD/HD/3G video). However, I haven't used it for a while as I long ago wrote my own version of the CVI block. It's possible the Altera version has undergone some changes.  Jake

[Altera_Forum]

Hi JackobJones, 

 Thanks for the reply! Here are some answers to your questions: 1. Cyclone 3, (EP3C16) 2. The FIFO is 2048 pixels (I need it to work up to HD 1080i which has 1920 pixels per line) 3. I am not aware of suvh a blxo, but I will look again... 4. Yes, I am sure the timing is properly constrained. I have a set_input_delay constraint for all data inputs. I have also registered the input data and placed the registers in the IO blocks. TimeQuest reports a max video clock of 159MHz, where I need only up to 75MHz. I have also analyzed the worst case setup and hold path in Timequest and I can see that it is correct as I expect it. If there was a timing problem, I would have expected noise in the images, or "bad pixels". But if it works, it works 100% until it gets into this funny state, where it does not work at all. 5. Yes, I would like to but I am using an evaluation license for the VIP cores which makes it impossible to signaltap the design (or am I wrong? I am under the impression that I cannot signaltap a design which includes time limited IP evaluation cores). 6. Ah-ha, didn't know that! I'll have a look.   I have played around with the vid_locked signal as well bit it made no difference. I do take the vid_locked signal low when my system detects a loss of signal (this is done by a uC which monitors the video decoder).    Personally I think it is not a good idea to run the core from the video clock - I would take all data into a FIFO as soon as possible then do all the work in the system clock domain. Since I have no control over the input video clock (it might glitch - violating timing), it would never be safew to run the main control state machines from this clock. I have seen, for instance, that if I remove the video clock, the status register still indicates a lock and valid line and pixel counters (it reads back 0x01f8). This should not be the case - without a video clock, the status should read back that it does not have lock, and this can only be done if the control runs of the system clock.   Anyhow, I am on the verge of rewriting this core myself...   Thanks again! Niki

[Altera_Forum]

You can run signaltap with a time-limited design. You either have to disconnect from the design (in which case it will usually run for an hour) and then run signaltap or you can start another instance of Quartus and run signaltap from there. 

 One thing you might consider doing is to put a small dual-clock FIFO outside your SoPC system. Bring the raw video data into the FIFO using the video clock. Then clock the output of the FIFO using your system clock and going into your CVI block. Use the negation of the rdempty signal from the fifo as the datavalid signal into the CVI block. Use the locked signal to clear the FIFO. This will do two things: 1 - Provide a constant,reliable clock to the CVI block. 2 - Allow you to run the CVI block in single clock mode.  Jake

[Altera_Forum]

Hi Jake, 

 Thanks for letting me know about the signaltap. Now I just have to see if it will fit into my FPGA (which is already 90% full and takes 40 minutes to compile on my slow laptop!).   Your suggestion for adding a small FIFO is an excellent suggestion. Thanks! I have started writing my own clocked video input, and might finish it just for the fun of it, but your suggestion will be easier and faster!   Regards, Niki

[Altera_Forum]

Hi Jake, 

 Out of interest, I have done some more measurements with the Altera Clocked Input (without the modifications you suggested). I get the core into this stuck state fairly easily by repeatedly resetting my video decoder. This abruptly removes the video clock. Once in this state I have tried the following just now: 1. Made sure the video clock is again applied and stable (currently at 27MHz) 2. Stop the core and clear the FIFO overrun flag. This works. 3. Enable the core. Immediately I get a FIFO overrun. 4. Stop the core again, clear the FIFO overrun. Drive VidLocked input low. 5. Enable the core. So far nothing happens. 6. Take VidLocked high again. Immediately I get a FIFO overrun.   This time I have also seen that the status register reports that it is not outputting data - yet I see control and vidoe packets coming out of the core.   What is the procedure if I want to report an issue like this to Altera? Do you think it is worth it?   Regards, Niki

[Altera_Forum]

You could report it. The big problem I see is the clock instability. Altera could perhaps do something to improve the reliability in a situation where the input clock is unstable (which seems like it could be common in video designs). 

 It seems to me the fix to would be to reset the core whenever the video locked signal is deasserted.  Writing your own version is a reasonable amount of work. I wish I could give you mine but it was written on company time. I may be able to give you the block which does the control packet insertion. I'll look into it.  Jake

[Altera_Forum]

Hi, 

 Thanks for the offer, but I think I can do it in a reasonable time (I do not need a very generic one, which simplifies the design). But I am also changing my microcontroller firmware to not reset the video decoder during a mode change. I this case I believe the video decoder will not abruptly change the clock. If the input cable is unplugged, the decoder PLL will just coast on. This will probably also fix the problem. If it does not work I will continue with my own version.   Thanks for your help! Niki