OpenCores
URL https://opencores.org/ocsvn/avs_aes/avs_aes/trunk

Subversion Repositories avs_aes

[/] [avs_aes/] [trunk/] [doc/] [manual/] [src/] [avs_aes.tex] - Diff between revs 11 and 16

Go to most recent revision | Show entire file | Details | Blame | View Log

Rev 11 Rev 16
Line 47... Line 47...
0.2 & all & added interrupt  & 2009/03/25  & T. Ruschival \\
0.2 & all & added interrupt  & 2009/03/25  & T. Ruschival \\
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 \\
}
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 
 
 
\begin{document}
\begin{document}
Line 58... Line 59...
\newpage
\newpage
\tableofcontents
\tableofcontents
\newpage
\newpage
 
 
\section{Introduction}
\section{Introduction}
\label{sec:intro} The \AES is a symmetric block cypher operating on fixed block sizes
\label{sec:intro} The \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 \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 datapath in \ECB mode with
This component implements an AES encryption decryption datapath in \ECB mode with
either 128,192 or 256 Bit keys.  The keylength is determined by generics at compile
either 128,192 or 256 Bit keys.  The keylength is determined by generics at compile
Line 81... Line 82...
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 selfcontained entity and can be embedded into other \SoC\ bus
core however is a selfcontained entity and can be embedded into other \SoC\ bus
interfaces as well or used indepentently.
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},
consequently they are provided by the Avalon\rtm\ interface.
consequently they are provided by the Avalon\rtm\ interface.
Line 121... Line 122...
  The core itself is designed without need for reset signals.
  The core itself is designed without need for reset signals.
        \\ \hline
        \\ \hline
  \texttt{writedata} \label{sig:writedata} & 32 &  in  & Input data to write to location designated by \texttt{address}. Bit 31 is most significant Bit.
  \texttt{writedata} \label{sig:writedata} & 32 &  in  & Input data to write to location designated by \texttt{address}. Bit 31 is most significant Bit.
        \\  \hline
        \\  \hline
  \texttt{address}   \label{sig:address}    & 5   &  in & Word offset to the components base address. The memory map of the component for the
  \texttt{address}   \label{sig:address}    & 5   &  in & Word offset to the components base address. The memory map of the component for the
  respective offest is described in \ref{sec:memmap}. Only full 32-Bit words can be addressed no byte addressing is implemented.
  respective offset is described in \ref{sec:memmap}. Only full 32-Bit words can be addressed no byte addressing is implemented.
        \\  \hline
        \\  \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}.
  \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
        \\  \hline
  \texttt{read}\footnotemark[1] \label{sig:read}   & 1 &  in  & If asserted output data at location designated by \texttt{address} to \texttt{readdata}.
  \texttt{read}\footnotemark[1] \label{sig:read}   & 1 &  in  & If asserted output data at location designated by \texttt{address} to \texttt{readdata}.
        \\  \hline
        \\  \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.
  \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
        \\  \hline
 \texttt{waitrequest} \label{sig:waitrequest}  & 1  &  out & Asserted if writedata was not accepted, this is the case if the keyexpansion is
 \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
         not yet complete and a new is written to the \texttt{KEY} address range without previous deassertion of  the \texttt{KEY\_VALID} Bit
        \\  \hline
        \\  \hline
  \texttt{irq}\label{sig:irq}   & 1 &  out & If Interrupt behaviour is enabled \texttt{IRQ}
  \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}
  will be asserted when the operation has terminated. For use of interrupt see \ref{sec:irq}
        \\ \hline
        \\ \hline
