[SI-LIST] question concerning a PowerPC740
- From: jan.vercammen.jv1@xxxxxxxxxxxxxxxx
- To: si-list@xxxxxxxxxxxxx
- Date: Thu, 16 Aug 2001 17:01:25 +0100
I have a question concerning an IBM PowerPC cpu type 740. A colleague of mine,
Patrick Lambrechs,
has encountered 'hot' reset errors with a 740 PowerPC. The details are below.
Although we check
the standard channels of the manufacturers for an answer to this problem, it
could be worthwhile to
ask the si-list.
To summarize, we pinned the problem to address bus pin 7 (or A7). I have
checked the topology, simulated
and measured this specific net. However, we find no anomalies, with respect to
routing/crosstalk/ringing. It behaves
as the other address bus nets, electrically and layout technically.
The power supplies vcore, 3.3V and 5V are clean.
We solve the problem by a simple pull up resistor of 10K on A7. The question is:
what is so special about address pin A7?
As anyone experienced similar problems, possibly with other address pins.
You can contact me directly at jan.vercammen.jv1@xxxxxxxxxxxxxxxxx
Any help is appreciated.
Kind regards.
Below are the details as input by my colleague.
----------------------------------------
We are experiencing 'hot reset' problems on most of our production CPU boards.
The design is based on IBM EMPPC740GBUB2660 in combination with Motorola
MPC106ARX66CG. As soon as *HRESET negates the CPU initiates the first code fetch
(*TS asserted together with address 0xFFF00100). This access is acknowledged by
the MPC106 by means of an address acknowledge *AACK, asserted during one clock
cycle. However, under certain conditions, the MPC106 responds with two
consecutive pulses on *AACK instead of just one (4 clock cycle sequence:
assert-deassert-assert-deassert).
This erratic behaviour of the MPC106 is known to Motorola, as can be seen on the
PowerPC FAQ database under reference 4495 (see end of this mail).
After having verified all conditions and solutions herein mentioned, we found
that the erratic behaviour of the MPC106 still remained in combination with the
IBM 740 device.
First we found a high temperature dependency of the 740 CPU: at low to moderate
CPU die temperatures the error always occurs, at high CPU die temperatures it
does not (die temperature > 60C after removal of cooling fan).
Then we found that putting a logic analyser probe or oscilloscope probe on one
peticular signal, made the error occur under all temperature conditions. The
signal is A7 (CPU address bus).
Carefull measurements and investigation on and around A7 did not reveil anything
suspicious.
Now we have put a 10Kohm pull-up (3.3V) resistor on A7 and the problem does not
occur anymore.
Additional info: the CPU address bus is routed from CPU to MPC106 and to a debug
connector, so 3 loads on all nets. All tracks are routed in equivalent routing
layers (same impedance) and are of comparable length. There are no pull-up
resistors on the bus. The problem occurs both on a 66MHZ CPU bus frequency as on
a 50MHz bus frequency. The problem does not occur after a complete power-up
(cold reset), but only when *HRESET is asserted during operation (even when the
CPU is completely idling).
Can anyone explain these phenomena, maybe comment on what makes A7 so special?
Are other signals equally 'special'?
If the pullup resistor on A7 is really required, do we have to put pullups on
all address/address attributes lines?
Patrick Lambrechts
AGFA Healtcare - Imaging Systems - R&D Equipment
Tel. 32-3--444-6278
Fax. 32-3-444-6268
===========================================================
Motorola FAQ Database :
Product: MPC106
Category: Performance Issues
Problem: 6/8/99 - A customer is seeing problems when issuing
HRESET_ to a
MPC603p and MPC106 while the system is running. The problem
occurs when
HRESET is asserted in the window before AACK_ is asserted in
response to a
TS_ assertion. When HRESET_ is released the 106 will assert
AACK_ twice to
the 603r reset exception fetch at 0xfff00100 and hang without
giving out DBG_.
Power cycling is the only way to recover. The same behaviour is
observed if
HRESET_ falls between HIT_ assertion and AACK_ assertion. I have
pointed out
the FAQ entry on 106 startup problems but the customer says that
he meets all
of the criteria. The part marking is XPC106ARX66CG, S23460 (O?)
W001 Does
the minimum HRESET_ assertion differ between power on reset and
when the
system is running? Any ideas on what the problem could be?
Solution:
6/8/99 - MW - We have seen this type of behavior from a 106 when
the 106
samples TS_
asserted in the same clock cycle that it issues BG0_ to the
processor. The
106 perceives the TS_ as spurious and asserts AACK_ to bring its
internal
state machine to a known good state. However, without a DBG0_,
the processor
waits for the data tenure which the 106 never allows. This
appears to be the
problem with the customer's system.
The two cases where this has occured are:
1) The customer had the clock skewed to the processor too much
2) The customer had the PLL voltage (AVdd) at 3.3 Vdc on a part
that
required AVdd to be 2.5 Vdc
Here is the standard list of suggestions for 106 customers
having trouble right out
of reset.
1) Check to make sure that the 106's SDMA1/XATS_ signal (pin P1)
has a
pull-up. P1 MUST be pulled-up. If you system uses SDRAM, the
function of pin
P1 is XATS_ until the memory controller is properly initialized.
2) The 106's TRST_ signal (pin H13) should either be pulled-down
or asserted
along with HRESET_ in order to ensure the scan chain initializes
properly.
3) Check all of the pull-up/pull-down resistor recommendations
in Section 1.8.4.1
of the 106 hardware specifications.
4) Make sure that your system meets the minimum hard reset pulse
requirement
of 255 clocks plus 100 microseconds.
5) Clocking is very important in 106-based systems. Ideally,
there should be
zero clock skew between the 106 and the processor clock inputs.
There is some
allowance for jitter, but the processor clock input and the 106
clock input should
have less than 250 ps skew.
If these suggestions don't fix the problem, we will need more
information to
diagnose your problem. Please provide the following:
1) A block diagram of your system
2) Traces of the failure (please include the signals BRn_, BGn_,
TS_,
TT[0:4], TSIZ[0:2], TBST_, A[0:31], AACK_, DBGn_, TA_ and the
60x bus clock)
3) The configuration register settings for the MPC106 in your
system
4) The state of the configuration input signals (PLL[0:3],
BCTL0_, DBG0_,
FOE_, and RCS0_) during power-on reset.
Date: 6/8/1999
Ref No: PowerPC-4495
========================================================
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
- » [SI-LIST] question concerning a PowerPC740
