Dear Charles & other Experts,
I have done some more analysis. I have measured the track capacitance
of the clock & data signals of device 'A' & 'B'. For this I used Agilent
4249A Impedance analyser.
In product 'A' which consistently passes in the test, the clock signal
capacitance value is about 42 pF.
In product 'B' which consistently fails in the test, the clock signal
capacitance value is about 56 pF.
In 'A', I tried by adding a 47 pF capacitor across the clock signal
and ground near to controller end (controller drives the clock signal). But
still 'A' consistently passes. I measured the clock signal capacitance
with this additional 47 pF and the value measured is about 90 pF (almost
equal to the algebraic sum of original 42 pF and the added 47 pF).
I still believe transmission delay time is the root cause and I need
your guidance for the further testing and for understanding the above
results.
Sincerely
K.Balasubramanian
Project Leader - Hardware.
K
Balasubramanian/I
N/SCM To
"Charles Gervasi"
09/02/2006 06:27 <[log in to unmask]>,
PM "(Designers Council Forum)"
<[log in to unmask]>
cc
Subject
RE: [DC] Trace propagation delay
may not be the problem.(Document
link: K Balasubramanian)
Dear Charles,
Certainly on finding the root cause I will come back to the forum.
One piece of information I missed in my previous mail. There is an 26
pin SMT connector involved in the device 'B'. Data, clock and control
lines are routed through this connector. Male piece is on the controller
PCB and the female piece on the device PCB. The PCB in which peripheral
device is placed should not contain any passives, so I placed all the
series termination resistors in the controller PCB. Signal quality
measurements does not show any abnormality.
The controller PCB is of 6 layer and device PCB is of 4 layer type
with solid ground planes below all the traces.
Sincerely
K.Balasubramanian
Project Leader - Hardware.
"Charles Gervasi"
<cgervasi@prosoft
-technology.com> To
"(Designers Council Forum)"
09/01/2006 07:16 <[log in to unmask]>,
PM <[log in to unmask]>
cc
Subject
RE: [DC] Trace propagation delay
may not be the problem.
That is a mystery to me. It's unfortunate that an extra 540ps (3
inches) causes it to fail. It makes you worry that there's not enough
headroom the Device A design. It makes you suspicious that something
else might be going on apart from propagation delay.
I wonder if there's a signal integrity problem and better termination
would help. I doubt that, though, since the rise times (5ns) are >= six
times the propagation delay (180ps * 4.5). Is there a solid ground
plane under all traces?
I hope you post a message when you figure it out.
CJ
-----Original Message-----
From: DesignerCouncil [mailto:[log in to unmask]] On Behalf Of
Balasubramanian Krishnan
Sent: Friday, September 01, 2006 2:21 AM
To: [log in to unmask]
Subject: Re: [DC] Trace propagation delay may not be the problem.
Dear Charles,
Thanks for the thorough attention paid to my mail and for the
detailed reply. There are 2 products with same controller and peripheral
device. Please find the length of traces in both the products below.
Product 'A' functions well consistently but product 'B' fails
consistently.
The delay introduced by the device is not matching with the controller
timing specification. These timing are not firmware controllable they
are
inherited in the controller / device (hardware).
Length of Data line:
Device 'A' - 1.5 inch,
Device 'B' - 4.5 inch.
Length of Clock line:
Device 'A' - 1.5 inch
Device 'B' - 4.5 inch.
Sincerely
K.Balasubramanian
Project Leader - Hardware.
"Charles Gervasi"
<cgervasi@prosoft
-technology.com>
To
"(Designers Council Forum)"
08/31/2006 07:41 <[log in to unmask]>,
PM <[log in to unmask]>
cc
Subject
Trace popagation delay may not be
the problem.
The propagation speed in a stripline (internal) trace is equal to (speed
of light) / sqrt (dialectric const). That works out to about 180 ps/
in. Assuming your traces are a few inches long, propagation delay of
the traces accounts for only a very small fraction of the delay. To
reduce propagation delay by 2ns, you would have to decrease trace length
by 12 inches.
Expensive materials have a higher dielectric constant and therefore more
propagation delay. Microstrip traces may propagate slightly faster but
still only about 140ps/in. 85ps/in is the speed of light, which is the
ultimate speed limit of the universe.
It seems to me that the software will have to be modified to wait an
additional 2 ns, or the device it's getting data from will have to
generate its own clock/interrupt.
CJ
-----Original Message-----
From: DesignerCouncil [mailto:[log in to unmask]] On Behalf Of
Balasubramanian Krishnan
Sent: Thursday, August 31, 2006 8:21 AM
To: [log in to unmask]
Subject: [DC] How to minimise PCB trace propagation time
Dear Experts,
In one of our design we see that signal round trip delay (clock
'high
to low' transition and data arrival) is beyond the timing requirement of
the microcontroller used. The microcontroller expects the data to arrive
within 14 nanoseconds after the clock pulse is activated but the data is
reaching only after 16 nanoseconds delay and hence the device fails. No
over shoots or undershoots are noticed in the clock signal, the clock
frequency is 24 MHz with rise time of about 4 to 5 nano seconds. The
PCB
trace length cannot be reduced. Costly PCB material (for low relative
permittivity) is not acceptable being a cost effective product.
How to handle this issue? Your expert guidance will be of great
use.
Sincerely
K.Balasubramanian
Project Leader - Hardware.
------------------------------------------------------------------------
---------
DesignerCouncil Mail List provided as a free service by IPC using
LISTSERV 1.8d
To unsubscribe, send a message to [log in to unmask] with following text
in
the BODY (NOT the subject field): SIGNOFF DesignerCouncil.
To temporarily stop/(restart) delivery of DesignerCouncil send: SET
DesignerCouncil NOMAIL/(MAIL)
Search previous postings at: www.ipc.org > On-Line Resources & Databases
> E-mail Archives
Please visit IPC web site
http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional
information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100
ext.2815
------------------------------------------------------------------------
---------
------------------------------------------------------------------------
---------
DesignerCouncil Mail List provided as a free service by IPC using
LISTSERV 1.8d
To unsubscribe, send a message to [log in to unmask] with following text
in
the BODY (NOT the subject field): SIGNOFF DesignerCouncil.
To temporarily stop/(restart) delivery of DesignerCouncil send: SET
DesignerCouncil NOMAIL/(MAIL)
Search previous postings at: www.ipc.org > On-Line Resources & Databases
> E-mail Archives
Please visit IPC web site
http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional
information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100
ext.2815
------------------------------------------------------------------------
---------
---------------------------------------------------------------------------------
DesignerCouncil Mail List provided as a free service by IPC using LISTSERV 1.8d
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF DesignerCouncil.
To temporarily stop/(restart) delivery of DesignerCouncil send: SET DesignerCouncil NOMAIL/(MAIL)
Search previous postings at: www.ipc.org > On-Line Resources & Databases > E-mail Archives
Please visit IPC web site http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100 ext.2815
---------------------------------------------------------------------------------
|
