Lpc2000

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...>
wrote:
> 
> Hi,
> see some comments below.
> > 
> > If you are going to add a 32 kHz crystal input for the RTC, it
would
> > be very useful to make the RTC power independant of the rest of
the
> > chip.  The Atmel AT91M55800A did this very well.  The RTC can be
used
> > to control the power to the rest of the chip for timer based power
> > savings.  The RTC runs on a separate Vdd and can be powered by a
Li
> > coin cell for years.  
> 
> We need to combine power down with running the RTC -> no separate
Vdd
> for the RTC.

I guess I am not sure I understand why you would have a separate RTC
if you are not going to provide for a separate backup battery input. 
The point of using a 32 kHz xtal for the RTC is to allow very low
currents when the CPU is not running.  Otherwise it can be done the
way you currently implement it, or leave it out altogether and let the
SW do it.  

What is the advantage of an RTC with 32 kHz xtal if you don't provide
for battery backup?  


> > I would also suggest that the PLL be designed so that the 32 kHz
clock
> > can be the reference for the master clock PLL to save the need
for a
> > second crystal or oscillator.  
> > 
> > These suggestions can save around $2 in system cost in a small
> > embedded system which is what your parts are targeted to.  
> > 
> A PLL that is as well accurate (low jitter) as low power while it
> multiplies by factors >1000 does, to my best knowledge, not exist.
> Having CAN as one of our standard interfaces, we need to support
> "even" frequencies such as 16 MHz, 24,48,60 which can all be used to
> get the standard CAN baudrate while still providing good enough
> baudrates for UARTs. Unfortunately 32768 Hz is not a good base
> frequency for any serial communication that needs standard
transmition
> rates. The second (32kHz) oscillator is optional for those who want
to
> use the RTC during Power Down. I am curious how many applications
will
> actually be using this feature. 

I expect that the way you are going to implement it, not many designs
will be using the RTC hardware other than to save writing a bit of
software.  I assume you will still provide for dividing down the main
clock, so not many will use the 32 kHz xtal.  

When I do the math, I get a ratio of 1,831.0546875 between 60 MHz and
32.768 kHz.  The integer 1831 puts the main freq at 59,998,208 which
is within 30 ppm, as good as most HF xtals.  I have also found good
ratios for all standard serial baud rates with better than 70 ppm
error.  

The jitter you are referring to may be an issue with some designs such
as CAN, but it is low enough for many such as standard serial baud
rates.  The point is to not design your chips for a single purpose,
but to make them flexible so that they can optimize *many different*
apps.  You can design the chip to support HF xtals for CAN work and
still allow a single 32 kHz xtal for low cost apps that need an RTC
with battery backup. 


> > BTW, if you go to a single power voltage approach, which voltage
will
> > it be, 3.3 or 1.8?  I don't understand how you can run the core
from
> > 3.3 volts and I don't understand how you can have 5 volt tolerant
IO
> > (or 3.3 for that matter) with 1.8 volt powered IOs.  You're not
> > putting an LDO inside the chip are you?  That's one of the
features
> > they use on the newest CPLDs that ruin their quiescent power
ratings.
> 
> It is going to be 3.3V.  Hint: low power DC-DC internal
> 
> Another fact: in processes 0.18 um and smaller it will be very close
> to impossible to get quiescent current in the range of 1 uA.
> Want to know more, find some articles about deep submicron processes
> and leakage.

Ok, a switched cap on chip is a good idea.  But other parts that use
LDO have quiescent currents of > 1 mA.  That pretty much ruins them
for any low power apps.  Certainly at 180 nm you can still get the
quiescent current below 100 uA, no?  And the RTC can be made in an
isolated portion of the chip to allow low enough quiescent current to
run from a backup battery and still work with the rest of the chip. 
Like I said, look at how the AT91M55800 does it.  That does everything
I am asking about and everything you are describing.  Why can Atmel do
it and Philips can't? 

Your current data sheets show a typ of 50 uA with a max of 500 uA over
temp.  You might consider doing what the memory makers do and
providing a low power version that is graded more carefully to be
under 100 uA over temp.  That would help a lot with battery life (5x)
for the CPU.