Their are both historical and practical reasons for the default values in the
SDK in regards to the PLL multiplier associated with each component that might
Originally the PLL mulitplier and the DSP56F80x components was set at 72 Mhz to
best meet what we believed to be the fastest rate at which the combination of
worst case timing in conjunction with the speed of the RAM on the EVMs and for
another reason that really had nothing to do with the rate at which external RAM
could run. This was thought to be the safest approach. Latter we began to modify
our thinking some. We also modify the PLL mulitplier to access external memory
at full rate and do not experience problems. This works because of what Art has
described that when you are not at worst case voltage and temperature the
performance the components are much better than in the data sheet. To me this
is a perfectly valid thing to do while in development. Run at full rate and use
the extra memory and speed available to debug your application. Once you are go
to your final target throttle down the speed of any external memory accesses to
the rate that satisfies the speed of !
e external RAM you have chosen.
In the case of the DSP56F826/827 EVM we set the PLL multiplier to run at full
rate even though this doesn't meet the worst case data sheet specifications of
the RAM on the 826/827 EVM. But emperatical testing have shown no problems and
the EVM is intended only for development. We no longer felt that 72 Mhz was the
proper default because this was probably only unneccessarily running customers
programs at a slower rate than was appropriate for their final target hardware
and confusing customers evalauting the parts as to the best possibel
performance. We set the default rates on the 826/827 EVMs to be full rate
because of these reasons. In regards to the DSP56F80x did not modify the deafult
rate because the product had already been fielded and we try quite hard to not
make modifiactions in the SDK that could have unexpected results to existing
The bottom line is that you need to set the PLL multiplier to be correct for
your end system and its end environment. But while in development in can be
beneficial to break the data sheet rules and in this case it works out when
accessing external RAM faster. Also in regards to the DSP56F826/827 we have
recently posted a FAQ on accessing slower external RAM at a faster rate than
specified in the data sheet by limiting the capacitance of the external memory
lines to 20 pf instead of the data sheet test conditions of 50 pf.
- Bill -----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, December 06, 2002 12:59 PM
To: Johnson, Jerry; Roger Flor;
Subject: RE: [motoroladsp] SDK default CPU clock rate, DSP56F80x
The 80MHz clock rate will probably work in most if not all systems, due to the
fact that most RAM chips have access times that are better than the "worst-case"
value that is specified on the data sheet. This does not, however, guarantee
that it will work for all devices under all combinations of power supply voltage
and temperature. The only way to guarantee that, is to compare the specified
maximum access times and minimum pulse width times of the memory device
(including any delays due to address decoding and/or address/data bus buffers),
to the required "zero-wait-state" times in the DSP56F805 data sheet. Of course,
on the EVM module, there are none of these "extra" delays, so the calculation is
1) From going through the DSP56F805/D Rev. 8.0, 11/2002 data sheet, and the
GS72116TP Rev. 1.04a 10/2002 data sheet, the most critical timing parameter is
the minimum write pulse width, as shown below:
DSP56F807 80MHz minimum write pulse width = 7.5ns
GS72116TP-12 minimum write pulse width = 8.0ns
GS72116TP-10 minimum write pulse width = 7.0ns
GS72116TP-8 minimum write pulse width = 5.5ns
GS72116TP-7 minimum write pulse width = 5.0ns
2) Since the DSP56F805EVM module uses the 12-nanosecond GS72116TP-12 RAM chip,
it is not guaranteed to work with zero wait states at a processor clock
frequency of 80MHz. The 10-nanosecond GS72116TP-10 RAM chip would be required
in this case. Most of the experienced hardware design engineers I am acquainted
with would require at least a 1-nanosecond margin to be on the safe side, so
this would require you to use the 8-nanosecond GS72116TP-8 RAM chip.
3) While your chance of running across a case where the 12-nanosecond chip
actually caused a failure is quite low, it is not zero. If your systems are
used in critical control, monitoring, and safety applications as ours are, then
even this very small possibility of failure is unacceptable. Especially when
the potential for failure is easily demonstrated by a simple calculation like
the one shown above.
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
Phone: 604 433-4644
FAX: 604 433-5570
From: Johnson, Jerry [mailto:]
Sent: Friday, December 06, 2002 6:20 AM
To: 'Roger Flor';
Subject: RE: [motoroladsp] SDK default CPU clock rate, DSP56F80x There have been earlier postings about the speed issue, and the default. As far
as I know there are no problems with 80Mhz operation. I have been initializing
it that way for over a 18 months, on several hardware platforms. At the higher
internal clock rate, there is more power dissapation, but I have not seen any
issues yet. The peripheral bus rate will default to 40Mhz instead of 36 Mhz,
but that is probably what you want to happen.
From: Roger Flor [mailto:]
Sent: Thursday, December 05, 2002 6:07 PM
Subject: [motoroladsp] SDK default CPU clock rate, DSP56F80x Hello!
I am using a DSP56F805 EVM.
Page 3-47 of the Embedded SDK Targeting Motorola DSP56F80x Platform manual
says that the default SDK setting for the CPU clock is 72MHz. Is there any
special reason for this? Why not 80MHz? Is there anything I should be aware
of if I set the CPU clock to 80 MHz?
Thanks in advance Roger
The new MSN 8: advanced junk mail protection and 2 months FREE*
Note: If you do a simple "reply" with your email client, only the author of this
message will receive your answer. You need to do a "reply all" if you want your
answer to be distributed to the entire group.
About this discussion group:
More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> .