DaVinci Video Encoder NTSC clocking

BMillikan said:

I am looking at the diagram (Figure 22) of the VPBE and I want to clock it using an external clock source at VPBECLK.  How do I divide the OSD clock by 2 if the incoming clock is 27MHz (ie. I want 13.5MHz at the OSD)? 

Assuming DM6446 and SPRUE37c for the figure, the OSD is actually configured for half the clock within the OSD iteslf, so it is fed the same 27MHz clock, in particular section 4.5.2 discusses the OSD clock management. It just happens that the default settings for OSDCLK1.OCPT and OSDCLK0.OCPW lead to a half rate OSD clock, so this should be working for you out of the box.

BMillikan said:

It looks like I want to set the "venc_div2" flag, but I don't see it anywhere.

This looks to be a typo in figure 22, I believe that should be called just VENC_DIV without the 2, in which case you are looking at the second bit of the PCR register as shown in figure 78 of SPRUE37c, however I don't think you want to use this unless you are feeding in 54MHz as it impacts both the clock going into the OSD and the VENC.

I'm having a strange problem when using the VPBECLK on the DM6446 for NTSC video output.  I am trying to synchronize several DM6446 outputs using the same clock at the VPBECLK, but I am losing the color channel for some reason when I just do a simple copy from the command prompt to the frame buffer "cp osd.r16 /dev/fb/0".  It is also jittery when I display a video stream when hooked up to a TVP5146 chip (and no color).  We are using a CDCE913 PLL clock chip to generate the clock for the DM6446 VPBECLK.  It is currently being set for 27MHz.

Losing color and having a jittery display could be an analog problem, is this only happening when you use the VPBECLK as your clock source or do you see this with other clocking methods? From an analog perspective how does your output configuration look like, I imagine this was copied from the EVM schematic on page 25?

Our board is pretty much a copy of what was done on the EVM board.  It looks fine if we allow the DaVinci use it's own internal clock to generate the NTSC signals.  The problem only comes about when I change MUXSEL in the VPSS_CLKCTL register from 0x0 to 0x2.  I measured the VPBECLK and it is right around 27MHz.  It is a PLL, though, so it may not be there exactly when the DaVinci powers up.  Will that be a problem?

I'm setting VPSS_CLKCTL to 0x1A.  Is that correct?  Should the DACCLKEN and VENCCLKEN be 1 if I am providing the VPBECLK?

BMillikan said:

I measured the VPBECLK and it is right around 27MHz.  It is a PLL, though, so it may not be there exactly when the DaVinci powers up.  Will that be a problem?

I don't believe this will be a problem, the vpbe will not be active until later on anyway when the driver configures it.

BMillikan said:

I'm setting VPSS_CLKCTL to 0x1A.  Is that correct?

This sounds like the right setting.

BMillikan said:

Should the DACCLKEN and VENCCLKEN be 1 if I am providing the VPBECLK?

That is right, otherwise the DAC and VENC will not be active.

Ok, my clock coming out of the PLL was not *exactly* 27MHz.  It was more like 26.5MHz because I was also using it to generate a 40MHz clock as well and that was the best it could to.  So, I was able to tie the VPBECLK to a 27MHz oscillator and the color is perfect.  However, it is still jittery.  The analog backend from the DM6446 is pretty much the same as the DVEVM with the exception that we have 3 DM6446 video processors feeding into a video MUX that we switch with yet another DM6446.  However, the video looks fine when I let each DM6446 run with it's own VCLK instead of using the VPBECLK (VPSS_CLKCTL is set to 0x18 instead of 0x1A). 

BMillikan said:

Ok, my clock coming out of the PLL was not *exactly* 27MHz.  It was more like 26.5MHz because I was also using it to generate a 40MHz clock as well and that was the best it could to.  So, I was able to tie the VPBECLK to a 27MHz oscillator and the color is perfect.

I am glad to hear this resolved the color problem, this sounds like good progress.

BMillikan said:

However, it is still jittery.

Could you provide some more detail on what you mean by jittery? Is this a horizontal or vertical phenomenon, and is it the whole screen or just some lines? Perhaps you could post a picture of the output screen if this is something that could be captured in a stll image.

