Subversion Repositories avs_aes

\documentclass{ruschidoc}

\usepackage[

        bookmarks,

        plainpages={false}]{hyperref}

\usepackage[

        style=altlist,

        toc=true,

        acronym=true]{glossaries}

\usepackage{capt-of}

%%% Water mark

%\usepackage{draftwatermark}

%\SetWatermarkText{\shortstack{DRAFT}}

%\SetWatermarkScale{0.9}

%\SetWatermarkLightness{0.85}

\makeglossaries

\input{glossary}

\bibliographystyle{IEEEtran}

%%%%%%%%%%%%%%%%%

% Document variables

%%%%%%%%%%%%%%%%%

\docDate{ \today }

\docID{avs\_aes\_doc}

\docRevision{0.8}

\docStatus{Final}

\docTitle{\mbox{AES 128/192/256 (ECB)}  \mbox{Avalon\rtm-MM Slave}}

\keywords{Avalon, bus, slave, cryptography, AES, ecb, IP core }

\authorName{\mbox{Thomas Ruschival} \\ and opencores.org}

\authorURL{www.opencores.org}

\authorAddress{\mbox{}}

\authorEmail{ruschi@opencores.org}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% FORMAT: Rev | Chapter |  Description | Date | Reviewer \\

\revisionList{

0.1 & all & initial document & 2009/02/01  & T. Ruschival \\

0.2 & all & added interrupt  & 2009/03/25  & T. Ruschival \\

0.3 & all & added generics  & 2009/04/20  & T. Ruschival \\

0.4 & all & cleanup for opencores.org  & 2009/05/20  & T. Ruschival \\

0.5 & all & final release  & 2010/03/07  & T. Ruschival \\

0.6 & 3,6 & fixed memory map, added testbench description  & 2010/04/02  & T. Ruschival \\

0.7 & 3,6 & fixed typos  & 2010/04/03  & T. Ruschival \\

0.8 & 6 & corrected key schedule  & 2011/05/15  & T. Ruschival \\

}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

\maketitle

\newpage

\tableofcontents

\newpage

\section{Introduction}

\label{sec:intro} The \gls{AES} is a symmetric block cipher operating on fixed block sizes

of 128 Bit and is specified for key sizes of 128, 192 and 256 Bit designed by Joan

Daemen and Vincent Rijmen. The algorithm was standardized by \gls{NIST}. For more

information on the algorithm see \cite{NIST:Fips197}.\\

This component implements an AES encryption decryption data path in \gls{ECB} mode with

either 128,192 or 256 Bit keys.  The key length is determined by generics at compile

time. Also the decryption data path can be disabled by generics if it is not needed

for the application.\\

The component provides an Avalon\rtm\ Memory Mapped (Avalon-MM) slave interface to

connect to an Altera\rtm\ Avalon\rtm\ switch fabric. The Avalon\rtm\ interface is

implemented in a way that it can also be used to connect to a Whishbone master if the

signals are correctly mapped, see \cite{Wiki:AvWb}. For further information about the

Whishbone bus refer to \cite{OC:WBspec}. \\

\section{Interface}

\label{sec:interface}

The AES core is accessed by the interface described in this section. An Avalon\rtm\

interface was chosen for its simplicity and compatibility with wishbone.  Furthermore

Avalon\rtm\ defines interrupt request signals for slaves which would be separate

signals in a Wishbone implementation.The component can be used both in polling

mode or can provide an interrupt for signalling. \\

Unfortunately Avalon\rtm\ is an Altera\rtm\ proprietary technology. The actual AES

core however is a self contained entity and can be embedded into other \gls{SoC} bus

interfaces as well or used independently.

\subsection{Configuration Generics}

\label{sec:generics}

The AES core can be configured by generics shown in table \ref{tab:generics},

consequently they are provided by the Avalon\rtm\ interface.

\begin{tabularx}{\textwidth}{|p{33mm}|p{25mm}|X|}

  \hline

  \bf{Generic name} & \bf{type} & \bf{Description}\\ \hline

  \texttt{KEYLENGTH}  \label{gen:keylength}     & NATURAL   & Size of initial user key. Must be 128, 192 or 256 \footnotemark[1] . \\ \hline

  \texttt{DECRYPTION} \label{gen:decryption}  & BOOLEAN  & Enables the instantiation of the decrypt data path if true. \\

\hline

