Linux x uClinux for ColdFires: what is the best for what?

[Ricardo Raupp]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 

Hi people

Could someone show me a comparsion between Linux and uClinux for ColdFires?

I´m deciding between a V2 (5274L) x a V4 (54450) core.

The main diference I noticed ( or almost the) is V4 has MMU, wich enable Linux on it.

The chips cost is very close...I´m tending to a V4 chip..

Thanks

 

Ricardo Raupp

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

[Pickering Stephen]

-----Original Message-----
From: Ricardo Raupp <ricardo@...>
Sent: 29 April 2008 23:12
To: stephen.pickering@... <stephen.pickering@...>
Subject: [ColdFire] Linux x uClinux for ColdFires: what is the best for what?


Hi people
Could someone show me a comparsion between Linux and uClinux for ColdFires?
I´m deciding between a V2 (5274L) x a V4 (54450) core.
The main diference I noticed ( or almost the) is V4 has MMU, wich enable Linux on it.
The chips cost is very close...I´m tending to a V4 chip..
Thanks

Ricardo Raupp
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

Ricardo Raupp wrote:
>  
> Hi people
> Could someone show me a comparsion between Linux and uClinux for ColdFires?
> I´m deciding between a V2 (5274L) x a V4 (54450) core.
> The main diference I noticed ( or almost the) is V4 has MMU, wich enable
> Linux on it.
> The chips cost is very close...I´m tending to a V4 chip..
> Thanks
>  

The difference between ucLinux and Linux is that ucLinux works without
an MMU (you can also use it on a cpu with an MMU if you want).  ucLinux
works mostly like Linux, but has a few limitations:

You don't get protection between processes memory spaces (obviously), so
a bad process can stomp on good processes.

You can't use "fork" - you must use "vfork" to replace "fork + exec"
combinations.  This may mean changing existing Linux code to port it to
ucLinux - for most applications, it's a minor issue, but it can be a
problem if you want to run traditional unix-style forking servers.

You can't use virtual memory.  Even if you are not using external page
files, virtual memory and the MMU can help avoid fragmentation of main
memory.

I'm not sure on this one, but I don't think you can nmap files in ucLinux.

For small systems where you have complete control over which processes
will run on the system, ucLinux is often perfectly good, and can be
faster than plain Linux since MMU's can add a delay to memory access.


As for the V2 versus the V4 - you get more processing power for your
money with a V4, but more microcontroller-style peripherals with most V2
devices, and a V2 board is going to be easier and cheaper to make.  But
that depends on the sort of boards you are used to making.

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Seymour David-ra2693]

Thanks Stephen. Keep them coming if you see them.
Mr. Brown beat me to the reply.  Otherwise I would have helped.
Regards,
David

David E Seymour
Come to FTF 2008 June 16th through the 19th in Orlando

http://www.freescale.com/ftf 


-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of Pickering Stephen
Sent: Wednesday, April 30, 2008 12:37 AM
To: Seymour David
Subject: RE: [ColdFire] Linux x uClinux for ColdFires: what is the best for what?



-----Original Message-----
From: Ricardo Raupp <ricardo@...>
Sent: 29 April 2008 23:12
To: stephen.pickering@... <stephen.pickering@...>
Subject: [ColdFire] Linux x uClinux for ColdFires: what is the best for what?


Hi people
Could someone show me a comparsion between Linux and uClinux for ColdFires?
I´m deciding between a V2 (5274L) x a V4 (54450) core.
The main diference I noticed ( or almost the) is V4 has MMU, wich enable Linux on it.
The chips cost is very close...I´m tending to a V4 chip..
Thanks

Ricardo Raupp
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

David,

I'm curious about this statement:

David Brown wrote:
> As for the V2 versus the V4 - you get more processing power for your
> money with a V4, but more microcontroller-style peripherals with most
> V2 devices, and a V2 board is going to be easier and cheaper to make.  
> But that depends on the sort of boards you are used to making.

What do you consider more MCUish that we've put on a V2 versus what
we've put on a V4.  If you look at a part like the MCF5270 or MCF5208
and the MCF54450, they are similar apart from the cores.

If you're thinking about single-chip flash devices, I agree, that the
differences are greater.  We generally don't put ADCs on devices that
run from SDRAM, because we usually can't afford the pins and customers'
ADC requirements tend to vary widely.  Of course, if enough people ask,
that is something that can change.

For systems that run from SDRAM, especially the double data rate
varieties, I'm not sure there's a huge world of difference between the
board design for something like the MCF5208 and for the MCF54450.

Both support DDR1 and mobile DDR (LPDDR) SDRAM.  The MCF5208 has
dedicated DQ, DQS, and DM lines for the DDR while the address bus is
shares among all memories.  The MCF54450 has a completely dedicated DDR
bus, so I tend to think that board layout is of similar complexity for
both.  Of course, the DDR clock on the MCF5208 tops out at 83.33 MHz
(well, if you're not overclocking :-) vs. 120 (or is it 133) MHz for the
MCF54450, so a little more attention to high frequency stuff is
necessary for the latter.

Best regards,

John Bodnar
Systems Engineer
Microcontroller Solutions Group
Freescale Semiconductor, Inc.

--
POPI Classification
[ ]General Business Information
[x]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Greg Ungerer]

Hi David, Ricardo,

David Brown wrote:

> Ricardo Raupp wrote:
>>  
>> Hi people
>> Could someone show me a comparsion between Linux and uClinux for
>> ColdFires?
>> I´m deciding between a V2 (5274L) x a V4 (54450) core.
>> The main diference I noticed ( or almost the) is V4 has MMU, wich
>> enable Linux on it.
>> The chips cost is very close...I´m tending to a V4 chip..
>> Thanks
>>  
>
> The difference between ucLinux and Linux is that ucLinux works without
> an MMU (you can also use it on a cpu with an MMU if you want).  ucLinux
> works mostly like Linux, but has a few limitations:
>
> You don't get protection between processes memory spaces (obviously), so
> a bad process can stomp on good processes.
>
> You can't use "fork" - you must use "vfork" to replace "fork + exec"
> combinations.  This may mean changing existing Linux code to port it to
> ucLinux - for most applications, it's a minor issue, but it can be a
> problem if you want to run traditional unix-style forking servers.
>
> You can't use virtual memory.  Even if you are not using external page
> files, virtual memory and the MMU can help avoid fragmentation of main
> memory.
>
> I'm not sure on this one, but I don't think you can nmap files in ucLinux.

You can use mmap(), but there is limitations.
For the details have a look at the file Documentation/nommu-mmap.txt
in any modern 2.6.x kernel version source tree.

Regards
Greg

> For small systems where you have complete control over which processes
> will run on the system, ucLinux is often perfectly good, and can be
> faster than plain Linux since MMU's can add a delay to memory access.
>
>
> As for the V2 versus the V4 - you get more processing power for your
> money with a V4, but more microcontroller-style peripherals with most V2
> devices, and a V2 board is going to be easier and cheaper to make.  But
> that depends on the sort of boards you are used to making.
>
> ---
> coldfire@...              Send a post to the list.
> coldfire-join@...        Join the list.
> coldfire-digest@...    Join the list in digest mode.
> coldfire-leave@...     Leave the list.
>
>

