I' ve been using the VIP core for some time now, but am still having problems with a few aspect of the design. The project in question mixes two input channels, with clippers and scalers and multiple output modes, and each component in the design has a control port.Q1) What order should I be starting each of the core components? Right now they're started from input (first) through to output (last), in order of 'flow'. Q2) I'm having problems starting the clocked video output core. Most of the time it fails to start, and reading back the output mode, it's set to 0. Right now the only way to recover is reset the entire SOPC system and try again. Sometimes (rarely) it comes up 1st iteration, but generally it takes 5 or 6 (sometimes a lot more!) Once the system (CVO) has started properly, it's pretty stable. I can plug/unplug the inputs and it doesn't lock up. But starting is a real problem... :( Any pointers would be appreciated! Regards, Mark
Hi,Although it will not matter in most cases, starting the components from the output to the input is usually a better choice. You are less likely to overflow the CVI and trigger other issues in the system if the IP blocks downstream are ready to start processing when the data arrives.
Not sure if this is any help, but I bought the NEEK (nios eval board) and I am learning the VIP using a demo available in Alterawiki - note: not the 'AN427' demo , but the other one.I think it is written by one of the Altera dudes, and is probably a good example of how to do what you are trying. It includes most of the VIP modules - used in quite a cool way - live mixing, re-scaling, clipping - absolutely no flickering- amazing. He uses the synchroniser module to make sure things happen at the correct time. On screen display aswell. Hand written pattern generator aswell. You dont need the NEEK to understand it. (written for 9.1, but compiles fine in 10.1)
@johnjunk: Thanks for the heads-up, I'll check it out.I think I've found the problem, or a major contributing factor... we support multiple output modes and therefore we must dynamically configure the PLL used for video output. Previously I was configuring the PLL *after* the VIP components were brought out of reset, and then starting the CVO module via the control port. If I configure the PLL and *then* reset the entire VIP core (including CVO), and subsequently start CVO, the problem is all-but-eliminated. Still more investigation required... EDIT: is anyone else using dynamically-configured PLLs for VIP/CVO?