head 1.1; branch 1.1.1; access ; symbols noReleaseTag: noVendorName:1.1.1; locks ; strict; comment @# @; 1.1 date 2003.; author doru; state Exp; branches; next ; date 2003.; author doru; state Exp; branches ; next ; desc @@ 1.1 log @Initial revision @ text @ Introduction
Main Page   Modules   Related Pages  


This project implements an 8 bit controller that is compatible with Atmel's AVR architecture, using VHDL (Very High speed integrated circuits Hardware Definition Language).
The device built here is not a specific controller of the AVR family, but rather a maximally featured AVR controller. It is configurable enough to be able to simulate most AVR family controllers.
The goal is to obtain an AVR processor that is as powerful as possible (in terms of MIPS), with a work budget of about 6 months*man.

Atmel's AVR core is reasonably fast, among the other 8 bit controllers on the market (year 2002). Most instructions take one clock. The instruction set is (almost) RISC. In real life applications, the average clocks per instruction (CPI) is typically 1.2...1.7, depending on the application. CPI=1.4 is a good average. The core has a short pipeline, with 2 stages (fetch and execute). With Atmel's 0.5um technology, the core runs at 10...15 MHz.

From the start were searched ways to improve original core's performance.
As the original core already executes most instructions in one clock, two ideas come quick in mind: a deeper pipeline and issuing more than one instruction per clock (multi-issue).
A deeper pipeline is relatively straightforward. A clock speed increase of about 3...4x is expected from a 5 or 6 stages pipeline. However, the resulted average CPI is expected to be slightly bigger than the original, mainly because of jumps, branches, calls and returns. They require the pipeline to be flushed, at least partially, thus some clocks are lost while refilling the pipeline.
The multi-issue approach was quickly rejected. The available time budget is too small for implementing both a deep pipeline and multi-issuing. On the other hand, multi-issue without a deeper pipeline wouldn't make much sense.

pAVR is a parameterizable and synthesizable VHDL design, AVR-compatible, that has:

The sources structure is modularized. The sources are written based on a set of common-sense conventions (the process splitting strategy, signals naming, etc). Thus, pAVR is quite an easily maintainable design.
Extensive testing was carried out.
pAVR is to be synthesized and burned into a FPGA.

Project structure
This project is distributed in two forms: release and devel (development).

The devel distribution contains In a word, the devel structure contains anything that is needed for one to develop this project further. As a side note, this project was developed under Windows XP. Yet, all the main software tools used here have Linux counterparts (Doxygen, VHDL simulator, C compiler, TCL interpreter, text editor).
The documentation is generated via Doxygen. For those who don't know how to use this wonderful tool, please check www.doxygen.org .
In the "doc" directory can be found the sources of the documentation. Also, here are some scripts for compiling the documentation, cleaning it up, or running (viewing) it.
In the "doc/html" folder is placed the compilation result (HTML). The HTML documentation is further compiled into a .CHM (compressed HTML) file that is placed in the "doc/chm" folder. CHM is a very convenient file format, providing about all the features of HTML, plus that it's very small due to compression and very handy (a single file instead of a bunch of files and folders). However, this file format is still Windows-bound. There are neither compilers nor viewers for Linux (but things might change soon...).
The "src" folder contains pAVR VHDL sources, VHDL tests and some Modelsim macro files.
The "test" folder contains the test programs (ASM and ANSI C) with which pAVR was tested.
The "tools" folder contains some utilities. The most important utility is a text preprocessor. In the VHDL sources are placed XML-like tags, inserted as comments. The preprocessor parses these sources and interprets the XML-like tags. For example, some tags isolate non-synthesizable code that can easily removed when synthesizing pAVR. The preprocessor is also used to insert a common header into all VHDL sources.
Also, in the "tools" folder are some scripts that build devel or release packages.

The release distribution contains only the documentation. However, all the VHDL sources are embedded into the documentation, and are thus easily accessible.
The release distribution comes in two flavors: HTML or CHM. My favorite is CHM, because it's much more compact. However, for viewing the documentation under Linux, HTML is still needed.

Throughout this project are a few sub-projects that must be edited/compiled/run independently (for example, generating the documentation, or compiling test sources). For this purpose, I use a TCL console with stdin/stdout/stderr, and a few buttons: edit/compile/run/clean. Each button launches a script with the same name as the button, placed in the same folder as the console script. The stdout/stderr of the scripts are captured on the TCL console. I use this "project manager" (the TCL console) the very same way for, let's say, compiling a C source or generating Doxygen documentation.

Generated on Tue Dec 31 20:26:30 2002 for Pipelined AVR microcontroller by doxygen1.2.16
@ log @Importing into repository the new directory structure. @ text @@