BMillikan said:

The analog backend from the DM6446 is pretty much the same as the DVEVM with the exception that we have 3 DM6446 video processors feeding into a video MUX that we switch with yet another DM6446.

So you are taking the CVBS NTSC output from the DM6446 devices and running it into a three input one output analog video switch the output of which goes into another analog video switch with another DM6446 for the final output? I would typically be suspicious of how the analog portion was handled however your next statement implies that the analog portion is really ok.

BMillikan said:

However, the video looks fine when I let each DM6446 run with it's own VCLK instead of using the VPBECLK (VPSS_CLKCTL is set to 0x18 instead of 0x1A). 

By my understanding there should be no difference between MUXSEL=0 and MUXSEL=2 if both the MXI crystal is 27MHz and the VPBECLK pin is being driven at 27MHz, this should really just be between using the internal oscillator and the external oscillator, in which case if there is a functional difference than the prime suspect would be the VPBECLK signal being fed in. If the signal was not solid and stable a 'jittery' analog output seems to be a reasonable end result.

Lets take a few steps back here though...

BMillikan said:

I am trying to synchronize several DM6446 outputs using the same clock at the VPBECLK

How accurately do you need the outputs to be aligned at the pixel level? Since you are using analog outputs, and the horizontal axis is analog, does the clocking at an individual pixel level really have a large enough impact to tangibly effect the resultant output? My thought here is that if you are trying to have the outputs aligned that the clock level may not matter as much as the sync insertions, so as long as you feed the same external sync signals to each device you should have all of them aligned with the same frame, even if the clocks are off by a pixel. I imagine you are planning on using external syncs on the VPBE (i.e. VMOD.SLAVE=1) as this is the only practical way I can see of getting the devices all frame synchronized together, otherwise even if the clocks are synchronized the timing generators internally may not be. Note that I have not come across someone using slave mode with the DACs in this fashion, though it seems like it should work.

I'm not sure how to capture the screen, since it seems to be only when I am putting motion video through it (using a camera source through a TVP5146 chip, to the DM6446 VPFE through DRAM and out the VPBE).  The only way I can describe it is that the picture literally "jumps" periodically (vertically).

We are taking the analog outputs to three different places and there we have three analog video switches that can switch between the video channels to the back portion of the electronics.

We have actually tried the VMOD.SLAVE=1 and it worked, but we got weird results.  That is, we got a weird "NTSC-like" video stream out the back-end.  Our oscilloscope didn't like it at all and couldn't trigger on it (it normally can).  The platform we are integrating on doesn't seem to like it either.  So, we are trying this method with using the VPBECLK.  I wonder if our lines are too long or we are loading it too much.  We had to white wire the board to make this change as this wasn't in our original design.

BMillikan said:

We have actually tried the VMOD.SLAVE=1 and it worked, but we got weird results.  That is, we got a weird "NTSC-like" video stream out the back-end.  Our oscilloscope didn't like it at all and couldn't trigger on it (it normally can).  The platform we are integrating on doesn't seem to like it either.  So, we are trying this method with using the VPBECLK.

As I mentioned in the last post, I am not sure that using the same clock to all the DM6446 devices will result in a real synchronized output, at least not one that is guaranteed every time you power up the board and across different boards with different silicon, since the overall frame synchronization (h/v sync) is based on counters in the VPBE that will not be guaranteed to be aligned with each other. For example if the VPBE is being configured by a higher level software driver, and the OS on each board does not boot at exactly the same speed, than you could end up with wide inconsistencies in the syncs, similarly if one device happens to power up slightly faster than another. The only way to guarantee these would be to drive with external syncs to keep each part inline, though this seems to not be working so well in your case (and like I said, I am not sure how well this works with the DACs, though the docs do not suggest it will not).

I am curious if you are seeing alignment in the syncs on all the DM644x devices using the shared VPBE clock method?

BMillikan said:

I wonder if our lines are too long or we are loading it too much.  We had to white wire the board to make this change as this wasn't in our original design.