--
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@...
Secure Computing Corporation                PHONE:       [phone]
825 Stanley St,                             FAX:         [phone]
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

John Bodnar wrote:

>
> David,
>
> I'm curious about this statement:
>
> David Brown wrote:
>> As for the V2 versus the V4 - you get more processing power for your
>> money with a V4, but more microcontroller-style peripherals with most
>> V2 devices, and a V2 board is going to be easier and cheaper to make.  
>> But that depends on the sort of boards you are used to making.
>
> What do you consider more MCUish that we've put on a V2 versus what
> we've put on a V4.  If you look at a part like the MCF5270 or MCF5208
> and the MCF54450, they are similar apart from the cores.
>
> If you're thinking about single-chip flash devices, I agree, that the
> differences are greater.  We generally don't put ADCs on devices that
> run from SDRAM, because we usually can't afford the pins and customers'
> ADC requirements tend to vary widely.  Of course, if enough people ask,
> that is something that can change.
>
> For systems that run from SDRAM, especially the double data rate
> varieties, I'm not sure there's a huge world of difference between the
> board design for something like the MCF5208 and for the MCF54450.
>
> Both support DDR1 and mobile DDR (LPDDR) SDRAM.  The MCF5208 has
> dedicated DQ, DQS, and DM lines for the DDR while the address bus is
> shares among all memories.  The MCF54450 has a completely dedicated DDR
> bus, so I tend to think that board layout is of similar complexity for
> both.  Of course, the DDR clock on the MCF5208 tops out at 83.33 MHz
> (well, if you're not overclocking :-) vs. 120 (or is it 133) MHz for the
> MCF54450, so a little more attention to high frequency stuff is
> necessary for the latter.
>
> Best regards,
>
> John Bodnar
> Systems Engineer
> Microcontroller Solutions Group
> Freescale Semiconductor, Inc.
>

Certainly the V2 microcontrollers with flash and other peripherals
built-in are a different matter, and ADCs are not something you
generally want in a high performance processor anyway.

I was making a more general hand-waving comment about the complexities
of boards with higher performance processors.  Perhaps it's a bit
unreasonable to talk about microcontroller-style peripherals (although
I'm used to the MCF5234, with a TPU - you don't have v4 cores with a
TPU, do you?).  But I still think board complexity is relevant.

With higher frequency and higher performance devices, you have to take
more care with your memories and buses, and you have more worries about
your power supplies and decoupling.  You often need more voltage levels
(the v4 has 1.5V for the core, 1.8/2.5V for the memory buses, and 3.3V
for IO - the 5234 with which I am most familiar has 1.5V core and
everything else at 3.3V).  It is typically easier on slower devices to
attach other peripherals to the external buses without glue logic, level
converters, etc.

I haven't used any v4 cores, so my rough comments are only based on my
reading of datasheets and application notes.  But our move from the
older, slower MC68832 to the MCF5234 required a bit step in board
complexity and quality - I would plan for another step up, though
perhaps not as large, in doing a v4 board.

I you want to tell me that I'm wrong, and that the MCF5445x is as easy
to use as the MCF5234 (baring the lack of a TPU), then go ahead - I'll
listen!  I like the ColdFire architecture, and if the v4 will give me a
lot more processing power for little more complexity, then it's
definitely good to know.

mvh.,

David
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

David Brown wrote:
> With higher frequency and higher performance devices, you have to take
> more care with your memories and buses, and you have more worries
> about your power supplies and decoupling.  You often need more voltage
> levels (the v4 has 1.5V for the core, 1.8/2.5V for the memory buses,
> and 3.3V for IO - the 5234 with which I am most familiar has 1.5V core
> and everything else at 3.3V).  It is typically easier on slower
> devices to attach other peripherals to the external buses without glue
> logic, level converters, etc.

Well, therein lies the rub.  As soon as you start supporting DDR of any
kind, you get away from being able to produce a device with only two
voltage rails.  The MCF523x family only supports SDR, so it never had a
reason to support other than just I/O and VDD supplies.

The MCF5445x still maintains a 3.3V general-purpose memory bus (FlexBus)
for connecting up everything else but your SDRAM.  In the future, I'm
looking to move the FlexBus to its own dedicated supply rail in order to
support flashes and FPGAs/CPLDs with 1.8V I/Os as a means of reducing
I/O power.  This would up the number of supply rails to four (core,
SDRAM, FlexBus, and digital I/O), but you could still run the FlexBus at
3.3V, if desired.

> I haven't used any v4 cores, so my rough comments are only based on my
> reading of datasheets and application notes.  But our move from the
> older, slower MC68832 to the MCF5234 required a bit step in board
> complexity and quality - I would plan for another step up, though
> perhaps not as large, in doing a v4 board.

I think we've made the MCF5445x family quite friendly for board design,
especially on the 256-ball MAPBGA variants.  We're trying to take the
lessons we've learned from doing the package and substrate design for
those devices and apply them to new higher end parts going forward.

> I you want to tell me that I'm wrong, and that the MCF5445x is as easy
> to use as the MCF5234 (baring the lack of a TPU), then go ahead - I'll
> listen!  I like the ColdFire architecture, and if the v4 will give me
> a lot more processing power for little more complexity, then it's
> definitely good to know.

I think I mentioned it before, but I am hardly an expert on board
design, so I could be wrong on all counts :-(  That said, I had plenty
of help from some real experts on the MCF5445x, so I think we've made
that family one of our better examples of how to pin out and package a
device.  Of course, by saying as much, I'm now setting myself up for pot
shots from the peanut gallery, so let the shooting commence :-)

John Bodnar
Systems Engineer
Microcontroller Solutions Group
Freescale Semiconductor, Inc.

--
POPI Classification
[ ]General Business Information
[x]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Ricardo Raupp]

John/David
..thanks for your help ...

Well...
My first conclusion :
V2 x V4 core and Linux x uCLinux issues are totally dependent, rigth?

1- Considering my company have reasonable experienced designers in control
embedded applications flows / state machines / hardwares accesses, low_level
drivers code, etc ( I don´t use OS ...yet...) .  we would feel very
confortable / confident enougth to handle uCLinux, taking its advantages due
to small overheads e getting closer to hardware control..and that full Linux
would not give us more usefull resources than uCLinux .considering our
application is an ethernet based PLC (no video, .MP3,etc...).
Rigth or wrong?

2- If I not use DDR memory, only SD_DRAM or ordinary  SRAM, the V2 flex bus
is pretty enough to it.
Rigth or wrong?

3- In practical ways, what is the advantages of Linux over uCLinux?What
could I do with linux I could not with uCLinus?or how much more effort shoud
I do in one then the other?

4- Could someone explain me why / whnen should I use SDR / DDR / DDR2 /
Mobile etc..devices?It makes a difference
when chosing between V2 x V4, rigth?

5- uCLinux was made because the MMU lack, or due to  a necessity of a lower
level management / hardware constraints considerations ? I mean..uCLinux is
a kind of trick for not mmu enable mcus?