\end{tabularx}
\end{tabularx}
\footnotetext[1]{\texttt{read} and \texttt{write} are mutually exclusive and must not be asserted simultanously.}
\footnotetext[1]{\texttt{read} and \texttt{write} are mutually exclusive and must not be asserted simultaneously.}
\label{tab:signals}
\label{tab:signals}
\captionof{table}{Avalon\rtm\ Bus interface signals}
\captionof{table}{Avalon\rtm\ Bus interface signals}
 
 
 
 
\section{Memory Map}
\section{Memory Map}
\label{sec:memmap}
\label{sec:memmap}
The AES core Avalon\rtm\ slave has an address space of 31 words accessable through the
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
offset described by the signal \texttt{address}, see \ref{sig:address}. This address
space is devided into three main sections for the 4-word input data, the 4-word
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 lenght of the userkey can vary
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
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
information of the component and a control word is provided. The memory mapping is
descibed in table \ref{tab:memmap}.\\
described in table \ref{tab:memmap}.\\
 
 
\begin{tabularx}{\textwidth}{|p{18mm}|p{14mm} |X|}
\begin{tabularx}{\textwidth}{|p{18mm}|p{14mm} |X|}
  \hline
  \hline
  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline
  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline
  \texttt{0x00-0x07} & \texttt{KEY}  & Initial user key that will be used for encryption and decryption.
  \texttt{0x00-0x07} & \texttt{KEY}  & Initial user key that will be used for encryption and decryption.
Line 174... Line 175...
 
 
\subsection{Control Register}
\subsection{Control Register}
\label{sec:ctrl}
\label{sec:ctrl}
The AES Core offers the register \texttt{CTRL} to control the function of the core
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.
and poll its status. The control register can be accessed in read and write mode.
 When wrriting to the register reserved Bits shall be assigned a value of \texttt{0}.
 When writing to the register reserved Bits shall be assigned a value of \texttt{0}.
 Individual Bits have following functionality decribed in table \ref{tab:ctrlreg}. \\
 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
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.
invalidating all previously written keys and resetting the AES core.
 
 
\begin{tabularx}{\textwidth}{|p{13mm}|p{18mm} |X|}
\begin{tabularx}{\textwidth}{|p{13mm}|p{18mm} |X|}
  \hline
  \hline
  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline
  \bf{Offset}     & \bf{Name} & \bf{Description}\\ \hline
  \texttt{31-8} & --- & reserved \\ \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 roundkeys.
  \texttt{7}     &\texttt{KEY\_VALID} &If asserted key data in the \texttt{KEY} memory range is regarded valid and will be expanded to roundkeys.
        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
        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 cylce to load a new key. \\ \hline
        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
  \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
                                        completing an operation. If not set the component operates in polling mode only.\\ \hline
  \texttt{5-2}   & --- &reserved  \\ \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
  \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
        \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
        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
  \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}.
        \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
         It will be set \texttt{0} by the core to signal completion of the operation. \\ \hline
\end{tabularx}
\end{tabularx}
\footnotetext[1]{\texttt{ENC} and \texttt{DEC} are mutually exclusive and must not be asserted simultanously.}
\footnotetext[1]{\texttt{ENC} and \texttt{DEC} are mutually exclusive and must not be asserted simultaneously.}
\label{tab:ctrlreg}
\label{tab:ctrlreg}
\captionof{table}{Bits in the control register}
\captionof{table}{Bits in the control register}
 
 
 
 
\section{Protocol Sequence}
\section{Protocol Sequence}
Line 210... Line 211...
Bursts are not supported.\\
Bursts are not supported.\\
\\
\\
Before any AES operation can be started the initial userkey has to be written to
Before any AES operation can be started the initial userkey has to be written to
\texttt{KEY} segment of the memory map.After the user key is transferred
\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
to the component the \texttt{KEY\_VALID} Bit must be set to start the key
expansion. This Bit can be set simultanously with \texttt{DEC} or \texttt{ENC} Bit of
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
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
\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.\\
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
Once a key is passed and marked valid data blocks can be transferred to the
Line 247... Line 248...
  \caption{Finite State Machine of encryption and decryption process}
  \caption{Finite State Machine of encryption and decryption process}
  \label{fig:aesFSM}
  \label{fig:aesFSM}
\end{figure}
\end{figure}
 
 
 
 
\subsection{Interrupt Behaviour}
\subsection{Interrupt Behavior}
\label{sec:irq}
\label{sec:irq}
By setting \texttt{IRQ\_ENA} in the control register \ref{sec:ctrl} the
By setting \texttt{IRQ\_ENA} in the control register \ref{sec:ctrl} the
component is configured to issue interrupt requests.
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
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}
computation has completed in addition to clearing the \texttt{ENC} or \texttt{DEC}
Bit.
Bit.
The \texttt{IRQ} \ref{sig:irq}  signal will remain set until clearing \texttt{IRQ\_ENA}
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.
or a read operation on the \texttt{RESULT} area of the components address range.
 
 
 
