| Line 4... |
Line 4... |
bookmarks,
|
bookmarks,
|
plainpages={false}]{hyperref}
|
plainpages={false}]{hyperref}
|
|
|
\usepackage[
|
\usepackage[
|
style=altlist,
|
style=altlist,
|
hyper=true,
|
toc=true,
|
number=none,
|
acronym=true]{glossaries}
|
acronym=true,
|
|
header=none]{glossary}
|
|
\usepackage{capt-of}
|
\usepackage{capt-of}
|
|
|
%%% Water mark
|
%%% Water mark
|
%\usepackage{draftwatermark}
|
%\usepackage{draftwatermark}
|
%\SetWatermarkText{\shortstack{DRAFT}}
|
%\SetWatermarkText{\shortstack{DRAFT}}
|
%\SetWatermarkScale{0.9}
|
%\SetWatermarkScale{0.9}
|
%\SetWatermarkLightness{0.85}
|
%\SetWatermarkLightness{0.85}
|
|
|
\makeacronym
|
|
\makeglossary
|
\makeglossaries
|
\input{acronym}
|
|
\input{glossary}
|
\input{glossary}
|
\bibliographystyle{IEEEtran}
|
\bibliographystyle{IEEEtran}
|
|
|
%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%
|
% Document variables
|
% Document variables
|
%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%
|
\docDate{ \today }
|
\docDate{ \today }
|
\docID{avs\_aes\_doc}
|
\docID{avs\_aes\_doc}
|
\docRevision{0.5}
|
\docRevision{0.8}
|
\docStatus{Final}
|
\docStatus{Final}
|
\docTitle{\mbox{AES 128/192/256 (ECB)} \mbox{Avalon\rtm-MM Slave}}
|
\docTitle{\mbox{AES 128/192/256 (ECB)} \mbox{Avalon\rtm-MM Slave}}
|
\keywords{Avalon, bus, slave, cryptography, AES, ecb, IP core }
|
\keywords{Avalon, bus, slave, cryptography, AES, ecb, IP core }
|
|
|
\authorName{\mbox{Thomas Ruschival} \\ and opencores.org}
|
\authorName{\mbox{Thomas Ruschival} \\ and opencores.org}
|
| Line 48... |
Line 45... |
0.3 & all & added generics & 2009/04/20 & 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.4 & all & cleanup for opencores.org & 2009/05/20 & T. Ruschival \\
|
0.5 & all & final release & 2010/03/07 & 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.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.7 & 3,6 & fixed typos & 2010/04/03 & T. Ruschival \\
|
|
0.8 & 6 & corrected key schedule & 2011/05/15 & T. Ruschival \\
|
}
|
}
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
\begin{document}
|
\begin{document}
|
| Line 59... |
Line 57... |
\newpage
|
\newpage
|
\tableofcontents
|
\tableofcontents
|
\newpage
|
\newpage
|
|
|
\section{Introduction}
|
\section{Introduction}
|
\label{sec:intro} The \AES is a symmetric block cipher operating on fixed block sizes
|
\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
|
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 \NIST. For more
|
Daemen and Vincent Rijmen. The algorithm was standardized by \gls{NIST}. For more
|
information on the algorithm see \cite{NIST:Fips197}.\\
|
information on the algorithm see \cite{NIST:Fips197}.\\
|
This component implements an AES encryption decryption data path in \ECB mode with
|
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
|
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
|
time. Also the decryption data path can be disabled by generics if it is not needed
|
for the application.\\
|
for the application.\\
|
The component provides an Avalon\rtm\ Memory Mapped (Avalon-MM) slave interface to
|
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
|
connect to an Altera\rtm\ Avalon\rtm\ switch fabric. The Avalon\rtm\ interface is
|
| Line 81... |
Line 79... |
interface was chosen for its simplicity and compatibility with wishbone. Furthermore
|
interface was chosen for its simplicity and compatibility with wishbone. Furthermore
|
Avalon\rtm\ defines interrupt request signals for slaves which would be separate
|
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
|
signals in a Wishbone implementation.The component can be used both in polling
|
mode or can provide an interrupt for signalling. \\
|
mode or can provide an interrupt for signalling. \\
|
Unfortunately Avalon\rtm\ is an Altera\rtm\ proprietary technology. The actual AES
|
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 \SoC\ bus
|
core however is a self contained entity and can be embedded into other \gls{SoC} bus
|
interfaces as well or used independently.
|
interfaces as well or used independently.
|
|
|
\subsection{Configuration Generics}
|
\subsection{Configuration Generics}
|
\label{sec:generics}
|
\label{sec:generics}
|
The AES core can be configured by generics shown in table \ref{tab:generics},
|
The AES core can be configured by generics shown in table \ref{tab:generics},
|
| Line 107... |
Line 105... |
\label{sec:signals}
|
\label{sec:signals}
|
The Avalon\rtm\-MM Slave interface is described in \cite{Altera:Avalon}, the component
|
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,
|
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
|
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
|
std\_logic} or \texttt{std\_logic\_vector}. For signals wider that 1 Bit the range
|
is \MSB\ \texttt{downto} \LSB\. \\
|
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
|
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
|
output signals, thus combinational loops are avoided. All signals are active
|
high. This component does not support burst transfers.
|
high. This component does not support burst transfers.
|
|
|
\begin{tabularx}{\textwidth}{|p{30mm}|p{11mm}|p{11mm}|X|}
|
\begin{tabularx}{\textwidth}{|p{30mm}|p{11mm}|p{11mm}|X|}
|
| Line 227... |
Line 225... |
The \texttt{ENC} or \texttt{DEC} Bit respectively is deasserted by the component
|
The \texttt{ENC} or \texttt{DEC} Bit respectively is deasserted by the component
|
after completing the requested operation.
|
after completing the requested operation.
|
The result of the operation can be read from the \texttt{RESULT} area of the memory
|
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.
|
and is not cleared. It will be overwritten by succeeding operations.
|
|
|
The underlying AES core uses the \FSM\ shown in \ref{fig:aesFSM} for processing of
|
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
|
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
|
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
|
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
|
\texttt{round\_index} is the counter for the rounds and the address to select a
|
round key. \\
|
round key. \\
|
| Line 263... |
Line 261... |
\section{The Inner Core}
|
\section{The Inner Core}
|
\label{sec:core}
|
\label{sec:core}
|
The algorithmic core is divided into two separate data paths one for encryption and a
|
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
|
second for decryption operation. The two data paths are independent, however they
|
share the keyexpansion component which provides decrypt and encrypt keys (which are
|
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 \FSM\. If
|
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
|
configured by the generic \texttt{DECRYPTION} \ref{gen:decryption} the decryption
|
data path is included and some multiplexers are generated for the shared signals,
|
data path is included and some multiplexers are generated for the shared signals,
|
e.g. \texttt{result} or \texttt{roundkey\_index}.\\
|
e.g. \texttt{result} or \texttt{roundkey\_index}.\\
|
For reference the encryption data path of \texttt{aes\_core.vhd} is given in figure
|
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
|
\ref{fig:aescore}. The decryption data path is left for the reader or any other author
|
| Line 285... |
Line 283... |
The Avalon\rtm\ interface communicates a 32-Bit DWORD per clock cycle. Therefore a key is transmitted in 4 to 8 cycles
|
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
|
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
|
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.
|
control register \ref{sec:ctrl} and 4 cycles to retrieve the data.
|
|
|
The keyexpansion component computes one column of a roundkey each clock cycle. AES takes, depending on the key length,
|
The keyexpansion component computes one column of a roundkey in two clock cycles. In
|
10, 12 or 14 roundkeys with each 4 columns, see \cite{NIST:Fips197}. The keyexpansion therefore takes 40, 48 or 56
|
the first cycle the column is substituted throught the s-box, in the second cycle the
|
cycles until the encryption or decryption can start. The roundkeys are stored until invalidated, see \ref{sec:usage}
|
shift-operation is executed. AES specifies \cite{NIST:Fips197}, depending on the key length $ N_{roundkeys}=\{10,12,14\} $
|
thus this step is is only needed once after power-up until the key changes.
|
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
|
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.
|
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
|
The maximum throughput $T_{max}[Bits]$ depends on the maximum operation frequency $f_{max}$ and the key length which
|
| Line 354... |
Line 358... |
decryption and encryption data paths share a common keyexpansion block, multiplexing
|
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
|
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.
|
frequency $f_{max}$ of the configuration compared to encryption only versions.
|
|
|
\section{Simulation}
|
\section{Simulation}
|
\label{sec:simulation}
|
|
\subsection{Testbench}
|
\subsection{Testbench}
|
\label{sec:testbench}
|
\label{sec:testbench}
|
In \texttt{./bench/VHDL/} a ``self-checking testbench'' is provided which runs tests
|
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
|
for a default \texttt{TESTKEYSIZE} is 256 Bit . For different key lengths the
|
constant \texttt{TESTKEYSIZE} has to be changed appropriately. Expected results for
|
constant \texttt{TESTKEYSIZE} has to be changed appropriately. Expected results for
|
| Line 451... |
Line 454... |
101 Innovation Drive, San Jose CA USA \\
|
101 Innovation Drive, San Jose CA USA \\
|
Xilinx, Spartan3A and Virtex5 are registered trademarks of Xilinx Inc. 2100 Logic 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
|
Mentor Graphics and ModelSim are registered trademarks of Mentor Graphics
|
Corporation 8005 SW Boeckman Road, Wilsonville OR USA \newpage
|
Corporation 8005 SW Boeckman Road, Wilsonville OR USA \newpage
|
|
|
\printacronym
|
\printglossaries
|
\printglossary
|
|
|
|
\bibliography{cited}
|
\bibliography{cited}
|
\revisionTable
|
\revisionTable
|
|
|
\end{document}
|
\end{document}
|