6- A V2 requirements, like pcb cares, powers, etc...is much(?) more simpler
than a (full use) V4?

Ricardo Raupp


----- Original Message -----
From: "John Bodnar" <john.bodnar@...>
To: "Ricardo" <ricardo@...>
Sent: Thursday, May 01, 2008 3:12 PM
Subject: Re: [ColdFire] Linux x uClinux for ColdFires: what is the best for
what?

> David Brown wrote:
>> With higher frequency and higher performance devices, you have to take
>> more care with your memories and buses, and you have more worries about
>> your power supplies and decoupling.  You often need more voltage levels
>> (the v4 has 1.5V for the core, 1.8/2.5V for the memory buses, and 3.3V
>> for IO - the 5234 with which I am most familiar has 1.5V core and
>> everything else at 3.3V).  It is typically easier on slower devices to
>> attach other peripherals to the external buses without glue logic, level
>> converters, etc.
>
> Well, therein lies the rub.  As soon as you start supporting DDR of any
> kind, you get away from being able to produce a device with only two
> voltage rails.  The MCF523x family only supports SDR, so it never had a
> reason to support other than just I/O and VDD supplies.
>
> The MCF5445x still maintains a 3.3V general-purpose memory bus (FlexBus)
> for connecting up everything else but your SDRAM.  In the future, I'm
> looking to move the FlexBus to its own dedicated supply rail in order to
> support flashes and FPGAs/CPLDs with 1.8V I/Os as a means of reducing I/O
> power.  This would up the number of supply rails to four (core, SDRAM,
> FlexBus, and digital I/O), but you could still run the FlexBus at 3.3V, if
> desired.
>
>> I haven't used any v4 cores, so my rough comments are only based on my
>> reading of datasheets and application notes.  But our move from the
>> older, slower MC68832 to the MCF5234 required a bit step in board
>> complexity and quality - I would plan for another step up, though perhaps
>> not as large, in doing a v4 board.
>
> I think we've made the MCF5445x family quite friendly for board design,
> especially on the 256-ball MAPBGA variants.  We're trying to take the
> lessons we've learned from doing the package and substrate design for
> those devices and apply them to new higher end parts going forward.
>
>> I you want to tell me that I'm wrong, and that the MCF5445x is as easy to
>> use as the MCF5234 (baring the lack of a TPU), then go ahead - I'll
>> listen!  I like the ColdFire architecture, and if the v4 will give me a
>> lot more processing power for little more complexity, then it's
>> definitely good to know.
>
> I think I mentioned it before, but I am hardly an expert on board design,
> so I could be wrong on all counts :-(  That said, I had plenty of help
> from some real experts on the MCF5445x, so I think we've made that family
> one of our better examples of how to pin out and package a device.  Of
> course, by saying as much, I'm now setting myself up for pot shots from
> the peanut gallery, so let the shooting commence :-)
>
> John Bodnar
> Systems Engineer
> Microcontroller Solutions Group
> Freescale Semiconductor, Inc.
>
> --
> POPI Classification
> [ ]General Business Information
> [x]Freescale Internal Use [ ]Freescale Confidential Proprietary
>
> ---
> coldfire@...              Send a post to the list.
> coldfire-join@...        Join the list.
> coldfire-digest@...    Join the list in digest mode.
> coldfire-leave@...     Leave the list.
>
>
>
> __________ NOD32 3067 (20080430) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

Ricardo Raupp wrote:

No comments on the Linux questions, but...
> 2- If I not use DDR memory, only SD_DRAM or ordinary  SRAM, the V2
> flex bus is pretty enough to it.
> Rigth or wrong?

Depends on which V2 device you use.  FlexBus is not used on all of them.

Doesn't matter, though.  You can bolt whatever external memory interface
is on a ColdFire device up to a SRAM.

But, do you really want to use SRAM?  It's easy to interface, but
choices are limited, and SRAM no longer has the commodity pricing it had
back in the days when every 486 motherboard came with 128 or 256 Kbytes
of L2 cache.

> 4- Could someone explain me why / whnen should I use SDR / DDR / DDR2
> / Mobile etc..devices?It makes a difference
> when chosing between V2 x V4, rigth?

SDRAM gets you more RAM for less money.  For a couple of dollars, you
can get 32 or 64 Mbytes of DDR1 SDRAM.  To get that much SRAM, you'd
have to spend a lot more.

The type of SDRAM you use and the ColdFire core you use are totally
independent choices, except that some ColdFire devices support more
SDRAM types than others.  Currently, the support is like this:

MCF523x family - 3.3V SDR only
MCF5270/1/2 family - 3.3V SDR only
MCF5274/5 family - DDR1 only
MCF528x family - 3.3V SDR only
MCF5207/8 - 1.8, 2.5, 3.3V SDR, DDR1, LPDDR (mobile)
MCF5227x family - 1.8, 2.5, 3.3V SDR, DDR1, LPDDR (mobile)
MCF532x family - 1.8, 2.5, 3.3V SDR, DDR1, LPDDR (mobile)
MCF537x family - 1.8, 2.5, 3.3V SDR, DDR1, LPDDR (mobile)
MCF547x family - 3.3V SDR and DDR1
MCF548x family - 3.3V SDR and DDR1
MCF5445x family - DDR1, DDR2, LPDDR (mobile)

LPDDR is the JEDEC standard name for Mobile DDR, which is essentially a
trade name used by Micron, Samsung, etc.

> 6- A V2 requirements, like pcb cares, powers, etc...is much(?) more
> simpler than a (full use) V4?

Not necessarily.  Depends on operating frequency and what type of
SDRAM.  Generally speaking, the ColdFire devices that we build intended
for use with SDRAM require multiple supply voltages.  The MCU devices we
produce have internal flash and SRAM, usually do not support SDRAM, and
require just one voltage level.

-- John