\section{The Inner Core}
\section{Ressource Usage and Throughput}
\label{sec:core}
\label{sec:ressources}
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
The Avalon\rtm\ interface communicates a 32-Bit DWORD per clock cycle. Therefore a key is transmitted in 4 to 8 cyles
share the keyexpansion component which provides decrypt and encrypt keys (which are
plus one cyle to activate keyexpansion with the control word \ref{sec:ctrl}. A payload datablock or the result consist
the same only in opposite order). Each data path is controlled by its own \FSM\.  If
always of 4 DWORDs, thus it takes 4 cyles to send data to the core, one cycle to activate the computation with the
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.
control register \ref{sec:ctrl} and 4 cycles to retrieve the data.
 
 
The keyexpansion component computes one column of a roundkey each clock cylce. AES takes, depending on the keylength,
The keyexpansion component computes one column of a roundkey each clock cycle. AES takes, depending on the key length,
10, 12 or 14 roundkeys with each 4 columns, see \cite{NIST:Fips197}. The keyexpansion therefore takes 40, 48 or 56
10, 12 or 14 roundkeys with each 4 columns, see \cite{NIST:Fips197}. The keyexpansion therefore takes 40, 48 or 56
cycles until the encryption or decryption can start. The roundkeys are stored until invalidated, see \ref{sec:usage}
cycles 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.
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 datablock 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 cylces 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 keylength which
The maximum throughput $T_{max}[Bits]$ depends on the maximum operation frequency $f_{max}$ and the keylength which
influences the number of rounds $N_{rnd} \epsilon \lbrace 10,12,14 \rbrace $.
influences the number of rounds $N_{rnd} \epsilon \lbrace 10,12,14 \rbrace $.
\begin{equation}
\begin{equation}
  T_{max}=\frac{ (1+N_{rnd}) \cdot 128 Bit}{f_{max}}
  T_{max}=\frac{ (1+N_{rnd}) \cdot 128 Bit}{f_{max}}
\label{eqn:tmax}
\label{eqn:tmax}
\end{equation}
\end{equation}
 
 
Note: Equation \ref{eqn:tmax} assumes that the roundkeys are already generated and does not include the constant of 4+1+4
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 cylces for transmission of data, activation and result retrieval.
Avalon\rtm\ bus cycles for transmission of data, activation and result retrieval.
 
\newpage
 
\section{FPGA implementations}
\subsection{Exemplary FPGA implementations}
\label{sec:fpga}
 
The component has only be implemented and tested on an Altera\rtm\ Cyclone-II EP2C35
The component has only be implemented and tested on an Altera\rtm\ CycloneII EP2C35
FPGA. For this setup a Makefile is provided in \texttt{./sys/Altera\_Quartus9.1}.  All
FPGA. For this setup a Makefile is provided in \texttt{./sys/AlteraQuartus9.1}.  All
 
other values in the table are only results of synthesis\footnotemark[0] and are not
other values in the table are only results of synthesis\footnotemark[0] and are not
verified on actual hardware.
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}
 
 
\footnotetext[0]{Synthesized with Altera\rtm\ QuartusII\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
The design is kept mostly vendor independent in generic VHDL. For Altera\rtm\ chips the
 
AES SubByte component is specially designed using M4K Blockrams as dual-port ROM. For
 
non-Altera\rtm\ FPGAs a second VHDL architecture exists also trying to make use of
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
ROM functions of the target chips however the success varies on RTL compiler
capabilities.
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}|}
\begin{tabularx}{\textwidth}{|p{30mm}|X|p{20mm}|p{30mm}|p{18mm}|}
  \hline
  \hline
  \bf{Configuration} & \bf{Target FPGA}\footnotemark[1] & \bf{LE / Slices} & \bf{HW RAM} & $\mathbf{f_{max}[Mhz]}$  \\ \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}
        \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{Xilinx\rtm\ Virtex5}   XC5VLX30-3FF324 &  - / 297 & \mbox{18 18k-Blocks}  \mbox{4 36k-Blocks} & 224 \\ \cline{2-5}
        & \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 1937 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 65 \\ \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  \\
        & \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 585 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 103  \\
        \hline
        \hline
