Main Page   Modules   Related Pages  

Introduction

What's AVR?
AVR is an 8 bit microcontroller family currently produced by Atmel Corporation.
The AVR instruction set is physically implemented and sold on the market as a bunch of controllers, sharing the same AVR core but differing on peripheral / RAM / ROM capabilities: from the TinyAVR controllers with 1KB flash ROM, no RAM, and 8 pins, up to MegaAVR controllers with 128KB flash ROM, 4KB RAM, 4KB EEPROM, 10 bit ADC with 8 channels, timers, comparators, JTAG, etc.

With Atmel's physical implementation of the AVR instruction set, most instructions take one clock. 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. Atmel's implementation has a short pipeline, with 2 stages (fetch and execute).
With Atmel's 0.5µm technology (I think) these cores run at 16MHz at most.

The key to the relative success of the AVR architecture is a (relatively) well designed instruction set. It is (almost) RISC and (almost) orthogonal. Now you'll probably say: "Heck, everything is almost ok! Why not choosing to implement a controller with a damn good instruction set?" Well, because I couldn't find any. As I wanted to clone an 8 bit controller currently on the market, I resisted the temptation to build my own "perfect" instruction set, because I should have also written some of the associated software (assembler, compiler, simulator, etc), and that would have taken more time than designing the controller itself. Not to say that I'd probably be the only one using that controller. Imperfect as it is, the AVR instruction set is still relatively good when compared to other 8 bit controllers on the market.
Now, looking back, I wonder why didn't I hint higher, to clone ARM7 instead. That should be a neat and easy design, because it's orthogonal and built with the pipeline concept in mind, unlike AVR.
What's pAVR?
pAVR is an 8 bit controller that is compatible with Atmel's AVR architecture.
pAVR stands for "pipelined AVR".
pAVR 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 accent was put on the core itself, where just about everything is costumizable. The peripherals were given only a secondary importance. A timer and an 8 bit I/O port were implemented, for demo purposes. Adding new peripherals won't be difficult, I think. A costumizable interrupt system is provided that can be used by new peripherals.
The main goal was to obtain a controller 100% compatible with the AVR instruction set that is as powerful as possible (in terms of MIPS), with a work budget of about 6 months*man.

Size does matter - pAVR has a deep pipeline, with 6 stages
At the very beginning, I tried to figure out how to design a processor (much) faster than Atmel's.
As Atmel's core already executes most instructions in one clock, two ideas came quick in my mind: a deeper pipeline and issuing more than one instruction per clock (multi-issue).
A deeper pipeline is relatively straightforward. I expected a clock speed increase of about 3 from a well balanced 6 stage pipeline. However, one can predict that the resulted average CPI is slightly bigger than AVR's, 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.
I quickly rejected the multi-issue approach. The available time budget was too small for implementing both a deep pipeline and multi-issuing. On the other hand, multi-issue without a deeper pipeline wouldn't have made much sense.
Result
pAVR is a parameterizable and synthesizable VHDL design, AVR-compatible, that has:

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

The release distribution contains only the documentation. However, all the VHDL sources are embedded into the documentation, and are thus easily accessible.
This is useful for those who want just to test pAVR or want to find what is pAVR, without trying to modify it to make it better (for the latter ones there's the devel pack).
The release distribution comes in two flavors: CHM or HTML. My favorite is CHM, because it's much more compact. I kept HTML for portability issues.

The devel distribution contains In short, 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, most software tools used here have Linux counterparts (Doxygen, VHDL simulator, C compiler, TCL interpreter, text editor). Exceptions are Atmel's AVR assembler & simulator, which are Windows only, as far as I know.

The documentation is generated via Doxygen. For those who don't know how about this wonderful tool, please check www.doxygen.org .

The directory structure of the devel pAVR project is:
pAVR
   doc
      chm
      html
   src
   synthesis
   test
      gentest 
      sieve
      stefan
      waves
   tools
      backup
      build_vhdl_hdr
      build_vhdl_test
      common
In the "doc" directory is the documentation of course. It's available in source format. Run Doxygen to compile it and obtain the HTML and CHM in the HTML and CHM folders. Some scripts are also provided in the doc folder, that can be used to compile the documentation, clean it up, or run (view) it.
The "src" folder contains the VHDL sources, VHDL tests, some Modelsim macro files and the license file.
The "test" folder contains the test programs (ASM and ANSI C) with which pAVR was tested so far.
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 VHDL comments. For example, some tags isolate non-synthesizable code that can easily removed when synthesizing pAVR. The preprocessor parses the sources and interprets the tags. The preprocessor is also used to insert a common header into all VHDL source files.
The "tools" folder also contains some scripts that build devel or release packages.

The source files 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 will soon be synthesized into an FPGA.

Workflow
Throughout this project there 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 (sub-project's folder). 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. Placing shortcuts to the TCL console in each sub-project's folder allows me using only one copy of the project manager for all sub-projects. (Neat, isn't it? Huh, you didn't understand anything? Hmm, I'm not much of a writer...)



Generated on Sat Jul 3 08:13:38 2004 for Pipelined AVR microcontroller by doxygen1.2.12 written by Dimitri van Heesch, © 1997-2001