\end{tabularx}

\footnotetext[1]{All other values raise a compilation failure}

\captionof{table}{Component generics}

\label{tab:generics}

Note: \texttt{KEYLENGTH} of 192 fail synthesis with Xilinx ISE \rtm\ because of division by 6 in key schedule that cannot be mapped to shift operations (\texttt{keyexpansion.vhd}).

\subsection{Signals}

\label{sec:signals}

The Avalon\rtm\-MM Slave interface is described in \cite{Altera:Avalon}, the component

implements the signals shown in table \ref{tab:signals}. All signals are synchronous,

sampled at the rising edge of the clock. The type for all signals is \texttt{IEEE1164

    std\_logic} or \texttt{std\_logic\_vector}. For signals wider that 1 Bit the range

is \gls{MSB} \texttt{downto} \gls{LSB}. \\

This components has only output signals driven by registers no input signals are directly combinatorially connected to the

output signals, thus combinational loops are avoided.  All signals are active

high. This component does not support burst transfers.

\begin{tabularx}{\textwidth}{|p{30mm}|p{11mm}|p{11mm}|X|}

  \hline

  \bf{Signal name} & \bf{Width} & \bf{In/Out} & \bf{Description}\\ \hline

  \texttt{clk}  \label{sig:clk} & 1  &  in  & Avalon\rtm\ bus clock, also used to drive the core. \\ \hline

  \texttt{reset} \label{sig:reset}& 1   &  in  & \emph{Synchronous} reset signal for Avalon\rtm\ bus interface.

  The core itself is designed without need for reset signals.

        \\ \hline

  \texttt{writedata} \label{sig:writedata} & 32 &  in  & Input data to write to location designated by \texttt{address}. Bit 31 is most significant Bit.

        \\  \hline

  \texttt{address}   \label{sig:address}    & 5   &  in & Word offset to the components base address. The memory map of the component for the

  respective offset is described in \ref{sec:memmap}. Only full 32-Bit words can be addressed no byte addressing is implemented.

        \\  \hline

  \texttt{write}\footnotemark[1] \label{sig:write}  & 1 &  in  & If asserted enable write of data at \texttt{writedata} to location designated by \texttt{address}.

        \\  \hline

  \texttt{read}\footnotemark[1] \label{sig:read}   & 1 &  in  & If asserted output data at location designated by \texttt{address} to \texttt{readdata}.

        \\  \hline

  \texttt{readdata} \label{sig:readdata}  & 32  &  out & Data output port for reading data at the location defined by \texttt{address}. Bit 31 is most significant Bit.

        \\  \hline

 \texttt{waitrequest} \label{sig:waitrequest}  & 1  &  out & Asserted if writedata was not accepted, this is the case if the keyexpansion is

         not yet complete and a new is written to the \texttt{KEY} address range without previous deassertion of  the \texttt{KEY\_VALID} Bit

        \\  \hline

  \texttt{irq}\label{sig:irq}   & 1 &  out & If Interrupt behavior is enabled \texttt{IRQ}

  will be asserted when the operation has terminated. For use of interrupt see \ref{sec:irq}

        \\ \hline

\end{tabularx}

\footnotetext[1]{\texttt{read} and \texttt{write} are mutually exclusive and must not be asserted simultaneously.}

\label{tab:signals}

\captionof{table}{Avalon\rtm\ Bus interface signals}

\section{Memory Map}

\label{sec:memmap}

The AES core Avalon\rtm\ slave has an address space of 31 words accessible through the

offset described by the signal \texttt{address}, see \ref{sig:address}. This address

space is divided into three main sections for the 4-word input data, the 4-word

result of the operation and the user key. The actual length of the user key can vary

between 4, 6 and 8 words depending on the keysize. For control signals and status

information of the component and a control word is provided. The memory mapping is

described in table \ref{tab:memmap}.\\

\begin{tabularx}{\textwidth}{|p{18mm}|p{14mm} |X|}

  \hline

  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline

  \texttt{0x00-0x07} & \texttt{KEY}  & Initial user key that will be used for encryption and decryption.

        The most significant word is written to offset \texttt{0x00}. This memory section is \emph{write-only} to the Avalon\rtm\ interface.\\

\hline

  \texttt{0x08-0x0B} & \texttt{DATA} & Input data, can be either interpreted as cyphertext for decryption or plain text for encryption.

        The most significant word shall be written to offset \texttt{0x08}. This memory section is \emph{write-only} to the Avalon\rtm\ interface. \\

