URL
https://opencores.org/ocsvn/pavr/pavr/trunk
Subversion Repositories pavr
[/] [pavr/] [trunk/] [doc/] [html/] [group__pavr__intro.html] - Rev 6
Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> <title>Introduction</title> <link href="doxygen.css" rel="stylesheet" type="text/css"> </head><body> <!-- Generated by Doxygen 1.2.16 --> <center> <a class="qindex" href="main.html">Main Page</a> <a class="qindex" href="modules.html">Modules</a> <a class="qindex" href="pages.html">Related Pages</a> </center> <hr><h1>Introduction</h1><table border=0 cellpadding=0 cellspacing=0> </table> <dl compact><dt><b> Goal</b><dd> This project implements an <b>8</b> <b>bit</b> <b>controller</b> that is compatible with Atmel's <a class="el" href="group__pavr__avrarch.html">AVR architecture</a>, using <b>VHDL</b> (Very High speed integrated circuits Hardware Definition Language). <br> 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. <br> <b>The</b> <b>goal</b> 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. <br> <br> </dl><dl compact><dt><b> Approach</b><dd> 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. <br> <br> From the start were searched ways to improve original core's performance. <br> 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). <br> 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. <br> 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. <br> <br> </dl><dl compact><dt><b> Result</b><dd> pAVR is a <b>parameterizable</b> and <b>synthesizable</b> VHDL design, AVR-compatible, that has: <br> <ul> <li> 6 pipeline stages <li> 1 instruction/clock for most instructions <li> estimated clock frequency: <b>~50</b> <b>MHz</b> & <b>0.5</b> <b>um</b>; assuming that Atmel's core runs at 15 MHz & 0.5 um. <br> 3x Atmel original core's performance. <li> estimated MIPS at 50 MHz: <b>28</b> <b>MIPS</b> (typical), <b>50</b> <b>MIPS</b> (peak) <br> 3x Atmel original core's performance.. At 15 MHz, Atmel's core has 10 MIPS typical, and 15 MIPS peak. <li> CPI: 1.7 clocks/instruction (typical), 1 clock/instruction (peak) <br> 0.75x (typical), 1.00x (peak) Atmel original core's performance. <li> pAVR architecture is rather computational-friendly than control-friendly. <a class="el" href="group__pavr__pipeline__jumps.html">Jumps</a>, <a class="el" href="group__pavr__pipeline__branches.html">branches</a>, <a class="el" href="group__pavr__pipeline__skips.html">skips</a>, <a class="el" href="group__pavr__pipeline__calls.html">calls</a> and <a class="el" href="group__pavr__pipeline__returns.html">returns</a> are relatively expansive in terms of clocks. A branch prediction scheme and a smarter return procedure might be considered as upgrades. </ul> <br> The <a class="el" href="group__pavr__src.html">sources</a> structure is <b>modularized</b>. The sources are written based on a set of common-sense <a class="el" href="group__pavr__src.html#pavr_src_conv">conventions</a> (the process splitting strategy, signals naming, etc). Thus, pAVR is quite an easily <b>maintainable</b> design. <br> Extensive <a class="el" href="group__pavr__test.html">testing</a> was carried out. <br> pAVR is to be synthesized and burned into a <a class="el" href="group__pavr__fpga.html">FPGA</a>. <br> <br> </dl><dl compact><dt><b> Project structure</b><dd> This project is distributed in two forms: <b>release</b> and <b>devel</b> (development). <br> <br> The <b>devel</b> distribution contains <ul> <li> pAVR documentation <li> VHDL sources for pAVR and associated VHDL tests <li> test programs <li> some utilities (preprocessor, some useful scripts) </ul> 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). <br> The documentation is generated via Doxygen. For those who don't know how to use this wonderful tool, please check <a target="top" href="http://www.doxygen.org"> www.doxygen.org </a>. <br> 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. <br> 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...). <br> The "src" folder contains pAVR VHDL sources, VHDL tests and some Modelsim macro files. <br> The "test" folder contains the test programs (ASM and ANSI C) with which pAVR was tested. <br> 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. <br> Also, in the "tools" folder are some scripts that build devel or release packages. <br> <br> The <b>release</b> distribution contains only the documentation. However, all the VHDL sources are embedded into the documentation, and are thus easily accessible. <br> 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. <br> <br> 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. <br> <br> <br> </dl><hr><address align="right"><small>Generated on Tue Dec 31 20:26:30 2002 for Pipelined AVR microcontroller by <a href="http://www.doxygen.org/index.html"> <img src="doxygen.png" alt="doxygen" align="middle" border=0 width=110 height=53></a>1.2.16 </small></address> </body> </html>