> ----- Original Message ----- From: "John Bodnar"
> <john.bodnar@...>
> To: "Ricardo" <ricardo@...>
> Sent: Thursday, May 01, 2008 3:12 PM
> Subject: Re: [ColdFire] Linux x uClinux for ColdFires: what is the
> best for what?
>
>
>> David Brown wrote:
>>> With higher frequency and higher performance devices, you have to
>>> take more care with your memories and buses, and you have more
>>> worries about your power supplies and decoupling.  You often need
>>> more voltage levels (the v4 has 1.5V for the core, 1.8/2.5V for the
>>> memory buses, and 3.3V for IO - the 5234 with which I am most
>>> familiar has 1.5V core and everything else at 3.3V).  It is
>>> typically easier on slower devices to attach other peripherals to
>>> the external buses without glue logic, level converters, etc.
>>
>> Well, therein lies the rub.  As soon as you start supporting DDR of
>> any kind, you get away from being able to produce a device with only
>> two voltage rails.  The MCF523x family only supports SDR, so it never
>> had a reason to support other than just I/O and VDD supplies.
>>
>> The MCF5445x still maintains a 3.3V general-purpose memory bus
>> (FlexBus) for connecting up everything else but your SDRAM.  In the
>> future, I'm looking to move the FlexBus to its own dedicated supply
>> rail in order to support flashes and FPGAs/CPLDs with 1.8V I/Os as a
>> means of reducing I/O power.  This would up the number of supply
>> rails to four (core, SDRAM, FlexBus, and digital I/O), but you could
>> still run the FlexBus at 3.3V, if desired.
>>
>>> I haven't used any v4 cores, so my rough comments are only based on
>>> my reading of datasheets and application notes.  But our move from
>>> the older, slower MC68832 to the MCF5234 required a bit step in
>>> board complexity and quality - I would plan for another step up,
>>> though perhaps not as large, in doing a v4 board.
>>
>> I think we've made the MCF5445x family quite friendly for board
>> design, especially on the 256-ball MAPBGA variants.  We're trying to
>> take the lessons we've learned from doing the package and substrate
>> design for those devices and apply them to new higher end parts going
>> forward.
>>
>>> I you want to tell me that I'm wrong, and that the MCF5445x is as
>>> easy to use as the MCF5234 (baring the lack of a TPU), then go ahead
>>> - I'll listen!  I like the ColdFire architecture, and if the v4 will
>>> give me a lot more processing power for little more complexity, then
>>> it's definitely good to know.
>>
>> I think I mentioned it before, but I am hardly an expert on board
>> design, so I could be wrong on all counts :-(  That said, I had
>> plenty of help from some real experts on the MCF5445x, so I think
>> we've made that family one of our better examples of how to pin out
>> and package a device.  Of course, by saying as much, I'm now setting
>> myself up for pot shots from the peanut gallery, so let the shooting
>> commence :-)
>>
>> John Bodnar
>> Systems Engineer
>> Microcontroller Solutions Group
>> Freescale Semiconductor, Inc.
>>
>> --
>> POPI Classification
>> [ ]General Business Information
>> [x]Freescale Internal Use [ ]Freescale Confidential Proprietary
>>
>> ---
>> coldfire@...              Send a post to the list.
>> coldfire-join@...        Join the list.
>> coldfire-digest@...    Join the list in digest mode.
>> coldfire-leave@...     Leave the list.
>>
>>
>>
>> __________ NOD32 3067 (20080430) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>
> ---
> coldfire@...              Send a post to the list.
> coldfire-join@...        Join the list.
> coldfire-digest@...    Join the list in digest mode.
> coldfire-leave@...     Leave the list.
>

--
POPI Classification
[ ]General Business Information
[x]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Bob Furber]

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: ******: 6.100000 Price & DodgySrc=1.0, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

John Bodnar wrote:

> Well, therein lies the rub.  As soon as you start supporting DDR of any
> kind, you get away from being able to produce a device with only two
> voltage rails.  The MCF523x family only supports SDR, so it never had a
> reason to support other than just I/O and VDD supplies.
>
> The MCF5445x still maintains a 3.3V general-purpose memory bus (FlexBus)
> for connecting up everything else but your SDRAM.  In the future, I'm
> looking to move the FlexBus to its own dedicated supply rail in order to
> support flashes and FPGAs/CPLDs with 1.8V I/Os as a means of reducing
> I/O power.  This would up the number of supply rails to four (core,
> SDRAM, FlexBus, and digital I/O), but you could still run the FlexBus at
> 3.3V, if desired.

While on this topic, can we talk you into reducing the minimum FlexBus
supply to 1.5v or less, to support the newer DDR3 memories and lower
voltage memories in the pipeline? And, perhaps even talk you into
reducing core voltages?

This would address two issues:

1. Memory availability: Yesterday's 3.3v SDRAM will be increasingly
harder to source. DDR will follow. So, for a new product, we really want
to design with tomorrow's memories in the hopes that they will be around
a little longer. If the product is any good, a life cycle of 10 to 15
years is not unreasonable. Try sourcing SDRAM 15 years hence ;o)

2. As circuits become smaller, power dissipation becomes a significant
issue. I believe power consumption is roughly proportional to V squared.
So, a small drop in supply voltage means a big drop in power
consumption. Smaller circuits mean shorter traces which translate into
less problems with high frequency signals (or, they make it possible to
run at higher frequency). Also, PCBs are priced by the square inch.

My experience with the MCF5208 was that the 3 power supplies (1.5v core,
1.8v DDR & flash and 3.3v I/O) were an irritant. But the board was a
dream in terms of low power consumption and heat dissipation for
significant performance. In hindsight, the power supply chips could have
been much smaller (less of an irritant).

And, oh, yes, I should mention that FlexBus with DDR is addictive. Once
tasted you can never go back. It makes for cleaner, more compact,
quieter board layouts.

Thanks,

Bob Furber
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

Bob Furber wrote:
> While on this topic, can we talk you into reducing the minimum FlexBus
> supply to 1.5v or less, to support the newer DDR3 memories and lower
> voltage memories in the pipeline?

That's not really possible.  The JEDEC standard for DDR3 specifies a
minimum operating frequency of 300 MHz, which means a data rate of 600
MHz, and that entails a PLL running at 1.2 GHz.  That's just not
realistic for the kinds of devices we're doing and for which customers
are asking.

Besides, at those frequencies we cannot combine the FlexBus and the
SDRAM bus.  They have to be split, as we've done on the 547x, 548x, and
5445x, so the FlexBus supply no longer depends on the SDRAM voltage.  
These same devices power the FlexBus from the 3.3V digital I/O rail,
but, in the future, I'm looking to give the FlexBus its own supply rail
in order to support things like flashes and FPGAs/CPLDs with 1.8V I/Os.

> And, perhaps even talk you into reducing core voltages?

Core voltage is entirely dependent on process technology, when we change
technology, we inevitably change core VDD.

> This would address two issues:
>
> 1. Memory availability: Yesterday's 3.3v SDRAM will be increasingly
> harder to source. DDR will follow. So, for a new product, we really
> want to design with tomorrow's memories in the hopes that they will be
> around a little longer. If the product is any good, a life cycle of 10
> to 15 years is not unreasonable. Try sourcing SDRAM 15 years hence ;o)

Well, the funny thing is that several DRAM vendors we spoke to 5 years
ago, when we first started planning to support DDR, told us to drop SDR
support in a hurry, because it wouldn't be around any longer.

Fast forward 5 years, and you can still buy SDR, and, in my experience,
it's what most customers are still using despite our support for newer
SDRAM options like mobile SDR (1.8V and 2.5V), DDR1, and LPDDR (mobile
DDR)...

> 2. As circuits become smaller, power dissipation becomes a significant
> issue. I believe power consumption is roughly proportional to V
> squared. So, a small drop in supply voltage means a big drop in power
> consumption. Smaller circuits mean shorter traces which translate into
> less problems with high frequency signals (or, they make it possible
> to run at higher frequency). Also, PCBs are priced by the square inch.

Again, technology mandates core VDD.  Our MPU devices are currently down
to 1.5V for the core logic, and as we move to 90 nm, that will drop to
1.2V for the low-power process and 0.9V for high-performance devices.  
That's not backwards either.  Low-power 90 nm processes generally run at
1.2V in order to reduce leakage, while the higher performance bulk 90 nm
process is specified at 0.9V in order to maximize frequency at the
expense of leakage.

