The source code is developed at https://github.com/devsaurus/t48.
The T48 µController core is an implementation of the MCS-48 microcontroller family architecture. While being a controller core for SoC, it also aims for code-compatability and cycle-accuracy so that it can be used as a drop-in replacement for any MCS-48 controller. The core also provides a variant that implements the specific features of the UPI-41A/41AH/42/42AH device family.
It can be configured to better suit the requirements and characteristics of the integrating system. On the other hand, nearly the full functionality of a stock 8048/8049 and 8021/8022 is available.
Such a sample system has been implemented in several FPGA families.
The implementation has been done with the free version of the vendor tools (Quartus II 7.2sp3 and ISE 10.1). Your mileage may vary.
Altera EP1C12Q240C8:
Xilinx Spartan-IIE XC2S300EPQ208-6:
Alongside with the microcontroller design, an implementation of the 8243 I/O expander chip is available.
The T48 µController has been successfully integrated in the FPGA Donkey Kong, the FPGA Adventure Vision, and the FPGA Videopac projects.
The project has Stable status:
The first step of this project was to collect information of the original MCS-48 family architecture. The available documents were bundled in electronic form and represent a superset of the architecture specification for the T48 µController. Download this document here: mcs-48.pdf (link is external to OpenCores.org).
The latest release of the T48 µController project is version 1.4.
Get this and all previous versions of the design files from SVN: Download repository.
Development code is available at https://github.com/devsaurus/t48.
You should also check the Tracker for known bugs and see if they affect your work.
The verification of the T48 µController core is based on self-checking assembler tests that are executed with one single testbench. All test programs contribute to the regression suite that allows automated, scripts-based verification whenever the design files have changed.
The test suite will be split up into two parts. First, a set of tests is generated to proof that each single instruction works in the expected way. As this excludes all implementation specific issues and only looks at the architectural features, these tests are called black-blox tests.
When issues with the internal implementation of some features arise, more in-depth tests are necessary to stimulate the design in a way that triggers potential bugs. These tests form the white-box test suite.
A C-model of the core architecture is available that is used as a reference for the hardware design. This model is implemented as an executable program (native compiled code for the host system) and has been used for years now within the MAME project. It executes the same assembler tests of the regression suite and by comparing the machine state after each instruction with the RTL implementation it acts as a instruction-cycle accurate reference.
The following tools are integrated and are required for this project: