Lpc2000

This ones for Philips Apps

We are pondering our layout with a LPC2106. My layout man wonders if the 
2129 would be better (A/D and edge triggered interrupts)
My grizzle to him was the RAM size.

Do Phipips have any intention of producing a pin for pin compatable unit 
with more RAM? eg 64K

OK - call be Mr greedy!

Owen Mooney

Hello Owen (or Mr Greedy ;-)

You mentioned the LPC2129 which also has 2 CAN channels integrated. On
the other hand your feature list would also be valid for the LPC2114,
which has 128k Flash like the LPC2106 but only 16k RAM. 
Why am I making this differentiation, becasue we are working on a
device very similar to the LPC2114 with more memory but not with CAN
channels. So, it would have edge triggered Ints, would have ADC,
actually more channels 8 instead of 4 and it would have more memory.
The RAM is going to be up to 32k (sorry no 64K).
Now the tough part, WHEN!?

I know our design team is still working on it, which means it is at
least 6 months to available samples, could be towards the end of the
year. This is when I usually get burned giving schedules but
nevertheless, these dates are to my best knowledge. 

Hope this helps in making a decision.

btw. the device will not be 100% pin compatible because we listen to
all your guys inputs and improve our devices step by step. Single
voltage supply and a 32 kHz input for the RTC are the two features
that make pincompatibility impossible.

Regards, Robert


--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> This ones for Philips Apps
> 
> We are pondering our layout with a LPC2106. My layout man wonders if
the 
> 2129 would be better (A/D and edge triggered interrupts)
> My grizzle to him was the RAM size.
> 
> Do Phipips have any intention of producing a pin for pin compatable
unit 

> with more RAM? eg 64K
> 
> OK - call be Mr greedy!
> 
> Owen Mooney

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
> btw. the device will not be 100% pin compatible because we listen to
> all your guys inputs and improve our devices step by step. Single
> voltage supply and a 32 kHz input for the RTC are the two features
> that make pincompatibility impossible.
> 
> Regards, Robert

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.  

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.  

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.

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 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. 

> 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.

Regards, Robert

--- 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.