> My experience with the MCF5208 was that the 3 power supplies (1.5v
> core, 1.8v DDR & flash and 3.3v I/O) were an irritant. But the board
> was a dream in terms of low power consumption and heat dissipation for
> significant performance. In hindsight, the power supply chips could
> have been much smaller (less of an irritant).

Yes, but you wouldn't want us to regulator that 1.5V core on-chip, right :-)

Thank you for confirming what I've said about mobile DDR all along.  We
often hear low-power used incorrectly.  People say low-power when they
really mean they want low current draw.  But that's not always true.  We
deal with numerous "industrial" customers who build things in small
metal boxes with no ambient air flow.  For them, low-power really means
reduced heat dissipation.  Lower current draw often comes with that, too.

> And, oh, yes, I should mention that FlexBus with DDR is addictive.
> Once tasted you can never go back. It makes for cleaner, more compact,
> quieter board layouts.

Thank you for your kind words about what I've always called the
pseudo-split bus.  You've just confirmed what I've always wanted
customers to experience when using it.  Clean, compact, quiet, and
low-power.

BTW, I've seen your MCF5208 board, of course, and it is "elegant" to use
the word in its engineering form :-)

Best regards,

John Bodnar
Systems Engineer
Microcontroller Solutions Group
Freescale Semiconductor, Inc.

--
POPI Classification
[ ]General Business Information
[x]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

John Bodnar wrote:

> David Brown wrote:
>> With higher frequency and higher performance devices, you have to take
>> more care with your memories and buses, and you have more worries
>> about your power supplies and decoupling.  You often need more voltage
>> levels (the v4 has 1.5V for the core, 1.8/2.5V for the memory buses,
>> and 3.3V for IO - the 5234 with which I am most familiar has 1.5V core
>> and everything else at 3.3V).  It is typically easier on slower
>> devices to attach other peripherals to the external buses without glue
>> logic, level converters, etc.
>
> Well, therein lies the rub.  As soon as you start supporting DDR of any
> kind, you get away from being able to produce a device with only two
> voltage rails.  The MCF523x family only supports SDR, so it never had a
> reason to support other than just I/O and VDD supplies.
>

Yes, I understand the necessity for the extra supply, and for the split
buses (for faster DDR bus independent of the FlexBus).  I'm not
suggesting that the v4 devices are overly complex for board design -
just that they are *more* complex than the v2 cores.  Getting higher
performance always requires a bit more work.

> The MCF5445x still maintains a 3.3V general-purpose memory bus (FlexBus)
> for connecting up everything else but your SDRAM.  In the future, I'm
> looking to move the FlexBus to its own dedicated supply rail in order to
> support flashes and FPGAs/CPLDs with 1.8V I/Os as a means of reducing
> I/O power.  This would up the number of supply rails to four (core,
> SDRAM, FlexBus, and digital I/O), but you could still run the FlexBus at
> 3.3V, if desired.
>
>> I haven't used any v4 cores, so my rough comments are only based on my
>> reading of datasheets and application notes.  But our move from the
>> older, slower MC68832 to the MCF5234 required a bit step in board
>> complexity and quality - I would plan for another step up, though
>> perhaps not as large, in doing a v4 board.
>
> I think we've made the MCF5445x family quite friendly for board design,
> especially on the 256-ball MAPBGA variants.  We're trying to take the
> lessons we've learned from doing the package and substrate design for
> those devices and apply them to new higher end parts going forward.
>
>> I you want to tell me that I'm wrong, and that the MCF5445x is as easy
>> to use as the MCF5234 (baring the lack of a TPU), then go ahead - I'll
>> listen!  I like the ColdFire architecture, and if the v4 will give me
>> a lot more processing power for little more complexity, then it's
>> definitely good to know.
>
> I think I mentioned it before, but I am hardly an expert on board
> design, so I could be wrong on all counts :-(  That said, I had plenty
> of help from some real experts on the MCF5445x, so I think we've made
> that family one of our better examples of how to pin out and package a
> device.  Of course, by saying as much, I'm now setting myself up for pot
> shots from the peanut gallery, so let the shooting commence :-)
>

 From my experience with the MCF5234, I don't think I have many
complaints about the pin out and packaging.  Some on-chip termination
for the sdram signals would have been nice, but it's not a problem.
I've also used a v2 MCU, the MCF5213 IIRC.  The only annoying thing with
the devices was the combinations available for peripherals sharing pins
- there can be a few too many peripheral sharing the same pins, making
it impossible to have things like 3 UARTs *and* a CAN bus at the same
time.  (Bizarrely, the MCF5213 has some peripheral outputs that are not
connected to *any* pins!)

I had a quick look at the MCF5445x on the website.  I like the 360 PGA
layouts with gaps in the middle and concentrated groups of power pins.
Sometimes small layouts are important, but often they are not -
tight-packed BGAs means a lot of layers and small track widths and vias
are needed, especially if the pitch is smaller than 1 mm.  In an
industrial board, this could easily mean you have a 12 x 20 cm board
where you need 8 layers and 6 mil tracks on a 4x4 cm corner for the
processor, while the rest of the card is better suited to much cheaper 2
or 4 layers and 10 mil tracks.  So make small and compact packages for
those that need them, and keep the slightly bigger and more open
packages for those of us that don't!

(I don't know where you stand within Freescale, and if these "peanuts"
should be directed to you or passed on to others.  But I think it is a
*very* positive thing that there are Freescale staff on lists like this,
giving helpful advice and listening to customers.)