\hline

  \texttt{0x10-0x13} & \texttt{RESULT} & Result of the operation. The most significant word of the result at offset \texttt{0x10}.

        This memory section is \emph{read-only} to the Avalon\rtm\ Interface.  \\

\hline

   \texttt{0x14-0x1E} & --- &  reserved  \\ \hline

 \texttt{0x1F} & \texttt{CTRL} & Control and status word of the component can be read and written. Detailed description see \ref{sec:ctrl}\\

\hline

\end{tabularx}

\label{tab:memmap}

\captionof{table}{Memory map of the AES core Avalon\rtm\ slave}

\subsection{Control Register}

\label{sec:ctrl}

The AES Core offers the register \texttt{CTRL} to control the function of the core

and poll its status. The control register can be accessed in read and write mode.

 When writing to the register reserved Bits shall be assigned a value of \texttt{0}.

 Individual Bits have following functionality described in table \ref{tab:ctrlreg}. \\

In case of a Avalon\rtm\ Bus reset this register is set to \texttt{0x00000000} thus

invalidating all previously written keys and resetting the AES core.

\begin{tabularx}{\textwidth}{|p{13mm}|p{18mm} |X|}

  \hline

  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline

  \texttt{31-8} & --- & reserved \\ \hline

  \texttt{7}     &\texttt{KEY\_VALID} &If asserted key data in the \texttt{KEY} memory range is regarded valid and will be expanded to round keys.

        When deasserted all keys are invalidated and the current operation of the core is aborted. It must be asserted as long as the key shall be

        used for either encryption or decryption. This bit must be cleared for one clock cycle to load a new key. \\ \hline

  \texttt{6}   & \texttt{IRQ\_ENA}  & Enable use of the interrupt request signal. If asserted the component will set \texttt{IRQ} after

                                        completing an operation. If not set the component operates in polling mode only.\\ \hline

  \texttt{5-2}   & --- &reserved  \\ \hline

  \texttt{1}    &  \texttt{DEC} \footnotemark[1] &  If asserted memory content of the \texttt{DATA} range is regarded to be valid and will be

        \emph{decrypted}. This Bit shall only be deasserted externally if a running AES operation is aborted by deasserting \texttt{KEY\_VALID}. 1

        It will be set \texttt{0} by the core to signal completion of the operation.\\ \hline

  \texttt{0}    &  \texttt{ENC} \footnotemark[1] & If asserted memory content of the \texttt{DATA} range is regarded to be valid and will be

        \emph{encrypted}. This Bit shall only be deasserted externally if a running AES operation is aborted by deasserting \texttt{KEY\_VALID}.

         It will be set \texttt{0} by the core to signal completion of the operation. \\ \hline

\end{tabularx}

\footnotetext[1]{\texttt{ENC} and \texttt{DEC} are mutually exclusive and must not be asserted simultaneously.}

\label{tab:ctrlreg}

\captionof{table}{Bits in the control register}

\section{Protocol Sequence}

\label{sec:usage}

The AES component appears as memory mapped peripheral. All writes are fundamental slave write transfers, see \cite{Altera:Avalon} and take one

clock cycle of the Avalon\rtm\ bus clock \texttt{clk}. It is not necessary to write all words of a input parameter successively or in one transfer.

Bursts are not supported.\\

\\

Before any AES operation can be started the initial user key has to be written to

\texttt{KEY} segment of the memory map.After the user key is transferred

to the component the \texttt{KEY\_VALID} Bit must be set to start the key

expansion. This Bit can be set simultaneously with \texttt{DEC} or \texttt{ENC} Bit of

the control register. To invalidate the previous key and use another key the

\texttt{KEY\_VALID} must be deasserted for at least one Avalon\rtm\ bus clock cycle

During this cycle the new key can already be transferred.\\

\\

Once a key is passed and marked valid data blocks can be transferred to the

\texttt{DATA} segment of the memory map.

The AES operation is started by asserting the \texttt{ENC} Bit for

encryption or \texttt{DEC} Bit for decryption.

While asserting \texttt{ENC} or \texttt{DEC} the \texttt{KEY\_VALID} Bit must be

kept asserted.\\

The \texttt{ENC} or \texttt{DEC} Bit respectively is deasserted by the component

