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

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

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