Instruction CACHE in the M5223X.....(?)

[mjbcswitzerland]

Hi All

Perhaps some one can clear up a point....

Has the M5223X family instruction CACHE?

There is a register which is normally set up by using
mcf5xxx_wr_cacr(0
| MCF5XXX_CACR_CENB
| MCF5XXX_CACR_CINV
| MCF5XXX_CACR_DISD
| MCF5XXX_CACR_CEIB
| MCF5XXX_CACR_CLNF_00); // enable instruction cache

But is there actually an intsruction CACHE in the device?

In the manual there are details about this register but no details about the CACHE.

Comparing with the 5282 - in its manual it has the same details about the register PLUS a chapter dedicated to the CACHE.

My understanding is that the register is always there but not always with the CACHE support behind it. This means that tight loops will run faster on the 5282 that the M5223X (which is the present impression). But is this absolutely correct? Perhaps the CACHE chapter is missing in the manual and really there on the chip...(?).

Who can say with authority what is correct?

Another related question.

If I let some code run in SRAM will it actually run faster that directly from FLASH? This is typically the case for other processor families I have used but will I be wasting time trying because SRAM and FLASH code accesses are at the same speed??

And finally...we all know that we can let the M5223X devices run rather faster than the maximum specified 60MHz. But the problem is that no one wants to risk it in real-life because it is 'not-specified'. I wonder whether it may be of interest to have some form of 'official' specification for operating at limits (eg. to what temperate is it 'guarantied', what other restrictions must be observed to have 'guarantied' reliability, etc.) Otherwise it seems to be wasting a rather useful feature of the devices. It works but no one is prepared to risk anything - meaning that it is of no actual use to anyone. Just an idea!!

Best regards

Mark Butcher
www.mjbc.ch / www.uTasker.com

[DrSeuss]

While this in defined in the header files for the 5223x. This device does not have an instruction cache.

I am sorry and will remove them. ( I think there is a new Codewarrior release near the end of the year which I hope to have (most) all header issues addressed)

"Who can say with authority what is correct?" me I'm the doctor....

Code execution from flash uses a 2:1:1:1 burst fetch. Sram is single cycle so it is marginally faster, if you can spare the space.

__________________________________________________________________

[DrSeuss]

On the speed temp issue. This is a very difficult question and I would assume that anyone you ask will give you a different answer. I will try to answer and explain the best I can. (Perhaps we should make this part a new post).

1) When a device is designed there are targets to the speed / temp trade off. (These are directly proportional)

2) I do have magic pixie dust that I can sprinkle on the chip and turn all transistors on at one time. It is my responsibility to make sure that in this case the device does not melt. It does not need to match any user specs but if it melts it is a bad thing. This is the reason (indirectly, but I hope clearly) that the MCF52235 is specified at 60MHz.

3) Then I look at lowest power modes. These can be tested.

So, I'm left with the question. What should the specification be? One notch below melt down? Statistically, there is no possible way that in normal user mode the device could have all transistors active at one time. Yet we still test to these limits.

To all that wonder, this is the reason that the Idd numbers in the (my) Freescale specifications take so long to move from TBD. One extreme (low power) the device is a simple non functional silicon rock, the other full MIPS, all modules rocking (unrealistic, as you can't get here) it is 25 degrees from molten glass (margin). What is the typical that helps you as a customer?

In a way I know the answer. How about a graph? While this can be accomplished via bench testing and point you in the right direction, this can not be done on production test equipment and "guaranteed".

So my question to the community is what "honest" measurable number can I put in the specifications for Idds?

Understand, that I am trying to impart my frustration with deriving these numbers and my opinions may not reflect the frustration of my employer. I am simply trying in a very long way to ask what nominal (useful) idds you as a customer need.

Perhaps, I’m not a Dr. after all and there is a simple specification (iEEE) that put all manufactures on the same even playing field. If so please forward to the group so I can get ride of the TBDs and phone calls…

[DrSeuss]

Read over one hundred times in two months, yet no input. hummm.

Does this mean that users want a number, any number, just make a number?

Perhaps anything w/o TBD in it?

As an update we are doing our very best to get finial numbers for manufacturing qualification,so that we can finally go to production,

I am disappointed that I have zero feedback to go forward.....Not even a gripe.. Darn..

Well I tried. :smileyhappy:

Dr.

[mjbcswitzerland]

Hi Doc

I think that the issue is very complicated and so it is hard to discuss.

I suppose also that most visitors are software based and so the real world physics also outside of the normal sphere.

However I am working on a few projects using the Coldfire (and other devices) and I can confirm that no producer of products has the nerves to run a device outside of the specifications (I have suggested it on various occasions but there is sheer panic to think about doing it in something which is manufactured and sold to end customers). The only way to get users to run a device faster is to specify it to do so - that means to have it in black on white.

So effectively the ball lies with the silicum manufacturer. The user uses the number as value which will be safe (zero defects) and if there is a higher number that is safe, it is an advantage.

Put a larger number in print and it will certainly be used (possibly with derating curve). If not, it won't.

Cheers

Mark

[J2MEJediMaster]

I'm looking into this...

---Tom