Lightweight 8051 compatible CPU

Description

Yet another free 8051 FPGA core.

This is a 6-clocker-equivalent implementation of the MCS51 architecture, aiming at area performance.

A full description of the core features can be found in the datasheet.

Though the core has already executed a Dhrystone benchmark in actual hardware (see below), it is still immature for actual use. A comprehensive test bench has yet to be developed, for starters.

Performance

Synthesis

These are the synthesis results for the Dhrystone demo:

Device	Synthesis Options	Clock Rate	CPU	Timer	UART	Total
Altera Cyclone-2 (-C7)	Balanced	62 MHz	997 LEs + 29M4Ks + 1MUL9	85 LEs	147 LEs	1349 LEs + 29M4Ks + 1MUL9
Xilinx Spartan-3A (-4)	Balanced	35 MHz	1162 LUTs + 10BRAMs + 1MUL18	66 LUTs	99 LUTs	1424 LUTs + 10BRAMs + 1MUL18

These results have been produced with Quartus-2 11.1 sp2 and Xilinx ISE WebPack 14.3, using the project files included. The synthesis has been performed with a simple clock rate constraint (Fclk > 50MHz for the Cyclone-2 and > 16MHz for the Spartan-3) and the results must be considered illustrative only.

The Dhrystone demo includes 12KB of ROM and 2 KB of XRAM, besides the IRAM. The CPU itself uses a single memory block (M4K or BRAM) for the IRAM memory bank, all other blocks are XCODE and XDATA memory which can be configured through generics.
Also included in the total resource count are the default i/o ports and some amount of glue logic (7-segment encoders, etc.) plus any LUTs used as route-through.

The CPU includes the optional BCD instructions (DA and XCHD). Excluding them saves about 30 LEs in the cyclone version and does not affect the clock rate.


Note that the number of BRAM blocks in the Spartan-3 version does not add up -- see bug tracker. The Dhrystone demo has worked on a Spartan3A dev board, though.

Bear in mind that the timer and the UART included in the demo are not equivalent those of the MCS51; the peripherals have been heavily simplified (UART and timer are independent, for example, and the only UART parameter that is programmable in the current version is the baud rate. More info in the datasheet.).

Benchmark Results

The MCU has executed a version of the Dhrystone 2.1 benchmark, adapted for MCUs by ECROS Technology and slightly modified to suit the light52 core. It has been compiled with SDCC with default options.

The benchmark has been executed on a DE-1 development board with a Cyclone-II FPGA clocked at 50 MHz using the Quartus-II project file included with this project. The benchmark executes 25000 iterations over the Dhrystone loop and produces the following results:

Dhrystone 2.1 Benchmark Results
1646	Dhrystones per second @ 50MHz
0.9368	Dhrystone MIPS
0.0187	Dhrystone MIPS per MHZ

(One Dhrystone MIPS is defined as 1757 Dhrystones per second.)

According to the figures that can be found in this description of one of CAST's single-clocker 8051s, the above benchmark results are about twice as fast as an original 12-clocker 8051 in DMIPS/MHz, and about five times slower than a single-clocker (at the same clock rate). So this core can be characterized as a '6-clocker-equivalent'.

The actual cycle count for the instructions can be found in the core datasheet and ranges from 2 to 8 cycles (except DIV, which takes 10 cycles).

Status

The core has been tried on two development boards for which support files are included (a top entity, pin constraints file and a project file).
The project files are set up to use the Dhrystone demo object code to initialize the XCODE ROM so that they can be tried without installing SDCC or any MCS51 toolchain.
They can easily be used with any other program by using the appropriate package, as explained in the datasheet.

The supported boards are Terasic's DE-1 board for Cyclone-II and Avnet's Spartan-3A Evaluation Kit (an old board for which no link is available).


In short, this is the current status of the project:

1.	- Design and implementation finished.
2.	- Already tried on real hardware (Dhrystone demo on Cyclone-2 and Spartan-3A FPGAs).
3.	- No documentation other than this page, a 'quickstart' file and a draft of the datasheet.
4.	- Has not yet passed a rigorous test bench (so no test coverage info is available).

The core has passed a basic test bench that exercises all opcodes and does basic functional tests of the interrupt logic. Also it has already run a non-trivial program like Dhrystone on real chips. This means that probably few bugs remain, if any.
Yet, until a strong test bench is developed, the core must be considered suspect or 'beta'.

The next step is adding some much-needed design document explaining the internals of the core plus a detailed explanation of how the crudely hacked software simulator (source included) is used as a verification 'golden model'. Usage instructions for the core are missing too.

Until the core passes a really exhaustive test bench, you use this core at your own risk -- it has worked so far but it probably still has bugs.

If you want to try it anyway, check out file /doc/quickstart.txt and don't hesitate to contact me if you need help!

Updates

Rev. 26 (Dec. 6th 2013)
Fixed a bug affecting bit operations targetting the ACC as an SFR.
Thanks to Stephane Bouyat, who caught the bug and also gave me the solution!
It's taken me 3 months to fix it because I´ve been relocating; now I have a development system again so further bugs will hopefully be fixed in a reasonable time :)

Rev. 20 (Feb. 3rd 2013)
Interrupt handling has been refactored to make it fully compatible to the original.
Register IP has been implemented and the irq test code (what little there is of it) has been updated accordingly.

Rev. 15 (Jan. 28th 2013)
Fixed bug in DJNZ state 'djnz_dir_0'; instruction 'DJNZ dir' failed when addressing an SFR instead of an IRAM location (see bug tracker). Revision 14 passes the (modified) test bench and runs OK on the DE-1 board with the Dhrystone demo.
The test bench was weak enough to let this bug slip through; it has been modified to test DJNZ with both IRAM and SFR addresses but it is still very weak.
I have modified the CPU test code to use IRAM and SFR addresses when testing direct addressing mode instructions; the new code has not uncovered any new bugs other than the DJNZ bug just fixed.
Thanks to the anonymous user who caught this bug!

Rev. 9 (Nov. 27th 2012)
Replaced the absolute output path in the Quartus-2 project file with an equivalent relative path.
Thankfully, Quartus-2 by default uses relative paths to point to source files...

Rev. 8 (Nov. 24th 2012)
Added a new project file and top entity for Avnet's Spartan-3A Evaluation Kit.
Added a new 'led blinker' mini-demo to be used as a 'sanity check' on a board with no display or serial port, like Avnet's.