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

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

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