after completing the requested operation.

The result of the operation can be read from the \texttt{RESULT} area of the memory

and is not cleared. It will be overwritten by succeeding operations.

The underlying AES core uses the \gls{FSM} shown in \ref{fig:aesFSM} for processing of

the data. The signals \texttt{data\_stable} and \texttt{key\_stable} are accessible

over the control status word \texttt{CTRL} \ref{sec:ctrl}. \texttt{key\_ready} is a

signal driven by the key generator when all keys are expanded. The signal

\texttt{round\_index} is the counter for the rounds and the address to select a

round key. \\

\texttt{NO\_ROUNDS} is the total number of rounds the processing takes, a constant

defined by the generic \texttt{KEYLENGTH} \ref{sec:generics}. The AES standard

in\cite{NIST:Fips197} defines 10 rounds for 128 Bit key, 12 rounds for a 192 Bit key

and 14 rounds for a 265 Bit key.\\

Thus depending on the key length the processing of a data block needs at maximum 15

clock cycles from \texttt{data\_stable=1} to completion, if the key is already expanded.

\begin{figure}[!ht]

  \centering

  \includegraphics[width=100mm]{encrypt_FSM}

  \caption{Finite State Machine of encryption and decryption process}

  \label{fig:aesFSM}

\end{figure}

\subsection{Interrupt Behavior}

\label{sec:irq}

By setting \texttt{IRQ\_ENA} in the control register \ref{sec:ctrl} the

component is configured to issue interrupt requests.

If \texttt{IRQ\_ENA} is asserted the interrupt request \texttt{IRQ} \ref{sig:irq} will be set when the

computation has completed in addition to clearing the \texttt{ENC} or \texttt{DEC}

Bit.

The \texttt{IRQ} \ref{sig:irq}  signal will remain set until clearing \texttt{IRQ\_ENA}

or a read operation on the \texttt{RESULT} area of the components address range.

\section{The Inner Core}

\label{sec:core}

The algorithmic core is divided into two separate data paths one for encryption and a

second for decryption operation. The two data paths are independent, however they

share the keyexpansion component which provides decrypt and encrypt keys (which are

the same only in opposite order). Each data path is controlled by its own \gls{FSM}.  If

configured by the generic \texttt{DECRYPTION} \ref{gen:decryption} the decryption

data path is included and some multiplexers are generated for the shared signals,

e.g. \texttt{result} or \texttt{roundkey\_index}.\\

For reference the encryption data path of \texttt{aes\_core.vhd} is given in figure

\ref{fig:aescore}. The decryption data path is left for the reader or any other author

of this document.

\newpage

\begin{figure}[!ht]

  \centering

  \includegraphics[width=0.9\textwidth]{CoreEncDP}

  \caption{Encrypt data path of the AES core as implemented in aes\_core.vhd}

  \label{fig:aescore}

\end{figure}

\newpage

\section{Throughput Calculation}

\label{sec:throughput}

The Avalon\rtm\ interface communicates a 32-Bit DWORD per clock cycle. Therefore a key is transmitted in 4 to 8 cycles

plus one cycle to activate keyexpansion with the control word \ref{sec:ctrl}. A payload data block or the result consist

always of 4 DWORDs, thus it takes 4 cycles to send data to the core, one cycle to activate the computation with the

control register \ref{sec:ctrl} and 4 cycles to retrieve the data.

The keyexpansion component computes one column of a roundkey in two clock cycles. In

the first cycle the column is substituted throught the s-box, in the second cycle the

shift-operation is executed. AES specifies \cite{NIST:Fips197}, depending on the key length $ N_{roundkeys}=\{10,12,14\} $

roundkeys with 4 columns each. The \gls{FSM} of the keyexpansion module adds o clockcycle for the ``DONE'' state.

\begin{equation}

  T_{keyexpansion}(N_{roundkeys}) = 2 \cdot 4 \cdot N_{roundkeys} +1

\label{eqn:keyexp}

\end{equation}

The keyexpansion therefore takes 81, 97 or 115 clockcycles until the encryption or decryption can start. The

roundkeys are stored until invalidated, see \ref{sec:usage} thus this step is is only needed once after power-up until the key changes.

The AES core computes one iteration (round) of the Rijndael-Algorithm each clock cycle, thus a 128 Bit data block is

encrypted or decrypted in 10, 12 or 14 cycles plus an initial round.

