I decided to start another thread to help with technical details on the latest V4 product offering. I know several discussions are happening in another thread, but thought it would be best to pull this content into its own thread.

The MCF5445x family comes in multiple flavors. The superset part, the MCF54455, is what we currently offer on our full functional EVB.

The core is a V4m. The "m" means it does have the ColdFire MMU unit, but lacks the FPU unit that we have in our V4e offering.

The FPU is a large logic block and in the 5445x family we decided to leave it off for this product. But the MMU is slightly upgraded with a new page size for the TLBs that should help with large memory systems.

The internal bus architecture is based on a 32 bit wide cross bar design. Meaning that each bus master has a non-blocking access to any slave as long as to masters do not attempt to access the same slave. What does this mean to software engineers? Well.. It means you have some interesting options in regard to how you handle data movement.

The DDR controller has only a 16 bit external port, but it is capable of 32 bits of data in a single clock cycle. So if you do a move.l from a SDRAM address to a data register, you still get 32 bits of data in a single clock (not counting address cycle, refreshes, and other drawbacks to SDRAM designs..) The full EVB is implemented with DDR2 memory which does have some minor drawbacks from a performance point of view. If you are doing lots of single "data beat" access meaning move.l or move.w/move.b to random addresses without data cache, you will suffer a variety of delays do to the nature of SDRAM memories are really optimized for bursting. The regular DDR memories and our controller support burst terminate commands, but DDR2 memories had that functionality removed. So to get good data copy performance, you really need to have the data cache enabled or attempt to use the move.m instruction so the controller can issue a 16-byte burst to the DDR2 memories.

In general.. you should see much of a performance loss because we did 16bit wide data bus externally, as you still get 32 bits of data in a given clock cycle.

Let's see what else can I point out...

The core runs at 2x of the bus clock. So the bus is running at 133Mhz and 32bit wide, with the core running at 266Mhz.. The KRAM runs at 266Mhz so you can do single cycle accesses at processor speed through the core's backside access to the KRAM.

The core, FECs, PCI, eDMA, serial boot, and the USB controller are all bus masters. Meaning the FECs, PCI, serial boot, and USB are all capable of moving data without the need of the CPU and/or the eDMA.

Lastly...Some details on the EVB board.

We did supply an FPGA on the board, that has some logic in there already, and lots of room for you to add your own. It is memory mapped on the FlexBus (our local bus). Their is a CPLD on the board as well... But that one actually does affect the functionality of the board. So change at your own risk. :)

The RTL should be posted on our website, so you don't have to modify without a template to make sure you keep some of the basic features. The design was written to allow for additional logic/expansion.

Have Fun.

-JWW

Hi John,
Can you explain this again?
When you say "32 bits of data in a single clock cycle" to which clock are you referring to? Is it CPU clock, CPU-Clock/2 or CPU-Clock/4 ?


Is the DDR memory clock 133MHz?
Did I understand this correctly that the bus transfers 16 bit on both rising edges of the 133 clock?

What memory transfer rates should we can expect to get from this design?

What is the maximum latency that we can expect when from it when doing total random memory reads?

Would you recommend to use DDR1 memory instead of DDR2 memory?


Cheers
Gunnar