Do you have any influence over the GPIO modules?  On the MCF5234,
setting output pins high and low is painfully slow (despite the "set
pin" and "clear pin" registers).  The latency as the write goes over to
a slower internal bus with multiple wait states (even at the lower
speed), is just too high.  I was trying to test and debug an interrupt
routine using the traditional method of setting a pin high on entry and
low on exit - driving the pins high and low took more time than the
interrupt routine itself.

On the MCF5234, the SDRAM controller is very poor - it has no concept of
banks and open pages.  This means that every read access takes (IIRC) 4
bus clocks before it can read out a single word.  If the cache is not
enabled, then there is no pipelining at all, and thus even sequential
code reads take 5 bus clocks (10 cpu clocks) per read.  Even with the
cache enabled, so that reads are done as bursts of 4 accesses,
continuous sequential reads use only half the bus bandwidth due to
overheads (less, actually, due to refreshes).  An little extra logic to
track the open page would half the overhead, and speculative burst reads
would reduce it even more in many cases.  This stuff is not hard (I've
made simple dram controllers on an fpga), and can make a big difference
for some types of code - and a vast difference if the cache is not used.

Other than that, I like the ColdFire devices.  I have always liked the
architecture (I've been a 68332 user for nearly 15 years).

mvh.,

David

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

David Brown wrote:
> From my experience with the MCF5234, I don't think I have many
> complaints about the pin out and packaging.  Some on-chip termination
> for the sdram signals would have been nice, but it's not a problem.

We're looking at on-die termination (ODT) for DDR2 once we start pushing
the frequency harder.

On the MCF5445x, for example, we support DDR2, but only up to 133 MHz,
and the JEDEC specified minimum frequency for DDR2 is 125 MHz, so doing
ODT wasn't a high priority for the design.

> I've also used a v2 MCU, the MCF5213 IIRC.  The only annoying thing
> with the devices was the combinations available for peripherals
> sharing pins - there can be a few too many peripheral sharing the same
> pins, making it impossible to have things like 3 UARTs *and* a CAN bus
> at the same time.  (Bizarrely, the MCF5213 has some peripheral outputs
> that are not connected to *any* pins!)

It's all about the package size.  I spent a lot of time on the MCF521x
pin outs, and one of the trade-offs was that you either get only three
UARTs or two UARTs and FlexCAN.  Going back to the original pin out, I
see that you can have all three UARTs and FlexCAN, even in the 64-pin
packages, so long as you're willing to give up the UART flow control
signals.  That seems to be a reasonable trade-off for a lot of folks.

BTW, I'm not aware of any peripheral I/Os that aren't connected to any
pins at all, save something like the DMA request and acknowledge (which
didn't make sense without a bus) and the 16-bit timer SYNC pin.


> I had a quick look at the MCF5445x on the website.  I like the 360 PGA
> layouts with gaps in the middle and concentrated groups of power pins.
> Sometimes small layouts are important, but often they are not -
> tight-packed BGAs means a lot of layers and small track widths and
> vias are needed, especially if the pitch is smaller than 1 mm.

My general take is that most of our customers aren't yet willing to go
with sub-1 mm ball pitch BGA packages.  We certainly have the options
available here (the cell phone business is good that way) should we ever
need to offer such packages.

> (I don't know where you stand within Freescale, and if these "peanuts"
> should be directed to you or passed on to others.  But I think it is a
> *very* positive thing that there are Freescale staff on lists like
> this, giving helpful advice and listening to customers.)

I'm always looking for good, well-documented customer inputs, meaning
requests with explanations are helpful.

> Do you have any influence over the GPIO modules?  On the MCF5234,
> setting output pins high and low is painfully slow (despite the "set
> pin" and "clear pin" registers).  The latency as the write goes over
> to a slower internal bus with multiple wait states (even at the lower
> speed), is just too high.  I was trying to test and debug an interrupt
> routine using the traditional method of setting a pin high on entry
> and low on exit - driving the pins high and low took more time than
> the interrupt routine itself.

I'm totally aware of this.  This is a limitation of the platform
architecture used on the MCF528x, MCF523x, MCF521x, MCF522xx, and
MCF5270/1/4/5.  The PORTS module resides on the other side of a bus
bridge that runs at half the platform clock rate.  That means that for a
150 MHz MCF5234, the PORTS block is running in a 37.5 MHz clock domain,
and that doesn't help.

The MCF5207/8, MCF532x, MCF537x, and MCF5445x are better in this
respect.  The PORTS module resides in the platform clock domain, meaning
that it gets clocked at 83.33, 80, 80, or 133 MHz, respectively, on
these devices.  I/O toggles times, based on our benchmarks, are about 4
times as fast as on those devices listed in the previous paragraph.

GPIO is going to get even faster.  Please read up on the Rapid GPIO
module on the MCF51QE128:

http://www.freescale.com/files/32bit/doc/ref_manual/MCF51QE128RM.pdf

We can use this block with other ColdFire cores, where it will reside on
the local (K) bus, allowing it to run at the CPU clock frequency.  You
can do the math from there... :-)

> On the MCF5234, the SDRAM controller is very poor - it has no concept
> of banks and open pages.  This means that every read access takes
> (IIRC) 4 bus clocks before it can read out a single word.  If the
> cache is not enabled, then there is no pipelining at all, and thus
> even sequential code reads take 5 bus clocks (10 cpu clocks) per
> read.  Even with the cache enabled, so that reads are done as bursts
> of 4 accesses, continuous sequential reads use only half the bus
> bandwidth due to overheads (less, actually, due to refreshes).  An
> little extra logic to track the open page would half the overhead, and
> speculative burst reads would reduce it even more in many cases.

You should examine the SDR/DDR/LPDDR controller on the MCF5207/8,
MCF532x, MCF537x, and MCF5445x.  It delivers better performance than the
SDR-only controller on the MCF523x and does track one page per bank.

John Bodnar
Systems Engineer
Microcontroller Solutions Group
Freescale Semiconductor, Inc.

--
POPI Classification
[x]General Business Information
[ ]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

John Bodnar wrote:

> David Brown wrote:
>> From my experience with the MCF5234, I don't think I have many
>> complaints about the pin out and packaging.  Some on-chip termination
>> for the sdram signals would have been nice, but it's not a problem.
>
> We're looking at on-die termination (ODT) for DDR2 once we start pushing
> the frequency harder.
>
> On the MCF5445x, for example, we support DDR2, but only up to 133 MHz,
> and the JEDEC specified minimum frequency for DDR2 is 125 MHz, so doing
> ODT wasn't a high priority for the design.
>
>> I've also used a v2 MCU, the MCF5213 IIRC.  The only annoying thing
>> with the devices was the combinations available for peripherals
>> sharing pins - there can be a few too many peripheral sharing the same
>> pins, making it impossible to have things like 3 UARTs *and* a CAN bus
>> at the same time.  (Bizarrely, the MCF5213 has some peripheral outputs
>> that are not connected to *any* pins!)
>
> It's all about the package size.  I spent a lot of time on the MCF521x
> pin outs, and one of the trade-offs was that you either get only three
> UARTs or two UARTs and FlexCAN.  Going back to the original pin out, I
> see that you can have all three UARTs and FlexCAN, even in the 64-pin
> packages, so long as you're willing to give up the UART flow control
> signals.  That seems to be a reasonable trade-off for a lot of folks.
>

To be honest, I can't remember off-hand which combination I was looking
for that did not exist - or if it was on the MCF5213 or the MCF5234.
But as you say, there are limits when you want to stick to a given
package size.

> BTW, I'm not aware of any peripheral I/Os that aren't connected to any
> pins at all, save something like the DMA request and acknowledge (which
> didn't make sense without a bus) and the 16-bit timer SYNC pin.
>

It was pwm timer outputs.  On the MCF5213, you can configure the pwm
outputs as 8 8-bit pwm timers, or 4 16-bit pwm timers (it was a while
ago that I worked on that project, so the details are hazy - and of
course, I could have misread the datasheet at the time).  It turned out
that although you could set up 8 pwm timers, only four were connected to
pins.

>
>> I had a quick look at the MCF5445x on the website.  I like the 360 PGA
>> layouts with gaps in the middle and concentrated groups of power pins.
>> Sometimes small layouts are important, but often they are not -
>> tight-packed BGAs means a lot of layers and small track widths and
>> vias are needed, especially if the pitch is smaller than 1 mm.
>
> My general take is that most of our customers aren't yet willing to go
> with sub-1 mm ball pitch BGA packages.  We certainly have the options
> available here (the cell phone business is good that way) should we ever
> need to offer such packages.
>
>> (I don't know where you stand within Freescale, and if these "peanuts"
>> should be directed to you or passed on to others.  But I think it is a
>> *very* positive thing that there are Freescale staff on lists like
>> this, giving helpful advice and listening to customers.)
>
> I'm always looking for good, well-documented customer inputs, meaning
> requests with explanations are helpful.
>
>> Do you have any influence over the GPIO modules?  On the MCF5234,
>> setting output pins high and low is painfully slow (despite the "set
>> pin" and "clear pin" registers).  The latency as the write goes over
>> to a slower internal bus with multiple wait states (even at the lower
>> speed), is just too high.  I was trying to test and debug an interrupt
>> routine using the traditional method of setting a pin high on entry
>> and low on exit - driving the pins high and low took more time than
>> the interrupt routine itself.
>
> I'm totally aware of this.  This is a limitation of the platform
> architecture used on the MCF528x, MCF523x, MCF521x, MCF522xx, and
> MCF5270/1/4/5.  The PORTS module resides on the other side of a bus
> bridge that runs at half the platform clock rate.  That means that for a
> 150 MHz MCF5234, the PORTS block is running in a 37.5 MHz clock domain,
> and that doesn't help.
>
> The MCF5207/8, MCF532x, MCF537x, and MCF5445x are better in this
> respect.  The PORTS module resides in the platform clock domain, meaning
> that it gets clocked at 83.33, 80, 80, or 133 MHz, respectively, on
> these devices.  I/O toggles times, based on our benchmarks, are about 4
> times as fast as on those devices listed in the previous paragraph.
>

You are aware of the issue, and improving things on later chips - I
couldn't really ask for more.

> GPIO is going to get even faster.  Please read up on the Rapid GPIO
> module on the MCF51QE128:
>
> http://www.freescale.com/files/32bit/doc/ref_manual/MCF51QE128RM.pdf
>

Yes, on the v1 ColdFires GPIO performance is likely to be more critical
given their target applications.

> We can use this block with other ColdFire cores, where it will reside on
> the local (K) bus, allowing it to run at the CPU clock frequency.  You
> can do the math from there... :-)
>

Sounds good to me.

>> On the MCF5234, the SDRAM controller is very poor - it has no concept
>> of banks and open pages.  This means that every read access takes
>> (IIRC) 4 bus clocks before it can read out a single word.  If the
>> cache is not enabled, then there is no pipelining at all, and thus
>> even sequential code reads take 5 bus clocks (10 cpu clocks) per
>> read.  Even with the cache enabled, so that reads are done as bursts
>> of 4 accesses, continuous sequential reads use only half the bus
>> bandwidth due to overheads (less, actually, due to refreshes).  An
>> little extra logic to track the open page would half the overhead, and
>> speculative burst reads would reduce it even more in many cases.
>
> You should examine the SDR/DDR/LPDDR controller on the MCF5207/8,
> MCF532x, MCF537x, and MCF5445x.  It delivers better performance than the
> SDR-only controller on the MCF523x and does track one page per bank.
>

Again, that sounds better.  I suppose with DDR, keeping pages open makes
an even bigger difference.  Still, it would have been nice to have had
this on the MCF5234, especially as we ran with the cache disabled for a
while (due to unclear tables in the manuals, I had slightly incorrect
settings for the sdram at first.  The sdram worked fine without the
cache, but with cache enabled, it failed depending on the state of A19
on the address bus.)

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

David Brown wrote:
> It was pwm timer outputs.  On the MCF5213, you can configure the pwm
> outputs as 8 8-bit pwm timers, or 4 16-bit pwm timers (it was a while
> ago that I worked on that project, so the details are hazy - and of
> course, I could have misread the datasheet at the time).  It turned
> out that although you could set up 8 pwm timers, only four were
> connected to pins.

Oh, yeah. The PWM module consists of eight 8-bit channels, pairs of
which can be concatenated to get up to four 16-bit channels.

On the smaller MCF5211/2/3 packages, the four 16-bit channels (1, 3, 5,
and 7) are the ones multiplexed with the 16-bit timer channels.  They
are also bonded to dedicated pins on the bigger packages (81-ball MAPBGA
and 100-pin LQFP).

The four even-numbered channels (0, 2, 4, and 6) are only available
muxed with the 32-bit timer channels.  In retrospect, they could've been
muxed elsewhere, but we worked on the premise that most people would
want a mix of 16- and 32-bit timers and PWMs, and that the 8-bit only
channels were unlikely to be used too often.  You must be using the
whole batch of timers and, therefore, had no way to use any of the
dedicated 8-bit channels...

John

--
POPI Classification
[x]General Business Information
[ ]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Bob Furber]

John Bodnar wrote:

 > :
> My general take is that most of our customers aren't yet willing to go
> with sub-1 mm ball pitch BGA packages.  We certainly have the options
> available here (the cell phone business is good that way) should we ever
> need to offer such packages.

May I suggest that 1mm BGA is pretty clunky by today's standards.

I suppose the challenge for you is that the MPU you start designing
today may not hit the market for a year. Your earliest client may not
have his product to market for another year. The bulk of your clients
may not have a marketable product for at least 3 years hence. My guess
is that 0.8mm pitch will be considered pretty clunky by then, with
commodity memory chips being 0.65mm, 1.2v or less. What kind of crystal
ball do you use assess all of this?

Commodity DDR and flash today comes in 0.8mm BGA packages and PCBs with
0.8mm BGA pitches and .004" traces no longer command a premium, even in
prototype quantities ..providing they are purchased from China. For some
bizarre reason, North American PCB suppliers have problems delivering
prototype quantities at a reasonable price when trace/space are below
0.005" with tolerances required for 0.8MM BGAs. So, this business goes
to China.

For what it is worth, my crystal ball shows MPU boards getting smaller,
lower powered and faster. Everything that has to be fast would be
contained on a small, multi-layered board. Slow, high-current industrial
stuff would sit on a separate connector, relay, driver, signal
conditioner or whatnot board with a tiny, high-speed plug-in module
providing smarts, memory and high-speed communications ..because the
industrial board would be a clunky 2 layer board with thick, heavy traces.

What I am asking is that you consider sub-1mm pitch for your future MPUs
..and make them frugal enough that heat dissipation is not a problem.

While in this wishful thinking state of mind, I cannot help mentioning
my Technicolor dream: A new, compact, fast, low powered MPC55xx with the
PowerPC ripped out and replaced with a ColdFire or Arm core with FlexBus
LPDDR/DDR2 interface ..and, oh, yes, don't forget USB Host & Device and
100/100 Ethernet and Phy ..all for < $50.

Why? Because:

a. As I mentioned earlier, having tasted FlexBus and low power, low heat
dissipation of your newer ColdFires, I got addicted.

b. Having tasted eTPU and MIOS on the MPC5xx, I got addicted.

They are both as good as it gets ..but, regrettably, not on the same MPU
..yet.

Thanks for listening,

Bob Furber
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[John Bodnar]

Bob Furber wrote:
> Commodity DDR and flash today comes in 0.8mm BGA packages

Yes, but these packages have split ball maps with a channel down the
middle, making them not much harder to route to than a TSOP.

We don't really have the luxury of being able to implement routing
channels like commodity memories.  If we were to go to sub-1 mm ball
pitch, we need to incorporate routing channels by depopulating balls,
and we'd likely end up in packages that are physically not much smaller
than what we're doing with 1 mm ball pitch today.

Cost matters, too, and it's less expensive to assemble a 1 mm pitch BGA
than it is a 0.8 mm pitch BGA.  For now, I most customers to whom I
talk, even for high-volume applications, aren't requesting sub-1 mm
pitches.  With our I/O counts in the 144 to 416 ball range, the coarser
1 mm ball pitch seems to afford folks a little more leeway in escaping
our ball maps out to the rest of the PCB within a reasonable number of
layers.

That's not to say there aren't customers who are space constrained and
asking for smaller packages, though.  There just aren't that many of
them yet.

> While in this wishful thinking state of mind, I cannot help mentioning
> my Technicolor dream: A new, compact, fast, low powered MPC55xx with
> the PowerPC ripped out and replaced with a ColdFire or Arm core with
> FlexBus LPDDR/DDR2 interface ..and, oh, yes, don't forget USB Host &
> Device and 100/100 Ethernet and Phy ..all for < $50.

I don't see Ethernet PHYs getting integrated on-chip anymore.  They're
not conducive to being designed in sub-0.18 micron process technologies,
and they've recently become about as commoditized as RS-232 level shifters.

When I started work on the MCF5282, we were figuring $5 into the system
cost for the PHY.  We've now reduced that to $1 to $2 depending on the
target market.  That kind of cost erosion makes it difficult for us to
recoup the costs of developing the PHY and integrating it.

BTW, I reserve the right to backtrack on this for Gbit Ethernet.  
There's some commonality between a GbE PHY and things like PCIe and SATA
PHYs, which do get integrated, that might make this possible.  No
promises, just an observation.
> b. Having tasted eTPU and MIOS on the MPC5xx, I got addicted.

eTPU...  We really have got the thumbscrews on you :-)

John

--
POPI Classification
[ ]General Business Information
[x]Freescale Internal Use
[ ]Freescale Confidential Proprietary

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

John Bodnar wrote:

> David Brown wrote:
>> It was pwm timer outputs.  On the MCF5213, you can configure the pwm
>> outputs as 8 8-bit pwm timers, or 4 16-bit pwm timers (it was a while
>> ago that I worked on that project, so the details are hazy - and of
>> course, I could have misread the datasheet at the time).  It turned
>> out that although you could set up 8 pwm timers, only four were
>> connected to pins.
>
> Oh, yeah. The PWM module consists of eight 8-bit channels, pairs of
> which can be concatenated to get up to four 16-bit channels.
>
> On the smaller MCF5211/2/3 packages, the four 16-bit channels (1, 3, 5,
> and 7) are the ones multiplexed with the 16-bit timer channels.  They
> are also bonded to dedicated pins on the bigger packages (81-ball MAPBGA
> and 100-pin LQFP).
>
> The four even-numbered channels (0, 2, 4, and 6) are only available
> muxed with the 32-bit timer channels.  In retrospect, they could've been
> muxed elsewhere, but we worked on the premise that most people would
> want a mix of 16- and 32-bit timers and PWMs, and that the 8-bit only
> channels were unlikely to be used too often.  You must be using the
> whole batch of timers and, therefore, had no way to use any of the
> dedicated 8-bit channels...
>

In this particular application, I wanted 8 pwm signals but was not too
bothered about the accuracy - 8 8-bit channels would have done nicely.
I managed it using one of the bigger packages, using the four available
pwm channels, and 4 general timers - slightly inelegant considering the
device had ideal internal hardware, but it worked fine in practice.

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[David Brown-4]

John Bodnar wrote:

> Bob Furber wrote:
>> Commodity DDR and flash today comes in 0.8mm BGA packages
>
> Yes, but these packages have split ball maps with a channel down the
> middle, making them not much harder to route to than a TSOP.
>
> We don't really have the luxury of being able to implement routing
> channels like commodity memories.  If we were to go to sub-1 mm ball
> pitch, we need to incorporate routing channels by depopulating balls,
> and we'd likely end up in packages that are physically not much smaller
> than what we're doing with 1 mm ball pitch today.
>
> Cost matters, too, and it's less expensive to assemble a 1 mm pitch BGA
> than it is a 0.8 mm pitch BGA.  For now, I most customers to whom I
> talk, even for high-volume applications, aren't requesting sub-1 mm
> pitches.  With our I/O counts in the 144 to 416 ball range, the coarser
> 1 mm ball pitch seems to afford folks a little more leeway in escaping
> our ball maps out to the rest of the PCB within a reasonable number of
> layers.
>
> That's not to say there aren't customers who are space constrained and
> asking for smaller packages, though.  There just aren't that many of
> them yet.
>

I agree with that.  To build cards using 0.8 mm BGA, and correspondingly
small chicken feed components, you need a much more expensive class of
board production machine, putting the cards out of reach of smaller
production companies.  I don't know how much of the market volume is
covered by smaller companies, but 1 mm (and packages like the 360 bga
with spaces in the middle) will appeal to a wider group than tiny BGA
packages.  Best of all, offer both sizes!

>> While in this wishful thinking state of mind, I cannot help mentioning
>> my Technicolor dream: A new, compact, fast, low powered MPC55xx with
>> the PowerPC ripped out and replaced with a ColdFire or Arm core with
>> FlexBus LPDDR/DDR2 interface ..and, oh, yes, don't forget USB Host &
>> Device and 100/100 Ethernet and Phy ..all for < $50.
>
> I don't see Ethernet PHYs getting integrated on-chip anymore.  They're
> not conducive to being designed in sub-0.18 micron process technologies,
> and they've recently become about as commoditized as RS-232 level shifters.
>
> When I started work on the MCF5282, we were figuring $5 into the system
> cost for the PHY.  We've now reduced that to $1 to $2 depending on the
> target market.  That kind of cost erosion makes it difficult for us to
> recoup the costs of developing the PHY and integrating it.
>

I can see the difficulties in integrating a PHY (Ethernet or USB) on
chip - different chip processes are optimal for different sorts of
device.  There are also occasions when you would actively prefer a MII
interface (such as for connecting to a switch chip).  But the big
advantage for customers is that with a PHY on chip, you only have four
lines for Ethernet, connected directly to a socket with magnetics -
without the PHY, you have about 15 lines and an extra chip on the board.
  With GbE, 480 MBit USB, and other faster peripherals, it's even worse
as you are routing a fair number of parallel fast signals rather than
just two differential pairs.

> BTW, I reserve the right to backtrack on this for Gbit Ethernet.  
> There's some commonality between a GbE PHY and things like PCIe and SATA
> PHYs, which do get integrated, that might make this possible.  No
> promises, just an observation.
>> b. Having tasted eTPU and MIOS on the MPC5xx, I got addicted.
>
> eTPU...  We really have got the thumbscrews on you :-)
>
> John
>

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.