How Function codes in M68ec020 are generated by the processor?

[shantanunakhate]

Hello,

       Please let me know how the microprocessor automatically generate the function codes.

Application Background:

Since the MC68020 is no longer supported by Freescale, we have come across a project requirement where we need to replace the MC68020 processor and emulate it on a POWER PC. We have decided to use a Freescale Power architecture product for our application.

The objective of our project is to take the complete object code as it is ( no modifications) and run it on Power PC. For this to be successful we need to understand how the Function codes are automatically generated in MC68EC020 processor.

Also, can I get the M68ec020 core IP?

Thanks and Regards,

Shantanu.

[TomE]

> replace the MC68020 processor and emulate it on a POWER PC.

That's exactly what Apple computer did way back in 1994 to transition the Macintosh computers from the 680x0 to the PPC.

The PPC they used was specially engineered to support this emulation. I think it would be more difficult on modern PPCs. Specifically it had a "combined cache" as the Macintosh OS wasn't written to handle the Code and Data cache flushing the normal PPC required.

Can you buy a working PPC emulation of a 68020 or are you trying to write your own from scratch?

> The objective of our project is to take the complete object code as it is

Have you considered recompiling it for a ColdFire chip? That's a lot closer to the 68020 than the PPC is. Apple went to PPC as it was the only CPU family with a high enough performance to do the job.

There used to be Coldfire boards made that could plug directly in place of the 68k CPU. These used Coldfire CPU variants that could execute 68k code directly (the MCF5102). I don't think they're available (boards or chips) any more, and the newer Coldfire chips can't execute all 68k opcodes any more either.

There's some Freescale CPU history here:

Re: A general question about MPC83xx Load/Store Unit.. Just for personal interest.

Here's the last time someone was trying to get code written for an MC68k running on something else:

Confusion on priority levels with exception handlers

