It would be very helpful for me and others involved in an ADV212 design if we could get the ADV212 evaluation kit schematics. Can this be posted somewhere?
You'll find them posted here: ftp://ftp.analog.com/pub/Digital_Imaging/
Thanks for the link Dave. I would like to run with IOVDD at 3.0V instead of 3.3V or 2.5V. The data dheet specifies two IOVDD ranges that almost overlap. Any reason I can't use 3.0V?
We haven't characterized it so I couldn't really say yes or no. It's generally safer to use 3.3V as it's had the most testing and is used the most widely. If you run into problems with another voltage, our advice is going to be to run the IO at 3.3V....
One more ADV212 question: In decode mode using master CCIR656 mode on the VDATA bus, what does the ADV212 output on the VDATA bus between frames if the last decoded frame has been output and the next frame hasn't been decoded yet?
You'll get a black frame out.
Thanks. I'm trying to understand how in decode mode VCLK should be driven so the output frame rate matches the input to the decoder.Can VCLK be gated or does it have to run continuously? Should it just be fixed at 27MHz and the decoder will synchronize reading the input code stream to match the output frame rate?
VCLK should run continuously. The part will read data as fast as it can as long as it has memory. There are several ways to match encoder and decoder VCLK. The best way, if possible, is to tweak the decoder VCLK based on the encoder VCLK.
We've done this in the past using a DDS for the decoder clock and tweaking it up or down based on the fullness of our buffer ahead of the decoder. You can also just dump or duplicate frames and leave the VCLK alone.
There are lots of approaches, but it's not a trivial problem.
Thanks Dave, this is very useful information. Following up on this, I see the release notes for the decoder firmware states that SCOM will be asserted if video stream under-run occurs. I'm assuming "video stream" refers to the VDATA bus output. Does under-run in this context mean the external VDATA interface is too slow or too fast? It also says SCOM remains asserted until the next PI interrupt. What is the PI interrupt?
SCOM assertion would be an indication that you are getting a black frame because it didn't get data in time to output it that frame. The stream is in reference to the compressed data input not going in on the HDATA interface fast enough. In general, the entire codestream for the next frame needs to be inside the part at least 1/3 of a frame time before the VSYNC it supposed to come out on.
PI interrupt is an internal one tied to VSYNC.
Does SCOM get asserted sometime during the VSYNC period of the black frame?
Generally yes, but it's software controlled so it's not entirely deterministic.
Are these black frames entire frames or individual fields? In other words, to avoid a black frame on the VDATA bus does the decoder need the code words for both fields or will it output one decoded field and then a black field if the second encoded field arrives too late?
In the case of interlaced video-- it would give a black frame in order to maintain field polarity.
Retrieving data ...