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

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

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.