If your code base is so (can't think of a better adjective here than "bad") that you can't port the source code, it may also have design problems that mean it won't work properly on the emulation as the execution timing will be different.

You're using the M68020 so you don't have the complications of MMU or Floating Point at least. I hope you're not using an external MMU or Floating Point unit!

> we need to understand how the Function codes are automatically

> generated in MC68EC020 processor.

From the M68000PRM manual I have here:

1.3.4 Alternate Function Code Registers (SFC and DFC)

The alternate function code registers contain 3-bit function codes. Function codes can be considered extensions of the 32-bit logical address that optionally provides as many as eight 4-Gbyte address spaces. The processor automatically generates function codes to select address spaces for data and programs at the user and supervisor modes. Certain instructions use SFC and DFC to specify the function codes for operations.

Search for "m68000PM" on Freescale's site and download and read.

Also get the two different "MC68020UM.pdf" manuals from Freescale. They details the Function Codes.

Simply, User and Supervisor mode generate User and Supervisor mode Function Codes. Program and Data Fetches modify the code likewise. It is very rare for hardware to take the slightest bit of notice of any of these. Unless you're doing something weird, hardware usually doesn't care about this at all. The only Function Code that matters is the "CPU Space" code, which is used to indicate interrupt vector fetches. So when your PPC is emulating a 68k Interrupt it has to drive the Function Code bits to the appropriate level. The CPU also drives the Address Bus with specific values (corresponding to the Interrupt level being responded to), but if your hardware ignores these signals you don't need to generate them.

The 68020 also support "Autovector" using the AVEC pin. You hardware might be using this instead of the "full vectors".

You're going to have to redesign all the hardware as the PPC bus is different to the 68020 bus. You should be able to change the interrupt hardware to be simpler and more compatible with the PPC. In that case you won't have to worry about the Function Codes at all.

Can you still get all the old peripheral chips that your object code depends on? Or are you going to have to emulate some or all of them inside the PPC as well?

This job would have been a lot easier if done 15 years ago. How come it took so long?

Tom

[shantanunakhate]

Dear Tom,

Thanks for your elaborate answer.

Let me provide you some more insight.

The product which uses 68020 is still popular with existing customer but nearing to its EOL. One of the option to migrate it to new processor but this will take more effort as functional verification of migrated system has to go through stringent compliance testing. So instead of this we are trying to use hardware virtualization by using PPC and commercially available emulators. For timing we will be adding FPGA which will be connected to PPC local bus and shall perform required address translation and timing adjustments.

One of the proprietary ASIC which is there on existing hardware uses 68020 function codes to provide access to various memories connected at other end of ASIC. And that’s is why for us it is important to understand how function codes are being generated.

I want to know what physical logic is present inside the processor which lets it to automatically generate these function codes?

We are also implementing the floating point co-processor 6888x in the PPC.

Further can you suggest a possible available chip from freescale which we can easily use to emulate the current system?

Thanks,

Shantanu.

[TomE]

>  functional verification of migrated system has to go through stringent compliance testing.

If I were in charge of the compliance I'd refuse anything running under an emulator. I'd require "proof" that the emulation is perfect first, and that's impossible. After all, you're the first to ever build that emulation software and hardware combination. Existing chips have "trust" built on their history. New and unique ones don't have that "trust".

They're also dreadful to debug. When anything goes wrong you don't know if it is the emulator, its hardware or the emulated code that is going wrong.

> For timing we will be adding FPGA which will be connected to PPC local bus

> and shall perform required address translation and timing adjustments.

That is "theoretically possible" with a 68000 but virtually impossible with a 68020. The CPU execution speed changes hugely depending on whether instructions hit in the cache or not. Then there's the prefetching and overlap.

The "good news" is that the original code had better not depend on any (or at least "too many") CPU timing loops, or depend on execution timing as it should be variable on the original hardware anyway. I'd forgotten how slow these chips were - 40 clocks for a MUL and 90 for a DIV!

> One of the proprietary ASIC which is there on existing hardware uses 68020 function

> codes to provide access to various memories connected at other end of ASIC.

>  important to understand how function codes are being generated.

It would be far better to understand what the ASIC is using the signals for. It will only be using a subset of the 8 possible codes and that should let you simplify the design.

What Function Codes is the ASIC decoding for what purpose? It is possible using special instructions and the SFC and DFC registers to read and write from arbitrary spaces, but that's pretty strange. If someone tried to use the "User" and "Supervisor" modes to implement some form of external memory management it is going to get very difficult. Note that "data reads" use the "Data" function codes, but that fetches of immediate values from the same memory use the "Instruction" code. Normally the only thing that the Function Codes are used for in the memory decoder is to recognise the "CPU Space" code during an Interrupt and to block the RAM from being accessed during that cycle. Prove it isn't doing that before worrying about this too much.

You're going to have to replace all of the external hardware anyway as the PPC bus signals are nothing like the 68020 ones. You don't want to try to "translate" the PPC bus into a 68k bus. That way lies pain and madness.

The decoder will be using A0, A1, SIZ0, SIZ1, AS, DS, DBEN and RW to decode the memory cycles, but should only use the Function Codes as stated above.

> I want to know what physical logic is present inside the processor which lets

> it to automatically generate these function codes?

User/Supervisor, Instruction/Data and Interrupts. And also Breakpoints and something else. What more do you want to know?

> We are also implementing the floating point co-processor 6888x in the PPC.

That's going to be fun. The MC68881/MC68882 are full 80-bit IEEE754. It also has "Support of functions not defined by the IEEE standard, including a full set of trigonometric and transcendental functions.". You should hope they're not being used. I don't know that floating point the PPC supports natively, and it is very hard to find out, as every manual refers to some other manual which refers to some architecture designator, which may be documented somewhere else or may not.

> Further can you suggest a possible available chip from freescale which we

> can easily use to emulate the current system?

No. Reimplement it on an appropriate Coldfire chip with new external hardware. Clean-slate design. That could end up far cheaper and faster (and the final hardware should be cheaper) that what you're looking at. I could imagine the debugging taking years.

If you need Floating Point then you may want one with that FP hardware. Frankly, any mid range ColdFire chip is so fast it could run floating point operations in software faster than the 68881 could ever run them in hardware, so why bother.

If you need some peripherals that exist only in PPC or ARM, then use them, but remember the ARM is little-endian. This is unlikely as your old 68020 hardware can't have anything too special on it.

Tom

[shantanunakhate]

Thanks for your rely.

Since I am going to emulate the code in the PPC I wanted to know how can I implement the generation of FC0,FC1 and FC2 the function codes in PPC.

Thanks,

Shantanu.

[TomE]

> I wanted to know how can I implement the generation of FC0,FC1 and FC2

Previously:

> we are trying to use hardware virtualization by using PPC and commercially available emulators.

Ask your commercial emulator provider. They have to decode the instructions, so they have to do this.

Anyway, as I've said it is really trivial.

Instruction fetches use one of the two Instruction fetch codes and data accesses use one of the two Data codes. Which one of the pair depends on whether the CPU is in Supervisor or User mode. And Interrupt Vector fetches use the CPU Space code.

Unless you're using one of the documented instructions that uses the SFC or DFC registers.

That's it. What more could you need to know?

> Further can you suggest a possible available chip from freescale which we can easily use to emulate the current system?

It would be worth getting a MCF54xxx development kit and seeing if the software runs on that. It might be close enough (and have floating point).

Otherwise, you might like to talk to Gunnar:

Can you please help me and run this test on a Coldfire Linux System?

Tom