8
\$\begingroup\$

I am working on a project that interfaces an Atmel SAMA5D3 MCU with a LCD TFT display. The interface between both is 24-Bit parallel RGB with HSYNC and VSYNC signals. The resolution of the display is 800x480 pixels.

I understand that it is important that all signals and the clock come in at the same time. The way to make that sure is meandering the traces to get equal trace length. I don't have a lot of space (who has) and I am worried that my meanders are too small causing reflections and/or cross talk.

I am also wondering if it is necessary in my case. Trace length is around 50-60 mm. How much variance in trace length is allowed in my case? Perhaps it would be enough to just meander the few shortest traces?

I also have implemented an OV5640 CMOS camera (not in the picture). It's interface is 8-bit parallel. Trace length here is about 60mm. The clock rate is around 100 MHz as far as I know. It's a 5 Megapixel camera. Do I have to meander the traces in this case?

Thank you very much for your help!

Phillip

Update #1: I reworked my design and removed all meanders to get the trace lengths of my signals: The shortest trace is 35mm for LCD HSYNC and the longest trace is LCD_R2 (data bit) with 57.5mm.

Update #2: In order to learn high speed PCB design I read a document I found at Toradex which is very good in my opinion. On page 54 and page 66 the layout guidelines for 24 Bit RGB and Camera parallel interface are summarized like that: "[...] Max skew between data signal and <100ps ≈15mm, depends on pixel clock, requirement can be relaxed for lower clock resolution display [...]". I don't get this en par with your answers. 100ps should allow for much larger trace variance than 15mm (as posted in the answers below)? The document can be found here: http://docs.toradex.com/101123-apalis-arm-carrier-board-design-guide.pdf.

My current PCB layout for 24-bit RGB parallel interface

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Have you looked at the timing diagram needed for this type of communication - the diagram should give you details about the timing limits needed. Also, without the meandering, what would be the difference in length of shortest to longest? \$\endgroup\$
    – Andy aka
    Mar 16, 2015 at 10:12
  • 1
    \$\begingroup\$ The data doesn't have to change at the same time as the clock; it can change before the clock as long as the setup and hold time constraints in the datasheet are observed (as Andy aka points out). \$\endgroup\$
    – Nick Johnson
    Mar 16, 2015 at 10:21
  • \$\begingroup\$ I have "ripuped" all my LCD traces and recreated them without meanders. I measure 35mm trace length for the shortest LCD signal (HSYNC) and 57mm for my longest trace being LCD_R2 (one of the 24 data bits). \$\endgroup\$
    – Phillip Schuster
    Mar 16, 2015 at 11:26
  • \$\begingroup\$ @PhillipSchuster - " 100ps should allow for much larger trace variance than 15mm " Please redo your math. 2 nsec / 100 psec = 20. 1 foot equals about 300 mm. 300mm / 20 = 15 mm. For your new layout, 57mm - 35mm = 22 mm. This violates the requirements you have quoted. \$\endgroup\$
    – WhatRoughBeast
    Mar 16, 2015 at 16:49
  • \$\begingroup\$ Thank you for your comment. Where do you take 2 sec? What is that value? I can follow your calculations but I don't understand where you took 2 nsecs. Thanks. \$\endgroup\$
    – Phillip Schuster
    Mar 19, 2015 at 15:40

4 Answers 4

Reset to default
6
\$\begingroup\$

The rule of thumb is that signals travel at 2ns per foot in standard PCB material. That's roughly half as fast as the speed of light due to the effect of the PCB dielectric material. 180psec per inch is the same thing, and in metric that's 71psec per cm.

Even if you are running with a 100MHz clock, thats 10ns per cycle. So assuming you have half of that as allowable skew for your signals you can have 5ns / 71ps = 70cm mismatch between your signals and still only have 5ns time difference between them.

So I seriously doubt you have to match your signals that closely in this design. But without more detailed specs I'm only guessing...

\$\endgroup\$
3
  • \$\begingroup\$ Thanks. Your calculations make sense. As replied above my trace length varies between 35 and 57mm. That's 3.5cm and 5.7cm. My shortest signal needs 71*3.5 = 248ps and my longest trace needs 71*5.7 = 404ps. If I understand you and @Nick Johnson I have to make sure that the longest trace is my clock signal? If all data signals are shorter their signal arrived before the clock signal. \$\endgroup\$
    – Phillip Schuster
    Mar 16, 2015 at 11:55
  • \$\begingroup\$ @PhillipSchuster: Yes, making the clock trace the longest is one way to make sure that all of the data transitions meet the setup/hold time requirements of the interface, even if there's skew among them. \$\endgroup\$
    – Dave Tweed
    Mar 16, 2015 at 12:14
  • \$\begingroup\$ @PhillipSchuster: Technically not necessary unless you want to output the clock signal in the same instruction as the data (you can do this for example with a 7 bit data + 1 clock and output everything in a single byte). Normally, you'd output the clock at least in the next instruction after you output the data which means you can have again another 70cm difference between your clock and data signals (a total of almost 1 and a half meters) \$\endgroup\$
    – slebetman
    Mar 16, 2015 at 18:22
3
\$\begingroup\$

At 800x600 pixels you have a total of 480000 pixels. It you were refreshing at 50fps (that's OTT, but for illustrative purposes), not including the porches, you would have a 24MHz pixel clock.

24MHz has a wavelength of about 12.5m in a vacuum.

So I would say you can have a variance measured in the order of meters in your trace length.

Impedance / length matched traces are only really needed when you're working with signals in the gigahertz range.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ In order to learn about high speed design I read a (in my opinion) very good document provided by Toradex (docs.toradex.com/…). In this document the layout requirements are described for both interfaces I want to use: 24-Bit RGB and Camera parallel interface. On page 54 and page 66 the layout requirements are summarized in a nice table. You can read: "[..] Max skew between data signal and <100ps ≈15mm, depends on pixel clock, requirement can be relaxed for lower clock resolution display [..]". 100ps should be much longer than 15mm? \$\endgroup\$
    – Phillip Schuster
    Mar 16, 2015 at 12:09
0
\$\begingroup\$

If your PCB has the space, why not match the lengths? It's good to practice length-matching any time you have the chance. However, you should be aware of electrical lengths instead of physical/geometric lengths. You need special software to match electrical lengths; speculating on geometric lengths is useless here.

\$\endgroup\$
1
  • \$\begingroup\$ This is what I thought. And it worked out quite well. And it looks very professional ;-). But I am unsure if my meanders are large enough. I did not want to get crosstalk and bad signal quality due to (unnecessary) meanders. Are my meanders good enough? \$\endgroup\$
    – Phillip Schuster
    Mar 19, 2015 at 15:38
0
\$\begingroup\$

I done some SRAM/CPLD/DAC waveform generator (10bits) at 100 MHz clock. Did not bother to match the delays at all. Used Diptrace autorouter generating 20..45mm tracks (LVCMOS 3.3V). Everything works just fine.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.