Is the new 27MHz oscillator white wired as well? If you have a waveform generator handy it might be worth trying to drive the clock directly by hand with a known good source clock to see if that helps.

We are seeing an interesting effect.  We used two layers (the OSD0 and OSD1) to display our overlay graphics and they do not appear to "jitter".  However, our input video does appear to "jitter".  I can also copy a bitmap image to the OSD0 buffer and it does not jitter when I use the external clock.  Now, I know that the TVP5146 chip is providing the PCLK to the DaVinci that is different than the VPBECLK but both are 27MHz.  That is creating a sync difference between the input video and the output video.  Perhaps this is the problem. 

BMillikan said:

Now, I know that the TVP5146 chip is providing the PCLK to the DaVinci that is different than the VPBECLK but both are 27MHz. That is creating a sync difference between the input video and the output video.  Perhaps this is the problem. 

This should not be an issue from a DM644x perspective, the capture and display interfaces can be clocked independently, which is why there is a PCLK and a VPBECLK and not just one 'VPSS clock' pin, the video itself is buffered in DDR to make both ends independent, so a difference in the clocks should not be an issue.

BMillikan said:

We are seeing an interesting effect.  We used two layers (the OSD0 and OSD1) to display our overlay graphics and they do not appear to "jitter".  However, our input video does appear to "jitter".  I can also copy a bitmap image to the OSD0 buffer and it does not jitter when I use the external clock.

This portion helps to solidify my above statement, if the display was getting corrupted because of a difference in the clocks than I would expect all of the display to jitter, not just the video window. This being said, if you fill your video window with a test pattern like color bars in software instead of the captured video from your front end do you still see the jitter? You should be able to leave the front end capture driver running so ensure that if there is an interaction from clocks that it will be seen, just ignore the incoming frames or dump them to /dev/null instead of passing them into the display video window. This should help to narrow down your jitter issues to something on the capture side of the system.

When I switch to using the external VPBECLK, I am only changing the VPSS_CLKCTL register to use the external clock.  Are there any other registers that might need to change in order to make this change work?  We moved the oscillator closer to the pins of the DaVinci chips using white wires, but the picture is still shakey.  Again, it just seems to be the video layer and not the osd layer.  I'm not positive that this is the case, but it sure looks that way.  The oscillator is driving two DaVinci chips (instead of just one) because we wish to sychronize the outputs of the DaVinci chips using a single oscillator.  How do I run the above mentioned test?  I'd like to narrow this problem down to something manageable.

BMillikan said:

When I switch to using the external VPBECLK, I am only changing the VPSS_CLKCTL register to use the external clock.  Are there any other registers that might need to change in order to make this change work? 

If the clocks are effectively the same than you should only need to modify the mux, it may be worth resetting the VPSS from the power and sleep controller (PSC) when changing the clocks to see if that impacts the situation, though you should not have to.

BMillikan said:

We moved the oscillator closer to the pins of the DaVinci chips using white wires, but the picture is still shakey.  Again, it just seems to be the video layer and not the osd layer.  I'm not positive that this is the case, but it sure looks that way.  The oscillator is driving two DaVinci chips (instead of just one) because we wish to sychronize the outputs of the DaVinci chips using a single oscillator.

I am curious if the moving of the oscillator had any impact at all, I understand it is still shaky but is it any less shakey? I am also curious if you put a scope on the clock signal if it is solid and driving strong, as if the splitting between two devices is putting too much of a draw on the oscillator and the DM644x are dropping some clock pulses randomly it could manifest itself as jittery looking video, though I imagine you have already checked this based on your statement.

BMillikan said:

How do I run the above mentioned test?

Assuming you are referring to sending a constant image through the video window generated by the processor through, you would have to modify your application to do this. Assuming your application now is doing some sort of loopback you just have to fill a buffer with generated test values and write that into the vid0 buffer in place of the frame you are bringing in from the VPBE. You could also copy values into the frame buffers from the command line, such as if you had a prepared file of values you could literally 'cp file /dev/vid0', though you would have to have your application turned off to do this since it would immediately overwrite the buffer.