Forum Discussion
Altera_Forum
Honored Contributor
14 years agoI've been taking the graphical-overlay CVI-block back to the configuration that didn't work, parameter by parameter, to try and figure out where the system "breaks." I changed the parameters in this order: 1) Field order, changed from "any field 1st" back to "field 0 1st"; the system still worked, 2) default frame size, changed from 800x600x32 back to 720x480x32; the system still worked, 3) FIFO size, changed from 3840 pixels back to 100 pixels; the system still worked, 4) (not directly related to CVI block) Global-clock parameter, I removed the "Global" directive on my top-level diagram that forces the main 100MHz clock to be global; the system still worked after I removed this.
So, after doing all this, the only difference between the system that works, and the system that didn't work is that the OMAP (graphical overlay source) has been reconfigured to output frames at a slower rate. It was initially outputting frames at ~73Hz (this is when the system didn't work). It was changed to output frames at 30Hz. The explanation I've come up with for why the system didn't work is: When the system didn't work, and the OMAP was outputting frames at 73Hz, the FIFO size in the CVI was only 100 pixels. I imagine the FIFO was constantly being overflowed, and was causing issues. When the "DVI-Default" was loaded into the CVI, this kicked the FIFO size up to 1920 pixels, and the system began to let more frames through, although there were still some flickering problems, which led us to reduce the frame rate of the OMAP output. The question I still have is: if the above is really true, why wouldn't the CVI constantly send out an EOP signal if the FIFO was always being overrun? When it wasn't working, I only ever saw a single EOP signal.