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

Subversion Repositories avs_aes

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /avs_aes
    from Rev 15 to Rev 16
    ↔ Reverse comparison
  •

Rev 15 → Rev 16

/trunk/doc/manual/src/avs_aes.bbl File deleted
/trunk/doc/manual/src/avs_aes.blg File deleted
/trunk/doc/manual/src/avs_aes.ilg File deleted
/trunk/doc/manual/src/avs_aes.glo File deleted
/trunk/doc/manual/src/avs_aes.toc File deleted
/trunk/doc/manual/src/avs_aes.gls File deleted
/trunk/doc/manual/src/avs_aes.ist
1,4 → 1,4
% makeindex style file created by LaTeX for document "avs_aes" on 2010-4-2
% makeindex style file created by LaTeX for document "avs_aes" on 2010-4-3
keyword "\\glossaryentry"
preamble "\\begin{theglossary}"
postamble "\n\\end{theglossary}\n"
/trunk/doc/manual/src/avs_aes.tex
49,6 → 49,7
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 \\
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
60,13 → 61,13
\newpage
 
\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
Daemen and Vincent Rijmen. The algorithm was standardized by \NIST. For more
information on the algorithm see \cite{NIST:Fips197}.\\
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
time. Also the decryption datapath can be disabled by generics if it is not needed
This component implements an AES encryption decryption data path in \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
82,8 → 83,8
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 selfcontained entity and can be embedded into other \SoC\ bus
interfaces as well or used indepentently.
core however is a self contained entity and can be embedded into other \SoC\ bus
interfaces as well or used independently.
 
\subsection{Configuration Generics}
\label{sec:generics}
93,8 → 94,8
\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 userkey. Must be 128, 192 or 256 \footnotemark[1] . \\ \hline
\texttt{DECRYPTION} \label{gen:decryption} & BOOLEAN & Enables the instantiation of the decrypt datapath if true. \\
\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}
123,7 → 124,7
\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 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
\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
134,11 → 135,11
\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 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}
\\ \hline
\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}
\captionof{table}{Avalon\rtm\ Bus interface signals}
 
145,13 → 146,13
 
\section{Memory Map}
\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
space is devided 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
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
descibed in table \ref{tab:memmap}.\\
described in table \ref{tab:memmap}.\\
 
\begin{tabularx}{\textwidth}{|p{18mm}|p{14mm} |X|}
\hline
176,8 → 177,8
\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 wrriting to the register reserved Bits shall be assigned a value of \texttt{0}.
Individual Bits have following functionality decribed in table \ref{tab:ctrlreg}. \\
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.
 
185,9 → 186,9
\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 roundkeys.
\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 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
completing an operation. If not set the component operates in polling mode only.\\ \hline
\texttt{5-2} & --- &reserved \\ \hline
198,7 → 199,7
\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 simultanously.}
\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}
 
209,10 → 210,10
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 userkey has to be written to
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 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
\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.\\
231,15 → 232,15
The underlying AES core uses the \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 keygenerator 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
roundkey. \\
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 keylength the processing of a datablock needs at maximum 15
clockcycles from \texttt{data\_stable=1} to completion, if the key is already expanded.
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
249,7 → 250,7
\end{figure}
 
 
\subsection{Interrupt Behaviour}
\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.
259,24 → 260,42
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{Ressource Usage and Throughput}
\label{sec:ressources}
 
The Avalon\rtm\ interface communicates a 32-Bit DWORD per clock cycle. Therefore a key is transmitted in 4 to 8 cyles
plus one cyle to activate keyexpansion with the control word \ref{sec:ctrl}. A payload datablock or the result consist
always of 4 DWORDs, thus it takes 4 cyles to send data to the core, one cycle to activate the computation with the
\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 \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 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
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.
 
The AES-core computes one iteration (round) of the Rijndael-Algorithm each clock cycle, thus a 128 Bit datablock is
encrypted or decrypted in 10, 12 or 14 cylces plus an initial round.
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 keylength which
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}}
284,24 → 303,22
\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 cylces for transmission of data, activation and result retrieval.
 
 
\subsection{Exemplary FPGA implementations}
 
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/AlteraQuartus9.1}. All
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}
 
\footnotetext[0]{Synthesized with Altera\rtm\ QuartusII\rtm\ Web edition Version 9.1 or Xilinx\rtm\ ISE 9.1 Webpack}
 
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
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.
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
308,24 → 325,23
\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\ 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 \\
\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\ 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
%%%%%%
\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\ 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 \\
\hline
%%%%%%
\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
 
\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.
333,20 → 349,20
\label{tab:ressources}
\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
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
frequency $f_{max}$ of the configuration compared to encryption only versions.
 
\section{Simulation and Software Driver}
\label{sec:simdriv}
\section{Simulation}
\label{sec:simulation}
\subsection{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
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 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}
357,7 → 373,7
\item key2, data2, encrypt: (encryption test with new key)
\end{enumerate}
 
\subsubsection{Simulation}
\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
367,13 → 383,15
``\texttt{avs\_aes\_lib}'' and a ``\texttt{work}'' library, compile all files and run
a testbench. \\
 
\subsection{Software Driver}
\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. Find more detailed description in the doxygen documentation in \texttt{./doc/sw/html}\\
The driver consits of the two files \texttt{avs\_aes.c} and \texttt{avs\_aes.h}.
\subsubsection{Configuration}
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
380,40 → 398,13
\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\ switchfabric \\
\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}
 
\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
\section{License and Liability}
\label{sec:license}
453,9 → 444,9
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 datasheet of the product must also contain it.\\
distribution'' the data sheet 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
101 Innovation Drive, San Jose CA USA \\
Xilinx, Spartan3A and Virtex5 are registered trademarks of Xilinx Inc. 2100 Logic Drive, San Jose CA USA \\
/trunk/doc/manual/src/avs_aes.acn
10,7 → 10,7
 
\gloitem {\glosslabel{acn:FSM}{Finite State Machine\ (\noexpand \acronymfont {FSM})}}Behavioural Model with finite number of states and transitions\relax
\glodelim
\glsnumformat{6}\delimN \glsnumformat{11}\delimT \gloskip \glogroupL
\glsnumformat{6}\delimN \glsnumformat{8}\delimT \gloskip \glogroupL
 
\gloitem {\glosslabel{acn:LSB}{Least Significant Bit\ (\noexpand \acronymfont {LSB})}}least value bit in a vector\relax
\glodelim
/trunk/doc/manual/src/avs_aes.acr
5,4 → 5,4
\glossaryentry{MSB@{\glosslabel{acn:MSB}{Most Significant Bit\ (\noexpand \acronymfont {MSB})}}highest value bit in a vector\relax|glsnumformat}{4}
\glossaryentry{LSB@{\glosslabel{acn:LSB}{Least Significant Bit\ (\noexpand \acronymfont {LSB})}}least value bit in a vector\relax|glsnumformat}{4}
\glossaryentry{FSM@{\glosslabel{acn:FSM}{Finite State Machine\ (\noexpand \acronymfont {FSM})}}Behavioural Model with finite number of states and transitions\relax|glsnumformat}{6}
\glossaryentry{FSM@{\glosslabel{acn:FSM}{Finite State Machine\ (\noexpand \acronymfont {FSM})}}Behavioural Model with finite number of states and transitions\relax|glsnumformat}{11}
\glossaryentry{FSM@{\glosslabel{acn:FSM}{Finite State Machine\ (\noexpand \acronymfont {FSM})}}Behavioural Model with finite number of states and transitions\relax|glsnumformat}{8}

powered by: WebSVN 2.1.0

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