Author: Johan Klockars (as28-3-8.va.g.bonet.se)
Date: 06-17-2003 02:07
I thought I wrote something about this here a couple of months ago, but it might have been on comp.sys.atari.st.
> > from what i know a 68000 at 250MHz is possible using fpga techniques.
To get something to run at 250 MHz in any current FPGA, you need to limit the combinatorial logic depth significantly (that is, you can't do much per clock cycle).
The fastest soft-core FPGA-CPU I'm aware of tops out at around 150 MHZ in the fastest current FPGA's (half of that frequency in reasonably priced chips). And that's a RISC architecture specifically designed for the FPGA in question and optimized for performance (Xilinx MicroBlaze (see http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=microblaze)).
The 125 Dhrystone MIPS rating for that CPU in a fast FPGA is somewhat higher than for a real '060, IIRC. From what I've heard, performance drops like a rock if you have to go to external memory for instructions, though.
Of course, frequency versus number of clock cycles per instruction is always a trade-off.
For example, the following might be a workable clock for clock design for how to implement a 68000 register to register addition at 250 MHz:
1 Read instruction word from internal RAM.
2 Decode instruction to figure out what we're supposed to do.
3 Fetch the necessary register values.
4 Pass register values through a network of multiplexers (since operands can come from a bunch of places).
5 Execute operation.
6 Pass result through a network of multiplexers (since there is a bunch of operation blocks that could have generated the result).
7 Write result to registers.
I might actually be possible to do all of these at 250 MHz in a fast FPGA, but I doubt there's enough margin to combine any of them.
Of course, now we've spent 7 cycles on something that a real 68000 did in four (and the MicroBlaze in one).
We should, however, be able to, in many cases, overlap 1&2 for the next instruction with 6&7 for the current one. Also, a couple of extra multiplexers in 4 might allow us to similarly overlap 3 and 7. So, we might reach a throughput of 4 cycles per instruction. Still, this leaves us a factor of 2.4 (1 cycle at 150 MHz compared to 4 cycles at 250 MHz) behind the MicroBlaze in actual execution speed for this example (and that's assuming we could reach the 250 MHz, which I'm not at all sure about).
The MicroBlaze, being a RISC and designed for the FPGA, might do something like:
1 Read instruction from FPGA.
2 Fetch the necessary register values (the bits to use are probably fixed in the instruction word) and possibly do some operand multiplexing.
3 Possibly do some operand multiplexing. Execute operation. Do result multiplexing.
4 Write result back to registers.
Due to the simpler architecture and lower clock frequency, this can be completely pipelined. That is, it can have a throughput of one instruction per clock cycle.
Also, note that the first step is exactly the same as above. This means that the chance of actually being able to fetch the instruction word in time is better (lower clock frequency), and/or that logic can be spent to do this more efficiently (for example by implementing some kind of caching mechanism).
(The last step is the same too, but at the moment I can't think of anything more useful to do there given the extra time.)
Of course, for this simple example, it would be possible to pipeline the 68000 in the same way (at the lower clock frequency). Unfortunately, there are lots of 68k features that are more complicated than the register to register addition mentioned above. The various addressing modes, for example, do not fit in this pipeline at all. And there was probably a good reason why Motorola used a two-level microcode design to handle the instruction decoding.
The 68k architecture, like most 'real' CPU architectures, is quite badly suited to FPGA implementation.
> > it would be a true 68000, but then you have all downsides.. no barrelshifter.. very slow multiply.. only 16 bit databus, only 16MB addressable and no fpu..
There's little reason for most of those limitations (but as I mentioned above, there are worse problems).
|
