Designing CPU

Hi. It's probably not very good place for asking such, but there're should be at least those who knows starting points. We need to design our own CPU which can be very slow. It can execute each instruction, let's say, up to 50 cycles. We don't care about speed, and we are also don't care about memory size for microcode, but we're really care about CPU unit size. Where to read about CPU designing techniques, which are about shifting all possible to microcode from CPU unit? Extreme case will be probably Turing machine, but it's not practical. CPU registers and instructions in our case should be looks like ARM9 processor, maybe.

Reply to
climber.tim
Loading thread data ...

A simple technique is to just implement the very basic instructions a cpu needs and then implement the rest as software functions. Instructions that you ought to have: Jump: Load instruction pointer from memory JumpSub: Push current instruction pointer on stack (stack++) Return: Load instruction pointer from stack (stack--) Move memory -> register Move register -> memory Compare register register and jump if equal Increase/Decrease register Shift left/right Add register + register -> register

This should give basic functionality for a performance penalty.

Reply to
sky465nm

Have you looked at the obvious published options such as Picoblaze? It's tiny. Anything that looks like an ARM9 will NEVER be tiny.

Do you *need* 32-bit? What are you proposing to do with this slow CPU?

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

Take a look at the "light 8080" at open cores. The author made it very small. For fun I moved the registers into block RAM (M4K)and nearly halved the size down to 230 LE on Cyclone 2.

There is enough documentation with the project to get you started.

+------------------------------------------------------------------------------+ ; Fitter Summary ; +------------------------------------+-----------------------------------------+ ; Family ; Cyclone II ; ; Device ; EP2C20F484C7 ; ; Timing Models ; Final ; ; Total logic elements ; 230 / 18,752 ( 1 % ) ; ; Total combinational functions ; 227 / 18,752 ( 1 % ) ; ; Dedicated logic registers ; 99 / 18,752 ( < 1 % ) ; ; Total registers ; 99 ; ; Total pins ; 74 / 315 ( 23 % ) ; ; Total virtual pins ; 0 ; ; Total memory bits ; 16,000 / 239,616 ( 7 % ) ; ; Embedded Multiplier 9-bit elements ; 0 / 52 ( 0 % ) ; ; Total PLLs ; 0 / 4 ( 0 % ) ; +------------------------------------+-----------------------------------------+

snipped-for-privacy@gmail.com wrote:

Reply to
Alex Freed

You do not need a left shift (add suffices) but the right shift is actually a necessary operation.

To the OP: Read fpgacpu.org (outdated but good)

Also see this:

formatting link
formatting link

Kolja Sulimma

Reply to
Kolja Sulimma

Sounds like homework ?. If you want simple, search for MC14500, which will give you a very small opcode set, to start from. If this is targeting FPGA, then better might be Mico8, PicoBlaze, or similar 8 bit variants. Also, if size matters more than speed, you could look at a core optimised to execute from SPI Serial memory, and you could map spare, non-hardcoded opcodes, into a jump table - that allows you to make up more opcodes in firmware.

-jg

Reply to
Jim Granville

I would suggest you check out the 16C54 from Microchip, very simple instruction set and you can find a number of free implementations on the web in both Verilog/VHDL. I my experience writing the software tools take far more time than writing a simply processor so try to use an existing instruction set.

Good luck,

Hans

formatting link

Reply to
HT-Lab

well, there are well-known candidates for SMALL FPGA CPU, but for the following spec

  • 32 bit registers, say block of 16 (use 32 LUTRAM == 16 LUT/LC)
  • serialized can run from spi flash up to 320MBit with
    formatting link
  • can address large code space
  • can run at high fabric clocks (due to lack of parallel buses and parallel ALUs)

now a bit-serialized CPU to the above spec can be done. it would use less than 100 slices.

if anyone is willing to desing this CPU, I may have funds for it, really please...

hm at 320MB/sec spi streaming, we get byte reads at 40Mhz from serial flash!

so this serialized pico-cpu with less than 100 slices would outperform many

8 bit microcontrollers and 8 bit microprocessors of the past.

And as the same flash could be used for FPGA config this 10 MIPS engine comes virtually free.

pls do not suggest that picoblaze, or pic12 or i8080 can do this for this low fabric utilization

Anttis

Reply to
Antti

His homework. ;)

Reply to
David Spencer

formatting link

Hi Antti, How many LUTs in a slice? In other words, what is your target usage in terms of 4-LUTs? Thanks, Syms.

Reply to
Symon

Antti,

As you make a design more and more serial, you will often find yourself forced to add some extra registers. So a totally serial implementation is not necessarily the smallest one. In some of my own experiements, four bits proved to be the optimial size (though I was also taking performance into account when doing the evaluations).

-- Jecel

Reply to
Jecel

But in the Xilinx fabric, for instance, shift registers are very inexpensive. Antti's divider back on 22 Mar 2005 "divide by 2^n, n=3D21..37 =3D=3D> 3 Virtex Slices !!" was an excellent example of serial going very small.

formatting link

1282

Serial logic in FPGAs has some very strong advantages over parallel implementations for speed versus density metrics, allowing the fabric to often run at maximum FPGA clock speeds.

It's great stuff!

- John_H

Reply to
John_H

Do you mean a 4 bit CPU, or a nibble-serial design of a larger

16/20/24/28/32 bit CPU ?

(There are 4 bit CPUs with tool chains, the Atmel MARC4, and the Atom from CoreRiver )

formatting link

-jg

Reply to
Jim Granville

formatting link

Did you mean you have someome to fund this, or that you could do it if someone funds you ?

and you can add a second SPI chip, if you want to double the bandwidth to 80MB/Sec. Of course, the jump latency does not improve, but a matched core design would minimise jumps. Short-Skip opcodes are an obvious cadidate.

-jg

Reply to
Jim Granville

In my case it was a nibble-serial implementation of a 16 bit processor. Antti is asking for large addresses, so the software should probably see 24 to 32 bits.

John_H wrote about shift registers in Xilinx FPGAs. I agree and have created some a really tiny design for a waveform generator using this. The problem I mentioned was that you need parallel addresses, however, and the shifts won't help you there. With a serial external memory you never need the whole address at once and might be able to avoid some registers. The instruction register might also have to be parallel, but by being smart when designing the instruction format you can avoid needing all the bits all the time.

-- Jecel

Reply to
Jecel

formatting link

current funding...

Reply to
Antti

Slow CPUs are usually also not very size efficient.

Maybe this is of interest, it recently found a new home:

formatting link

Reply to
referringto

Nice small instruction set, but maybe too limitd, because even implementing a shift operation (e.g. for implementing multiplication) would need multiple instructions. And 64 bytes of data/code memory doesn't look very useful.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Well, it obviously is not meant for real world applications.

Reply to
referringto

This entire thread has been very interesting in how to "design and build" a CPU from an FPGA.

Even the subject line states this.

However, the OP of this thread was not looking for an education, he was looking for a complete project with little or no work on his part.

This is obvious by his posting from a gmail account.

Everyone who has added to this thread must have assumed that the OP was interested in the "design" of such a device.

I for one thank all those who added to this interesting discussion, I may have learned something myself.

donald

Reply to
donald

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.