This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Noise on TVP5146

Other Parts Discussed in Thread: TVP5146, TVP5146M2

Hi

I have a dedicated framegrabber board that I designed about 8 years ago. It uses a SAA7111 video decoder. That device is now obsolete so I have redesigned the board to use the TVP5146 device. 

Only the video decoder part of the PCB has been changed, but I find that I now have noise problems on the TVP5146. The noise looks like just a few LSB and is probably down to the PCB design, but I am struggling to get rid of it.

I have been discussing the matter at on edaboard electronics forum http://www.edaboard.com/thread315358.html. There are PCB layout images there. 

Please give me your valuable expertise to help solve this issue.

Thanks

Mike

  • I have some more information:

    If I close down the iris of my camera so that I should just see a black screen, I see a noise pattern. A photo of the noise image is on my thread at http://www.edaboard.com/thread315358.html. 

    If I disconnect the camera then the screen goes completely black as expected. This would suggest that maybe the camera is noisy, however on the board with the SAA7111 the screen goes black when the camera iris is closed which suggests the camera is OK!

    With the TVP5146, does the output digital signal get forced to a proper black level if it cannot detect a video sync input. I suspect that this is the case and the noise is still at the input but the chip ignores the input because it cannot detect video sync

  • Mike,

    I have just read the other forum postings and I agree entirely with the ground plane split suggestions. You seem to have many signals which cross the plane cuts. this is bad since it causes the return current to have to go around the cut..

    I didn't read all the referenced links but one thing to realize/remember is that the return current for any signal trace will try to be exactly under the signal itself, so if the signal crosses a cut in a plane then the return current needs to be 'diverted' around the cut so that it can then 're-join' the signal on the opposite side of the cut. What this means is that you should never have any signals that cross a cut in a ground plane. You should either make all your signals grouped together, then ensure there is no cut underneath on the ground plane where they all 'cross', or simply use a solid ground plane.

    Split planes most often cause many more issues when you try to use them but do not fully control the return currents correctly.

    Additionally traces which cross splits in ground planes create a loop which in turn becomes an antenna hence will cause EMI issues too.

    Ground signal integrity is all about controlling where the return current flows. I myself have made this mistake in the past by isolating analog circuits, then having signals (both analog and/or digital) cross a split which then forces the return current into exactly the region I was trying to keep separate.

    Bottom line is to never let a signal cross a split in a ground plane. If you don't ever cross a split then it is obvious exactly where the return current is most likely to flow (i.e. under the signal itself).

    Note, the return current does NOT follow the path of least resistance back to the source, it follows the path of least IMPEDANCE back (yep, my college lecturers lied too). For DC this is the same as the resistance, but for a changing signal it depends on the inductance of the signal and the inductance depends on the loop area (and other factors). In general though the lowest impedance path for high frequencies is under the signal itself, so that is where the return current wants to flow.

    Are you using YC mode or using 2 composite inputs? If using YC mode then remove R54 and short R55 so that the chroma channel is disabled. This will help to determine if the noise is induced on luma or chroma.

    Have you tried injecting a different signal in to the input of the coupling capacitor? i.e. from a DVD player (remove R56 and connect a composite input to C129, configuring the TVP for composite input.

    This type of noise is often difficult to track down. It certainly looks to be coherent noise so likely one of the digital outputs is coupling in to the analog domain.

    If you are using discrete sync mode, and not embedded sync mode then try lifting each of the digital YV output pins of the TVP from the PCB to see is one particular signal affects the noise more. Obviously the image will change and a different kind of corruption will appear, but try to look at the low amplitude noise and not the gross noise/banding which will occur.

    BR,

    Steve

  • Hi Steve

    Thanks for the time and effort you put into answering my query. It really is a greatly appreciated.

    Regarding the ground split, it was done this way because of a recommendation in a TVP5146 application note on PCB guidelines - http://www.ti.com/lit/an/slea079/slea079.pdf.  Now having this noise issue and discussing the matter with other more knowledgeable people i can see why it could cause a problem. Buts lets discuss it a bit further here.

    I take on board and agree completely with your discussion on ground return paths, thats understood. However I fail to see where the problem lies in this particular case. Now understanding the issues better and looking at my signals again with a fresh perspective i still cant get to the bottom of the problem. Referencing my board layouts posted on the EDABOARD forum http://www.edaboard.com/thread315358.html, the ground plane in brown is split right up the middle of the TVP5146. Everything connection to the plane on the right hand side is analog. Everything on the left digital. The crystal load capacitors are connected on the analog side, and this was a concern so I lifted them rewired this to be on the digital side but no difference. Also there are three blue tracks that cross the ground slit. They are SDA, SCL and RESET signals for the TVP5146. They start at a microcontroller on the digital plane, cross over the analog plane but then connect back in the digital plane at the TVP5146. Although I now see this is bad practice, the signals only change during TVP5146 initialization and then become static, so the chance of these coupling into the video is nil. Other than these none of the signals cross the split plane.  You commented -"You seem to have many signals which cross the plane cuts. this is bad since it causes the return current to have to go around the cut.." - but I cannot see this, unless you are talking about signals inside the TVP5146, then i see the issue very clearly.

    With this in mind I spent the day making all sorts of tests and alterations, and here are my findings....

    (I am using a Y/C camera video source for the tests and have closed the iris completely to observe just the background noise)

    I bridged across the ground plans by connecting the grounds of the decoupling caps on the analog side to the decoupling caps on the digital side. Short wires were used strapping directly across the top of the chip. I have done this in 5 places and also solder linked the chip analog and digital ground pins 26 and 27. I expected to see some improvement, but there was no improvement to the noise at all, which suggests to me that the ground split is not entirely the cause.

    As previously mentioned I have isolated the crystal circuit from the analog side and connected to the digital side, but no improvement.

    I started to think it may be a digital issue in the FPGA, on the YCbCr bus. Maybe corruption of LSBs. But the system uses embedded syncs and the sync is working flawlessly, which suggests that there is no data corruption on the bus. Additionally increasing the Luma Gain (Reg 47 in the TVP5146) causes the noise level to increase, so that absolutely convinces me the noise is at the analog input.

    Additionally I have done the following tests. Connect only the Luma input with Chroma removed. The noise is still present. Connect only the Chroma input with Luma removed. The image sync is affected as you would expect, but the chroma only image has no noise. So the noise source is definitely on the Luma signal. As previously mentioned,  I check the signal with the Camera iris closed. The image should be a solid black, but the background noise is clearly visible. However, if I disconnect the camera from the Luma input then there is no noise at all - solid black! The TVP5146 continues to generate Hsync and Vsync signals under this condition, but why is there no noise on the signal now ? It suggests to me one of two things.

    1) That the noise source is from the camera, however i do not have this problem with my previous board. I have also tried 2 other different cameras (from different manufacturers) but with the result is the same.

    2)The TVP5146 detects that the Luma, and video sync are missing and continues to output video but forces a black signal level. Can you please confirm that this is the case.

    In addition, I have bypassed my on board switcher supply and used a 3.3v bench power supply to power the board. at 3.3v the problem is the same, however lowering the supply to 3.0v makes the noise all bar disappear. Also increasing the supply to 3.5v improves the situation (I dare not go any higher). I then reconnected my board 3.3v switcher and powered up each supply on the TVP5146 from the bench power supply. I was able to isolate the local TVP5146 supplies by lifting the local supply filter inductors and then connected the bench supply to the device. I went through all the local TVP5146 supplies in this way, but could not improve the noise. I varied the 3.3v supply while doing this but the noise did not improve as it did when varying the supply to the whole board.

    I have now even removed all the 1uH inductors in the local TVP5146 supplies and linked them out.

    The strange thing is whatever i do to the ground or power supplies around the TVP5146 (apart from varying the whole board supply voltage), does not make the noise any better or any worse!

    Do you have any evaluation board gerbers I can view to see how the board should be laid out?

    Regards

    Mike

     

  • Mike,

    Everything I talk about are suggestions, so please don't take anything as a comment that you have done things wrong. Analog noise is a difficult issue to solve and no system is the same as any other.

    The application note does not explicitly recommend a split ground, it says if you use one then here is a recommendation of how. The choice is still a system level one. This is also why you need to be very wary of 'example' layouts etc... since they will only consider an isolated scenario. The remaining layout of your entire system is critical. If the rest of your system inadvertently causes current to flow through the analog regions then there will be noise with or without a split plane. All I can really say though is that in my personal experience I have had much better success with solid planes and careful component placement than I have had with split planes.

    It looks like you have a lot of power supply activity under the analog input signals. Not sure the best way to eliminate this as the root cause.One thing to consider is that it is best to place the input coupling capacitor as close as possible to the TVP. This is because the TVP input and the TVP side of the capacitor are a high impedance hence more susceptible to picking up noise than the other side of the capacitor. The termination resistor (hence AA filter) should also be placed as close as possible to the TVP for the same reason.

    As a test all I can think of is to perhaps lift the 2 input pins of the TVP and completely bypass the PCB traces to see if the noise is still there when the analog input PCB is no longer part of the equation. Don't forget the coupling capacitor and termination resistor. Again, try to get the cap and resistor as close as possible to the TVP, then have flying leads (to a socket if necessary) to allow your camera to be connected.

    This test will help determine if this is an analog signal input issue or a power supply issue. If the noise goes away then the issue is more likely the layout in this input region of the PCB. If the noise does not go away then it is more likely the power supplies and/or the camera itself.

    I concur about the I2C signals. I did not check what they were but they cross multiple times. Even though they are static signals it is still good practice to avoid plane crossing as much as possible since noise on these signals will still behave as though they are active.

    In your split plane you have a solid connection at the top. Do you have the same connection at the bottom? This upper connection creates a loop through the TVP. If you look at the EVM gerbers you should see that the grounds are tied together at the TVP.

    On the schematics I can't see a ground connection for the filters? Could you post a PDF version of the schematics which will be easier to search, and layout screenshots which show more of the analog split plane? In the layout it looks like the 'ground' side of filter cap C58 goes off somewhere. This should be grounded I think.

    The variation in power supply behavior is strange. Can you measure all the power supply voltage levels and check all TVP ground connections?

    BR,

    Steve

  • If the TVP5146 detects that the Luma, and video sync are missing does it continue to output video but forces a black signal level. 

    Can you please confirm that this is the case.

  • Hi Steve

    I have hacked my PCB so that the ground analog plane on the right of the TVP is completely on its own. I used a saw and cut through the PCB to extend the ground plane slit out to the edge of the board above R58 - R62 at the top right and just above CONN8 at the bottom right. (I refer to my PCB layouts on edaboard forum).

    I have also removed the crystal from the boards, removed the crystal tracks from over the ground plane and rebuilt the crystal circuit above the TVP and connected the load capacitor to the digital side ground plane. Absolutely the only the components / tracks now on the analog side are the Y and C input filters and the capacitors and 75R terminations for the unused inputs. So there is absolutely no digital signals in this domain at all.

    The analog plane is connected to the digital plane by a number of short wires running directly across the top of the TVP. Pin 26 AGND and 27 DGND are shorted.

    I connected up the Y/C signal directly onto the Y/C filters with 150mm wires from the camera. I still have the noise.

    I removed the C component. I still have noise on the monochrome image.

    I lifted the Y input pin (pin 9) on the TVP. I connected a 100nf Capacitor to the pin and also then a 75R resistor before the cap. They are floating in mid air just connected to the pin. I connected the Y signal and Y ground from the camera across the 75R resistor. I connected a short link from the Y GND to the Analog ground at the TVP to reference them. The noise was still there.

    In desperation I decided to completely isolate the analog and digital grounds by removing all the straps connecting the two planes together. To my surprise the image still showed up (with the noise of course). I expected since the two planes were now isolated there would be no reference and the image would be worse or not sync! I tested continuity between the 'isolated' analog and digital planes. There was continuity, and it could only be through the TVP.

    I took a spare TVP (completely off board) and checked the continuity between ground pins....

    All the analog GND pins are connected together. All the DGND pins are also connected to the Analog GND pins with the exception of Pin 27 DGND which does not appear to be connected to AGND OR DGND pins. The IOGND pins are on their own net.  

    What is going on? Is this correct?

    No matter what I do cannot get rid of this noise. There is no way I see that digital noise from the FPGA, or rest of the board can get to the analog side (at least not via the ground plane) The noise is definitely coherent with the pixel timing, showing up predominantly on eighth pixel boundaries (where it forms a stronger pattern but not exclusively at this location).

    I have tried powering each of the 4 TVP supplies (3.3v digital., 3.3v analog, 1.8v digital and 1.8v analog) individually from a separate PSU but this did not clear the noise eiither.

    Is there a chance I have a bad batch of TVP5146M2 ???

    Am I expecting too much from the TVP device compared to the SAA7111A ???

    I am just about ready to give up on this device!

    I am based in Melbourne Australia, but will start work at 5:00am tomorrow to try communicate more on your timezone. I hope that you can be available.

    ALSO PLEASE CONFIRM IF TVP WILL OUTPUT BLACK LEVEL IF LUMA SYNC IS NOT DETECTED (as per questions in my earlier messages)

    Thanks and Regards

    Mike

     

      

     

  • Mike,

    I am pretty sure that if no signal is detected then a black image is output. I am checking in to exactly what conditions trigger this though and will get back ASAP.

    Given the experiments you have made, the fact that the noise looks coherent and varies with power supply this might be a timing issue between the TVP and the FPGA on some of the lower bits. Can you look at the relationship of the data signals with respect to the TVP clock with an oscilloscope to capture an eye diagram, then make sure that this timing meets your FPGA input timing specification?

    You can also try inverting the output clock of the TVP by flipping register 34h bit 1.

    We do not expect to see this type of noise.

    Regarding the ground connectivity inside the TVP it might measure as connected but this can be soft connections through internal silicon structures and not necessarily be a hard metal connection.

    BR,

    Steve

  • Whenever the TVP detects loss of H/V lock then it will output a black image and go in to free run mode.

    Loss of color lock does not cause this behavior though but can be used to switch to color kill mode.

    BR,

    Steve

  • Hi Steve

    I must admit that I cant get rid of the feeling that its more like a digital, LSB corruption, and I have considered the possibility of the YUV input to the FPGA being the source of the problem. I have previously checked the timings with a scope and all looked good. TVP clocks out on the falling edge, FPGA clocks in on the rising edge. All signals look good, no ringing on signals and timings as expected. Track length from TVP to FPGA is about 15mm. There are no series resistors in the signal lines.

    What convinced me that this was not the souce of the problem was the following ...

    1. The Embedded sync '0xFF, 0x00, 0x00, 0xSYNC' was being decoded and I never once saw sync problems.

    2. The forced 'black' level, which you have now confirmed is output by the TVP in the event of no sync, shows no sign of noise. 

    3. Increasing or reducing the gain on the TVP Luma chanel respectively increases, decreases the noise

    However I have just updated the software and inverted the clock as you suggested. The noise situation is unchanged. Its still there.

    Any other thoughts?

    Regards

    Mike

  • Mike,

    The black output would not show this kind of timing issue since there would not be any transitions. Timing issue often show up when, for example, you have changing digital values close to a significant bit value.

    For example, a near black value of 16 with a tiny amout of noise will want to jump between 15 and 16. This is a critical level for digital sampling since the bits don't transition at exactly the same time then the receiver might accidentally see 31 instead of 15 due to bit 4 changing slowly if the sample clock is wrong (i.e. sampling close to the transition).

    Binary analysis shows why this can be see only on transitions...

    sample 1 00010000
    sample 2 00001111
    sample 2 00011111 -bad if bit 4 'slow' and all other bits 'fast' and sampling clock is on wrong edge.

    This momentarily wrong value will result in a bright sample. The opposite is also true when going in the opposite sample value direction and results in a darker than expected image.

    The issue is significantly worse for 8 bit ITU656 since chroma and luma are interleaved so chroma values 'leak' in to luma and visa-versa. This most often manifests as green dots or sparkles in captured images.

    If the output is all black then there are no transitions hence you would not see any issue even with a completely wrong sampling clock.

    I do agree that this would affect the sync codes though since there you do have transitions from sample to sample, and all bits change at the same time in the sync code.

    Could you possibly try varying the TVP brightness register t see how the noise behaves? If the noise stays in the same place but varies with intensity then it is a front end issue (i.e. before demodulation) . If on the other hand the position of the noise changes then it implies post demodulation.

    As a sanity check can you make sure that the analog power supplies are at the correct levels and clean.

    This is certainly a strange issue and we have not seen it before.

    The only other thing I can possibly suggest is to see if the same issue exists on a TVP EVM. You could then feed the digital output from the EVM in to your FPGA.


    On the other forum you mentioned varying the power supply. Did you try isolating the TVP power supply and varying just that?

    Can you try adding a test mode to your FPGA to ignore the input value but output a constant low level value to the DAC? If this was run time selectable it would be best so that the FPGA internal switching noise is maintained. I am trying to determine if there is possibly some switching noise from the TVP and/or FPGA reaching the DAC. This would not show up by simply removing the camera since this also makes the TVP outputs to a bloac, but more critically, non-switching state. If we can keep the TVP outputs switching and still feed them to the FPGA but ignore their value we can eliminate the DAC and other TVP-FPGA switching noise.

    I am running out of ideas here.

    BR,

    Steve

  • Hi Steve

    Take you point regarding the black level, and the type of noise i see is quite as you described on significant bit transitions. As it stands at the moment I am able to pick out a pinstripe in the noise about every 8 pixels (the 8 pixels is an assumption based on the distance they are apart). At some point I tried changing the output drive levels and slew rate on my FPGA SRAM interface. I reduced the output drive from 8mA to 4mA, and also changed the slew rate from Fast to Slow. At this point the noise pattern was more visible, with minor pinstripes at 8 pixels and a more pronounced pinstripe at 32 pixels. When I say pinstripes understand i am talking about low level LSB noise not well defined lines. Its absurd. I have since set the FPGA outputs back to standard.

    I have just tried a composite input from my camera onto VI1A. There I have just a 100nf cap and a 75R termination to analog ground. I connected the CVBS directly across the 75R resistor. There is much less noise on this channel even though the capacitor is further from the TVP.

    Regarding the TVP power, I tried an isolated power supply on each of the 4 TVP supplies one at a time isolating each supply from the main board 3.3v by lifting the local inductors. I have not tried completely isolating all supplies together. Its one of the things i have considered trying.

    Regarding the DAC noise. I am capturing 4 images per second from the camera via the TVP. The captured image is saved in SRAM and then repeatedly output to the DAC (adv7125). I can freeze the capture at any time, and when I do this the output on the screen is solid, ie the noise is visible but no noise movement, indicating the noise is saved in the SRAM and being faithfully refreshed to the VGA output without further noise added.

    I will test the brightness and let you know shortly

    Mike

     

  • I have increased the brightness from the default 0x80 to 0xFF.

    The background has lightened from black to grey and the image, although still noisy does not show the pinstipe structure. Its difficult to tell if the pinstripe is still there under the brighter background. however the pinstripe did not increase in brightness with the rest of the image.

    Regards

    Mike

  • I have now powered the whole TVP from a separate 3.3v bench supply. The TVP 3.3digital is fed from the bench supply via a1uH inductor, the 3.3v analog is fed from the bench supply via 1uH inductor, the 1.8v regulator is fed directly from the bench 3.3v and then 2 x 1uH inductors used to feed the analog and digital 1.8v supplies respectively. None of the power for the TVP is from the board. I have joined the bench supply 0v to the TVP 0v .

    Also I have tried the video source from 3 different cameras, and even powered up the camera from a 12v battery to try to eliminate any possible ground loops.

    There is no improvement in the noise.

    Regards

    Mike

  • Another test ...

    TVP was previously configured for YC input: Y on VI-2C, C on VI-1C (Reg 0 = 0x46)

    Have now changed Y input to VI-4A (Reg 0 = 0x4E)

    There is a significant reduction in the noise. Although the faint pinstripe noise is still just visible it is about 20% of what it was on the VI-2C pin.

    The 100nF input capacitor for the VI-4A input is about 25mm from the TVP (Ref.C130). The input capacitor for the VI-2C input is about 3mm from the TVP pin yet carries much more noise??

    Is it the channel 2 ADC thats got issues?

    My part number is TVP5146M2 23A9HST G4

    Mike 

  • How long is this part likely to be in production. I see its listed under Legacy Video Converters!

    Regards

    Mike

  • Mike,

    These tests are good and help eliminate some things at least.

    It is interesting that when you slow/reduce the drive strength that the noise gets worse. Not quite sure what that is telling us though at the moment. It seems counter intuitive. It certainly points towards a switching noise interference though since nothing else in the system changed (although there is a slight possibility that the FPGA timings were affected due to re-synthesis).

    The pin stripe nature of the noise implies this is a position sensitivity and not simply an amplitude sensitivity. What type of memory are you using? SDRAM, DRAM, SRAM etc...?

    Is it possible there is a SRAM timing violation on the lower bits of the luma channel? How are you arranging the data sent to the SDRAM? Is it a 16 bit memory or an 8 bit memory? Could you possibly try some bit swizzling to mix chroma/luma bits and inter-mix LSBs and MSBs? This is not the likely cause since as I mentioned earlier this looks to be position (i.e. RAM address) sensitive. Can you also try swizzling the address bits (assuming SRAM is being used) to see if it changes the behavior of the noise pattern? Minor pin stripes at 8 pixel intervals implies SRAM address bit 3 is somehow different (longer? shorter? closer to something? Further from something? etc...?) likewise for the 32 pixel intervals with address bit bit5.

    Could you still add a selectable test mode which sets the data  sent to the SRAM in one of a couple of formats listed below? Basically mux the data immediately it enters the FPGA before any other processing. The first pattern I would like to see is chroma = 128, luma = 31. The second pattern I would like to see is chroma = 128, luma alternating between 32 and 19 so that slightly different low intensity vertical lines are stored. Again, this needs to be run time selectable so that the FPGA synthesis does not completely optimize away the input logic.

    Are you able to try your CVBS camera but feed it to the luma input of the currently problematic Y channel (obviously selecting CVBS in the TVP configuration registers)?

    If the noise is coupling directly to the analog inputs then using CVBS will tend to mask the noise due to the modulation technique. S-video has superior bandwidth and significantly reduced demodulation artifacts. resulting in a much crisper image. It also shows up more 'detail' such as coupled noise :)

    For the TVP brightness test how does the noise pattern change as you slowly increase the brightness? Small variations in the brightness will cause the position in the output image where the pixel to pixel data transitions flip (i.e. 00001000 to 00000111) for a given semi stable camera input).

    When you say the pinstripe did not increase in brightness with the rest of the image do you mean that the relative brightness went down (i.e. the 'normal' part of the image got brighter but the noise stripes remained dark, or do you mean all pixels got brighter so the relative intensity of the noise remain the same?

    I think it is clearly not a TVP power integrity issue. Coming back to an earlier experiment that you did when you varied the TVP 3.3V supply... The only other thing that this affects is the IO voltage levels. Are you 100% sure that the FPGA inputs are configured for 3.3V input levels?

    I am pretty sure there are no device specific issues since we have not received any other comments relating to quality and all devices are 100% production tested for ADC noise, linearity, INL and DNL. I will however keep my eyes and ears open for any other comments relating to image quality.

    Regarding the "Not recommended for New Design" status of the device all this means is that we have limited design in support available now due to the age of this family of devices. We have no plans currently to end of life these devices so they should be available for years to come. I believe typically there is a 3 year notice of intent to end of life devices which then have a lifetime buy opportunity. The TVP devices are not immediately destined for end of life so should be readily available for a few years minimum. Exactly how long they will be available though I can't comment further.

    BR,

    Steve