The maximum throughput $T_{max}[Bits]$ depends on the maximum operation frequency $f_{max}$ and the key length which

influences the number of rounds $N_{rnd} \epsilon \lbrace 10,12,14 \rbrace $.

\begin{equation}

  T_{max}=\frac{ (1+N_{rnd}) \cdot 128 Bit}{f_{max}}

\label{eqn:tmax}

\end{equation}

Note: Equation \ref{eqn:tmax} assumes that the roundkeys are already generated and does not include the constant of 4+1+4

Avalon\rtm\ bus cycles for transmission of data, activation and result retrieval.

\newpage

\section{FPGA implementations}

\label{sec:fpga}

The component has only be implemented and tested on an Altera\rtm\ Cyclone-II EP2C35

FPGA. For this setup a Makefile is provided in \texttt{./sys/Altera\_Quartus9.1}.  All

other values in the table are only results of synthesis\footnotemark[0] and are not

verified on actual hardware.

\footnotetext[0]{Synthesized with Altera\rtm\ Quartus-II\rtm\ Web edition Version 9.1 or Xilinx\rtm\ ISE 9.1 Webpack}

The design is kept vendor independent in generic VHDL.

AES SubByte component is specially designed using M4K block RAM as dual-port ROM. For

non-Altera\rtm\ FPGAs a second VHDL architecture exists also trying to make use of

ROM functions of the target chips however the success varies on RTL compiler

capabilities. Later versions of  Altera\rtm\ Quartus-II\rtm\ show the same results whether M4K blocks are used or the generic version in selected.