%%%%%%
%%%%%%
        \multirow{2}{30mm}{128 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 &  - / 1523 & 18 RAMB16BWE & 91 \\ \cline{2-5}
        \multirow{2}{30mm}{128 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 &  - / 1523 & 18 RAMB16BWE & 91 \\ \cline{2-5}
                & \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 1776 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 65 \\
                & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 1776 / - &  \mbox{39912 Bits} in  \mbox{22 M4K-Blocks} & 65 \\
        \hline
        \hline
%%%%%%
%%%%%%
        \multirow{4}{30mm}{256 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A}  XC3S1400A-5FG484 &  - / 680 & 14 RAMB16BWE & 159 \\ \cline{2-5}
        \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{Xilinx\rtm\ Virtex5}   XC5VLX30-3FF324 &  - / 297 & \mbox{10 18k-Blocks}  \mbox{4 36k-Blocks} & 268 \\ \cline{2-5}
        & \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 969 / - &  \mbox{22528 Bits} in  \mbox{14 M4K} & 97 \\ \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  \\
        & \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 524 / - &  \mbox{22528 Bits} in \mbox{ 14 M4K} & 145  \\
        \hline
        \hline
%%%%%%
%%%%%%
        \multirow{2}{30mm}{128 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A}  XC3S1400A-5FG484 &  - / 594 & 14 RAMB16BWE & 159 \\ \cline{2-5}
        \multirow{2}{30mm}{128 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A}  XC3S1400A-5FG484 &  - / 594 & 14 RAMB16BWE & 159 \\ \cline{2-5}
        & \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 797 / - & \mbox{22528 Bits} in  \mbox{ 14 M4K} & 95  \\ \cline{2-5}
        & \mbox{Altera\rtm\ Cyclone-II} EP2C35F484C8 & 797 / - & \mbox{22528 Bits} in  \mbox{ 14 M4K} & 95  \\ \cline{2-5}
        \hline
        \hline
 
 
\end{tabularx}
\end{tabularx}
\footnotetext[1]{This table is not meant to be a benchmark between FPGAs of different vendors, it is only a rough
\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.
  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. }
        The FPGA families cannot  be compared easily, see also \cite{Xilinx:wp284} and \cite{Altera:01007}for further details. }
\label{tab:ressources}
\label{tab:ressources}
\captionof{table}{ressource usage on different targets and configuration}
\captionof{table}{ressource usage on different targets and configuration}
 
 
All of the above configurations in table \ref{tab:ressources} use hardware key
All configurations in table \ref{tab:ressources} use hardware key
expansion. Downloading of software generated roundkeys is not yet supported. The
expansion. Downloading of software generated roundkeys is not yet supported. The
decryption and encryption datapaths share a common keyexpansion block, mulitplexing
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 and Software Driver}
\section{Simulation}
\label{sec:simdriv}
\label{sec:simulation}
\subsection{Testbench}
\subsection{Testbench}
\label{sec:testbench}
\label{sec:testbench}
In \texttt{./bench/VHDL/} a ``selfchecking 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
all testcases and key lengths are included. The expected results were generated by
all testcases 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
AES Calculator applet, written by Lawrie Brown from ADFA, Canberra Australia \cite{LaBr05}.  The
testbench consists of a sequence of 5 test cases:
testbench consists of a sequence of 5 test cases:
Line 355... Line 371...
\item key1, data1, encrypt: (test if internal state was changed)
\item key1, data1, encrypt: (test if internal state was changed)
\item key1, data2, encrypt: (encryption test with new data)
\item key1, data2, encrypt: (encryption test with new data)
\item key2, data2, encrypt: (encryption test with new key)
\item key2, data2, encrypt: (encryption test with new key)
\end{enumerate}
\end{enumerate}
 
 
\subsubsection{Simulation}
\subsection{Simulation}
\label{sec:simulation}
\label{sec:simulation}
The component library is ``\texttt{avs\_aes\_lib}''. All files are expected to be
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
compiled into this library as all files depend at least on the package
\texttt{avs\_aes\_lib.avs\_aes\_pkg}. \\
\texttt{avs\_aes\_lib.avs\_aes\_pkg}. \\
A Makefile for Mentor Graphics\rtm\ Modelsim\rtm\ is given in \texttt{./sim/}. The
A Makefile for Mentor Graphics\rtm\ Modelsim\rtm\ is given in \texttt{./sim/}. The
default make target \texttt{simaes} will create the library
default make target \texttt{simaes} will create the library
``\texttt{avs\_aes\_lib}'' and a ``\texttt{work}'' library, compile all files and run
``\texttt{avs\_aes\_lib}'' and a ``\texttt{work}'' library, compile all files and run
a testbench. \\
a testbench. \\
 
 
\subsection{Software Driver}
\section{Software Driver}
\label{sec:software}
\label{sec:software}
This AES Core Avalon\rtm\ slave was also tested on a NiosII\rtm\ processor.  To use
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
it in software a simple driver is provided in \texttt{./sw/} among with an example
program of the basic usage. Find more detailed description in the doxygen documentation in \texttt{./doc/sw/html}\\
program of the basic usage.
The driver consits of the two files \texttt{avs\_aes.c} and \texttt{avs\_aes.h}.
The driver consist of the two files \texttt{avs\_aes.c} and \texttt{avs\_aes.h}.
\subsubsection{Configuration}
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}:
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|}
 \begin{tabularx}{\textwidth}{|p{25mm}|p{25mm} |X|}
  \hline
  \hline
  \bf{define}     &  \bf{default} & \bf{Description}\\ \hline
  \bf{define}     &  \bf{default} & \bf{Description}\\ \hline
  \texttt{KEYWORDS} & \texttt{8}  & Key size in 32 Bit words \\
  \texttt{KEYWORDS} & \texttt{8}  & Key size in 32 Bit words \\
