topic Re: 68EC000 vs 68SEC000 in behavioral in ColdFire/68K Microcontrollers and Processors

68EC000 vs 68SEC000 in behavioral

ydohi — Thu, 18 Jun 2015 15:00:45 GMT

Dear,

I'm trying to re-design old 68k board, replace MC68EC000 to MC68SEC000.

Only ROM data is available, no source code, then new board must be binary code compatible to old one.

I'm not sure, those software adjust timing by loop code.

Does 68SEC000 work same as 68EC000 in behavioral?

i.e. prefetch queue depth, latency clock for each instruction.

Are there any docs show those information?

Thanks all,

ydohi

Re: 68EC000 vs 68SEC000 in behavioral

TomE — Sat, 20 Jun 2015 07:41:21 GMT

Have you downloaded and read all the documents here?

Low Cost 32-Bit Microprocessor (Including HC0|Freescale

The assurances in "MC68SEC000 Microprocessor - Product Brief" seem pretty good to me.

> prefetch queue depth,

This is a 68000. It was released in 1979, 36 YEARS ago. They didn't have prefetch then. The 68010 released in 1982 did.

Tom

Re: 68EC000 vs 68SEC000 in behavioral

ydohi — Sat, 20 Jun 2015 14:01:49 GMT

Hi Tom,

Thank you for your replying.

Just now I read that product brief, and it says "Complete code compatibility".

Should I read that also "latency clock cycles are same" or not....

Also first 68K had 2 words depth instruction prefetch queue.

That is only FIFO in previous stage of instruction decoder, not modern technology.

Deep queue increase performance when non branching process,

but significantly decrease when branching, e.g. loop code time waiting.

Thanks agen.

Regards,

ydohi

Re: 68EC000 vs 68SEC000 in behavioral

TomE — Tue, 23 Jun 2015 00:58:45 GMT

> Also first 68K had 2 words depth instruction prefetch queue.

No, the SECOND one had the prefetch queue - the 68010. The FIRST one (68000, 68008, 68HC00, 68EC00, 68SEC00) had no prefetch queue (unless you're calling the 68000 the zeroth one :-).

The 68000 actually had a 16-bit ALU, matching its 16-bit data bus. This is obvious looking at the instruction timing, where things like the ADD instructions take an extra two clocks for 32-bit over 16-bit. With the exception of MUL, DIV and some of the more complicated addressing modes, the 68000 was very much bus limited, and each read or write took 4 clock cycles (plus any wait states) for each 16 bits of instruction and data. As an example, the worst case MOV instruction is a 32-bit move from memory to memory with the 32-bit addresses specified. It takes 7 16-bit reads and 2 16-bit writes and so 36 clock cycles to execute, 3.6 microseconds at a typical 10MHz. That's a lot, but MUL and DIVS take maximum times of 70 and 158 clocks, so were best avoided if possible.!

Here's the evolution from a paper on optimisation for the different models from here:

http://www.freescale.com/files/32bit/doc/reports_presentations/MC680X0OPTAPP.txt

The following table summarizes the characteristics of the different members 
in the 68000 family:

PROC     CACHE    RADD    MADD    MUL    INDEX    BRA    UACC    HWFP
68000     0/0       6     18      40      18     10/6     no      no
68020   256/0       2      6      28       9      6/4     yes    68881/2
68030   256/256     2      5      28       8      6/4     yes    68881/2
CPU32     0/0       2      9      26      12      8/4     no      no
68040    4K/4K      1      1      16       3      2/3     yes     yes
68060    8K/8K      1      1       2       1      0/1     yes     yes

 RAdd: Register to register 32 bit add (add.l  d0,d1).
 MAdd: Absolute long address to register add (add.l _mem,d1).
  Mul: 16x16 multiplication (max. time) (mulu.w d0,d1).
Index: Indexed addressing mode (move.l 2(a0,d0),d1).
  Bra: Byte conditional branch taken/not taken (bne.b label).
 UAcc: Unaligned access allowed (move.l 0xffff0001,d1).
 HWFP: Hardware floating point support.

Tom

Re: 68EC000 vs 68SEC000 in behavioral

ydohi — Tue, 23 Jun 2015 04:39:04 GMT

Hi Tom.

Thank you for your replying again.

> Here's the evolution from a paper on optimisation for the different models from here:

Oh, that must be doc just I want, if it touched on 68SEC000.

From the context, I think I can understand to be same between EC & SEC except power consumption.

Anyway, classic 68000 had prefetch queue certainly.

Believe me. I had confirmed it by HP (todays Agilent) logic analyzer w/ 68K disasm s/w, decades ago. ^_^;

There is a brief description of the deference between 68000 and 68010 in

"Technical Description of the prefetch queue" section on this page.

Instruction prefetch on the 68000 processor

http://pasti.fxatari.com/68kdocs/68kPrefetch.html

Cause of public misunderstanding is Motorola's vague docs. :-(

Thank you again!

Regards,

ydohi

Re: 68EC000 vs 68SEC000 in behavioral

TomE — Tue, 23 Jun 2015 06:56:49 GMT

> Anyway, classic 68000 had prefetch queue certainly.

Yes, thank you for letting me know and also the pointers to that document.

That also explains why the 68010 didn't execute instructions a lot faster than the 68000, which it would be expected to do if it had a queue and the 68000 didn't. Except for the ones they sped up of course (MUL and DIV by a lot, and EOR, ADDI, EORI and others by 2 clocks in some cases.

Tom