\begin{tabularx}{\textwidth}{|p{30mm}|X|p{20mm}|p{30mm}|p{18mm}|}

  \hline

  \bf{Configuration} & \bf{Target FPGA}\footnotemark[1] & \bf{LE / Slices} & \bf{HW RAM} & $\mathbf{f_{max}[Mhz]}$  \\ \hline

        \multirow{4}{30mm}{256 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 &  - / 1609 & 18 RAMB16BWE & 91 \\ \cline{2-5}

        & \mbox{Xilinx\rtm\ Virtex5}   XC5VLX30-3FF324 &  - / 297 & \mbox{18 18k-Blocks}  \mbox{4 36k-Blocks} & 224 \\ \cline{2-5}

        & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 1937 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 65 \\ \cline{2-5}

        & \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 585 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 103  \\

        \hline

%%%%%%

        \multirow{2}{30mm}{128 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 &  - / 1523 & 18 RAMB16BWE & 91 \\ \cline{2-5}

                & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 1776 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 65 \\

        \hline

%%%%%%

        \multirow{4}{30mm}{256 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A}  XC3S1400A-5FG484 &  - / 680 & 14 RAMB16BWE & 159 \\ \cline{2-5}

        & \mbox{Xilinx\rtm\ Virtex5}   XC5VLX30-3FF324 &  - / 297 & \mbox{10 18k-Blocks}  \mbox{4 36k-Blocks} & 268 \\ \cline{2-5}

        & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 969 / - &  \mbox{22528 Bits} in  \mbox{14 M4K} & 97 \\ \cline{2-5}

        & \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 524 / - &  \mbox{22528 Bits} in \mbox{ 14 M4K} & 145  \\

        \hline

%%%%%%

        \multirow{2}{30mm}{128 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A}  XC3S1400A-5FG484 &  - / 594 & 14 RAMB16BWE & 159 \\ \cline{2-5}

        & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 797 / - & \mbox{22528 Bits} in  \mbox{ 14 M4K} & 95  \\ \cline{2-5}

        \hline

\end{tabularx}

\footnotetext[1]{This table is not meant to be a benchmark between FPGAs of different vendors, it is only a rough

  estimation for the user of the core.

        The FPGA families cannot  be compared easily, see also \cite{Xilinx:wp284} and \cite{Altera:01007}for further details. }

\label{tab:ressources}

\captionof{table}{ressource usage on different targets and configuration}

All configurations in table \ref{tab:ressources} use hardware key

expansion. Downloading of software generated roundkeys is not yet supported. The

decryption and encryption data paths share a common keyexpansion block, multiplexing

the address signals is one of the main reasons for regression of the maximum

frequency $f_{max}$ of the configuration compared to encryption only versions.

\section{Simulation}

\subsection{Testbench}

\label{sec:testbench}

In \texttt{./bench/VHDL/} a ``self-checking testbench'' is provided which runs tests

for a default \texttt{TESTKEYSIZE} is 256 Bit . For different key lengths the

constant \texttt{TESTKEYSIZE} has to be changed appropriately. Expected results for

all test cases and key lengths are included. The expected results were generated by

AES Calculator applet, written by Lawrie Brown from ADFA, Canberra Australia \cite{LaBr05}.  The

testbench consists of a sequence of 5 test cases:

\begin{enumerate}

\item load key1, load data1, encrypt : (basic encryption test)

\item key1, data1, decrypt: (basic decryption test)

\item key1, data1, encrypt: (test if internal state was changed)

\item key1, data2, encrypt: (encryption test with new data)

\item key2, data2, encrypt: (encryption test with new key)

\end{enumerate}

\subsection{Simulation}

\label{sec:simulation}

The component library is ``\texttt{avs\_aes\_lib}''. All files are expected to be

compiled into this library as all files depend at least on the package

\texttt{avs\_aes\_lib.avs\_aes\_pkg}. \\

A Makefile for Mentor Graphics\rtm\ Modelsim\rtm\ is given in \texttt{./sim/}. The

default make target \texttt{simaes} will create the library

``\texttt{avs\_aes\_lib}'' and a ``\texttt{work}'' library, compile all files and run

a testbench. \\

\section{Software Driver}

\label{sec:software}

This AES Core Avalon\rtm\ slave was also tested on a NiosII\rtm\ processor.  To use

it in software a simple driver is provided in \texttt{./sw/} among with an example

program of the basic usage.

The driver consist of the two files \texttt{avs\_aes.c} and \texttt{avs\_aes.h}.

Find more detailed description in the doxygen documentation in \texttt{./doc/sw/html}.

\subsection{Configuration}

To be adapted to different address mappings and key sizes two macros are use in \texttt{avs\_aes.h}:

 \begin{tabularx}{\textwidth}{|p{25mm}|p{25mm} |X|}

  \hline

  \bf{define}     &  \bf{default} & \bf{Description}\\ \hline

  \texttt{KEYWORDS} & \texttt{8}  & Key size in 32 Bit words \\

\hline

  \texttt{AES\_BASEADDR} & \texttt{0x40000} & Base address at which the AES Core is mapped to the Avalon\rtm\ switch-fabric \\

\hline

\end{tabularx}

\label{tab:macros}

\captionof{table}{user changeable macros in header}

\newpage

\section{License and Liability}

\label{sec:license}

The ``AES 128/192/256 (ECB) Avalon\rtm-MM Slave'' component, all its subcomponents

and documentation (like this document you are reading) are published under following

license:\\

Copyright (c) 2009, Thomas Ruschival - All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are

permitted provided that the following conditions are met:

\begin{itemize}

\item Redistributions of source code must retain the above copyright notice, this

  list of conditions and the following disclaimer.

\item Redistributions in binary form must reproduce the above copyright notice, this

  list of conditions and the following disclaimer in the documentation and/or other

  materials provided with the distribution.

\item Neither the name of the organization nor the names of its contributors may be

  used to endorse or promote products derived from this software without specific

  prior written permission.

\end{itemize}

 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"

 AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

 ARE DISCLAIMED. \\

IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE

 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,

 OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

 INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

 CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)

 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF

 THE POSSIBILITY OF SUCH DAMAGE\\

 Note: The term ``SOFTWARE'' in the above licence applies in this case not only to

 software as executable code but also to documentation, hardware description or

 compiled netlists for actual target hardware. As Chips generally don't just

 reproduce ``the above copyright notice, this list of conditions and the following

 disclaimer in the documentation and/or other materials provided with the

 distribution'' the data sheet of the product must also contain it.\\

 Altera, Cyclone-II, Stratix-II, Quartus, NIOS and Avalon are registered trademarks of the Altera

 Corporation

 101 Innovation Drive, San Jose CA USA \\

 Xilinx, Spartan3A and Virtex5 are registered trademarks of Xilinx Inc. 2100 Logic Drive, San Jose CA USA \\

 Mentor Graphics and ModelSim are registered trademarks of Mentor Graphics

 Corporation 8005 SW Boeckman Road, Wilsonville OR USA \newpage

\printglossaries

\bibliography{cited}

\revisionTable

\end{document}