\hline
\hline
  \texttt{AES\_BASEADDR} & \texttt{0x40000} & Base address at which the AES Core is mapped to the Avalon\rtm\ switchfabric \\
  \texttt{AES\_BASEADDR} & \texttt{0x40000} & Base address at which the AES Core is mapped to the Avalon\rtm\ switch-fabric \\
\hline
\hline
\end{tabularx}
\end{tabularx}
\label{tab:macros}
\label{tab:macros}
\captionof{table}{user changeable macros in header}
\captionof{table}{user changeable macros in header}
 
 
\subsubsection{Compilation}
 
Yes indeed very difficult to compile two files and one header.....  try this one:\\
 
\texttt{GCCNIOS -I. -o test aes\_tester.c avs\_aes.c}
 
 
 
Of course you need a cross compiler, or just use the Nios2 IDE.
 
 
 
 
 
 
 
\section{The Inner Core}
 
\label{sec:core}
 
The algorithmic core is devided into two seperate datapaths one for encryption and a
 
second for decryption operation. The two datapaths are independent, however they
 
share the keyexpansion component which provides decrypt and encrypt keys (which are
 
the same only in opposite order). Each datapath is controlled by its own \FSM\.  If
 
configured by the generic \texttt{DECRYPTION} \ref{gen:decryption} the decryption
 
datapath 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 datapath is left for the reader or any other author
 
of this document.
 
\begin{figure}[!ht]
 
  \centering
 
  \includegraphics[width=0.9\textwidth]{CoreEncDP}
 
  \caption{Encrypt datapath of the AES core as implemented in aes\_core.vhd}
 
  \label{fig:aescore}
 
\end{figure}
 
 
 
 
 
\newpage
\newpage
\section{License and Liability}
\section{License and Liability}
\label{sec:license}
\label{sec:license}
The ``AES 128/192/256 (ECB) Avalon\rtm-MM Slave'' component, all its subcomponents
The ``AES 128/192/256 (ECB) Avalon\rtm-MM Slave'' component, all its subcomponents
Line 453... Line 444...
 compiled netlists for actual target hardware. As Chips generally don't just
 compiled netlists for actual target hardware. As Chips generally don't just
 reproduce ``the above copyright notice, this list of conditions and the following
 reproduce ``the above copyright notice, this list of conditions and the following
 disclaimer in the documentation and/or other materials provided with the
 disclaimer in the documentation and/or other materials provided with the
 distribution'' the datasheet of the product must also contain it.\\
 distribution'' the datasheet of the product must also contain it.\\
 
 
 Altera, CycloneII, StratixII and Avalon are registered trademarks of the Altera
 Altera, Cyclone-II, Stratix-II, Quartus, NIOS and Avalon are registered trademarks of the Altera
 Corporation
 Corporation
 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

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.