%%This is a very basic article template.
%%There is just one section and two subsections.
\documentclass[a4paper,11pt]{article}
\usepackage[pdfborder= 0 0 0 1]{hyperref}
\usepackage{graphicx}
\usepackage{hyperref}

\usepackage{draftwatermark}
\SetWatermarkLightness{0.85}
\SetWatermarkScale{5}

\begin{document}

\title{\textbf{CONV-TTL-BLO \\ User Guide}}
\author{Carlos Gil Soriano\\BE-CO-HT\\
\href{mailto:carlos.gil.soriano@cern.ch}{\textbf{\textit{carlos.gil.soriano@cern.ch}}}}
\date{\today}
\maketitle

\begin{abstract}
This \textit{User's Guide} covers the following topics:
\begin{itemize}
  \item HDL global structure. 
  \item Golden image memory mapping.
  \item Register mapping of all the HDL cores.
  \item Instructions for accesing to the functionalities.
\end{itemize}
\end{abstract}

\pagebreak
\tableofcontents

\pagebreak
\section{HDL global structure}
The following schema is used as a reference for the HDL development:\\
\begin{figure}[htb]
    \begin{center}
      \includegraphics[scale=0.3, keepaspectratio]{Figures/HDLspecs.png}
            \caption{CONV-TTL-BLO HDL structure}
    \end{center}
\end{figure}

\subsection{Control}
It is the part that bridges the I2C frames to the correct wishbone module. The
tasks it is responsible of are: 
\begin{itemize}
  \item Correctly power-up the rest of the modules.
  \item Provide connectivity of all the wishbone registers via
  I2C. It manages control access to the registers.
\end{itemize}
\subsection{I2C slave}
An I2C slave is needed to receive the frames from the VME64x SERA and SERB pins
in P1 connector. This module will communicates with \textit{control hdl module}
in the following fashion:
\begin{itemize}
  \item It connects as a wishbone \textbf{slave} to control hdl core and
  provides interrupt lines for data reception and transmission.
\end{itemize}
The main reason of implementing a wishbone slave is that by dividing data
reception -\textit{i2c slave}- from control access -\textit{control}- the
development is more reliable and clear.\\ This module offers configuration
registers to ease the task of data assembly --for instance, the communication
schema in ELMA crate.
\subsection{Trigger}
The trigger manages the pulse repetition. The parameters handled that affect the
pulse repetition are:
\begin{itemize}
  \item \textbf{Debouncing} stages of the input pulse.
  \item \textbf{Pulse length} of the output pulse according to Standard
  Blocking definition.
  \item \textbf{Minimun spacing between pulses} to let the magnetizing current 
  of the transformer be drained off. It is also refered in other documents as
  \textit{Inactivity timeout upon output pulse is outputted}.
\end{itemize}
The pulses must be time-tagged. It can be achieved either by a
lossy time-tagging via i2c, or with a precise one via White Rabbit. Every
time-tag has appended event identifiers (metadata).
\subsubsection{Time-tagging Format}
The format of the time-tags should be defined. At this moment, an implementation
with 96 bits for timestamping with 32 bits of metadata is the default. A record
of the last 256 time-tags per channel is hold in the FPGA.
\subsection{Multiboot manager}
  The task of the \textit{Multiboot manager} is to manage a golden bitstream
  and another one to update the FPGA from. From within this module a FPGA
  reprogramming command is issued.
\subsection{EEPROM manager}
The module responsible to write into the EEPROM, read it back and reprogramming
the memory module. It should be targeted to interface directly with a MICRON
M25P32-VMF6P memory. It will be able to write the MAC address that will be used
by White Rabbit and block memory parts of the EEPROM.

\subsection{White Rabbit core}
Provides precise timestamping.
\pagebreak

\section{Golden image memory mapping}
To access the devices thanks to \textit{control module} the
following memory map applies:
\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline
&& \textbf{FIRST} & \textbf{LAST}\\
\textbf{NUMBER}&\textbf{DEVICE} & \textbf{WISHBONE} & \textbf{WISHBONE}\\  
&& \textbf{ADDRESS}  & \textbf{ADDRESS}\\
\hline
\hline
0 & \hyperref[sec:control]{Control} & 0x0100 & 0x01FF \\
\hline
1 & \hyperref[sec:I2C]{I2C slave} & 0x0200 &  0x02FF \\
\hline
2 & \hyperref[sec:trigger]{Trigger 1} & 0x0300 & 0x03FF \\
\hline
3 & \hyperref[sec:trigger]{Trigger 2} & 0x0400 & 0x04FF \\
\hline
4 & \hyperref[sec:trigger]{Trigger 3} & 0x0500 & 0x05FF \\
\hline
5 & \hyperref[sec:trigger]{Trigger 4} & 0x0600 & 0x06FF \\
\hline
6 & \hyperref[sec:trigger]{Trigger 5} & 0x0700 & 0x07FF \\
\hline
7 & \hyperref[sec:trigger]{Trigger 6} & 0x0800 & 0x08FF \\
\hline
8 & \hyperref[sec:multiboot]{Multiboot manager} & 0x0900 & 0x09FF \\
\hline
9 & \hyperref[sec:EEPROM]{EEPROM manager} & 0x0A00 & 0x0AFF \\
\hline
10 & White Rabbit core & 0x0B00 & 0x0BFF \\
\hline
\hline
11 & EEPROM memory & 0x1000 &  0x1FFF \\
\hline
\end{tabular}
\end{center}

\pagebreak

\section{Control module}
\label{sec:control}

\pagebreak

\section{I2C slave module}
\label{sec:I2C}

\subsection{Structure}
The i2c module contains several blocks related the following way:\\

--  i2c\_slave\_top.vhd 

----- i2c\_regs.vhd

----- i2c\_slave\_core.vhd

--------- FIFO\_dispatcher.vhd

--------- FIFO\_stack.vhd

--------- gc\_counter.vhd

--------- gc\_ff.vhd

--------- i2c\_bit.vhd


\subsection{Interrupting lines offered}

\subsubsection{ind\_wb\_addr}
This interrupting signal issues when a \textit{indirect wishbone address} has
been received. It is notified right after the first CTR0[BIA] + 1 bytes upon the
reception of the I2C byte address packet.
This signal is vital for correctly prefetching when a I2C read operation is
requested.

\subsubsection{inst\_rd}
This signal is issued when a read operation directed by an external master over
the HDL slave core is finished. That means it will be generated after the last
data byte has been sent by the HDL core.

\subsubsection{inst\_wr}
This signal is issued when a write operation directed by an external master over
the HDL slave core is finished. That means it will be generated after the last
data byte has been received.

\subsection{Registers}

\subsubsection{STA}
The STA register is a read-only register. It control the general enable and
reset of the module. It also contains the current value of the finite state
machine of the i2c modue (useful for easy debugging).\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
0 & EN & General ENable\\
\hline
1 & RST & General ReSeT\\
\hline
2 & RD\_WRN\_INST & Reserved\\
\hline
3 & A\_RX &\\
\hline
4 & A\_TX &\\
\hline
8-5 & x & Reserved\\
\hline
15-9 & i2c\_sla\_fsm & i2c fsm\\
\hline
31-16 & Not used\\
\hline
\end{tabular}

\subsubsection{PRE}
The PRE register is a write-read register. Right now it is not used.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
15-0 & PRE & PREscaler value\\
\hline
31-16 & - & Not used\\
\hline
\end{tabular}


\subsubsection{CTR0}
The CTR0 register is a write-read register. It controls the indirect addres
and holds the I2C address (which in the case of \textit{CONV-TTL-BLO} will be
connected to VME64x geographical address pins).\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
0 & EN & general ENable\\
\hline
1 & RST & general ReSeT\\
\hline
2 & PEN & Prescaler ENable\\
\hline
5-3 & x & Reserved\\
\hline
7-6 & BIA & Bytes Indirect Addressing\\
\hline
14-8 & A[6:0] & I2C address\\
\hline
15 & x & Reserved\\
\hline
31-16 & - & Not used\\
\hline
\end{tabular}

\subsubsection{CTR1}
The CTR1 register is a write-read register. It shows the fsm of the separate
\textit{read} and \textit{write} fsms.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
7-0 & RDS & fsm status: ReaD Status\\
\hline
15-8 & WDS & fsm status: WRite Status\\
\hline
31-16 & - & Not used\\
\hline
\end{tabular}

\subsubsection{DRXA}
The DRXA register is a read-only register. It holds the last four received
bytes through the I2C. DRX0 has the most recent byte received from the serial
interface. DRX3 has the oldest byte received.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
7-0 & DRX0 & Data RX register 0\\
\hline
15-8 & DRX1 & Data RX register 1\\
\hline
23-16 & DRX2 & Data RX register 2\\
\hline
31-24 & DRX3 & Data RX register 3\\
\hline
\end{tabular}

\subsubsection{DRXB}
The DRXB register is a read-only register. It holds the fifth and sixth latest
received bytes, respectively.
\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
7-0 & DRX4 & Data RX register 0\\
\hline
15-8 & DRX5 & Data RX register 1\\
\hline
31-16 & - & Not used\\
\hline
\end{tabular}


\subsubsection{DTX}
The DTX register is a write-read register. It shows the fsm of the separate
\textit{read} and \textit{write} fsms.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
7-0 & RDS & fsm status: ReaD Status\\
\hline
15-8 & WDS & fsm status: WRite Status\\
\hline
31-16 & - & Not used\\
\hline
\end{tabular}

\subsection{Internal Memory Mapping}
The internal registers map is as follow:\\

\begin{tabular}{| c | c | c |}
\hline
\textbf{Address} & \textbf{Register} & \textbf{Access} \\
\hline
\hline
\textbf{0x0} & \textit{STA} & Read-only\\
\hline
\textbf{0x1} & \textit{PRE} & Write-read\\
\hline
\textbf{0x2} & \textit{CTR0} & Write-read\\
\hline
\textbf{0x3} & \textit{CTR1} & Write-read\\
\hline
\textbf{0x4} & \textit{DRXA} & Read-only\\
\hline
\textbf{0x5} & \textit{DRXB} & Read-only\\
\hline
\textbf{0x6} & \textit{DTX} & Write-read\\
\hline
\end{tabular} 

\subsection{How to use it}
\subsubsection{Initialization}

\begin{enumerate}
\item Perform a reset of the module while module is not enabled:\\
\textit{CTR0: write 0 to EN and 1 to RST.} 
\item Load the prescaler:\\
\textit{PRE: set a new value.}
\item  Set the I2C address of the slave module:\\
\textit{CTR0[A]: set the I2C address.}
\item  Set the rest of bits of CTR0, including EN:\\
\textit{CTR0: set rest of bits.}
\end{enumerate}

\subsubsection{Indirect Write from Master to Slave}

It is a one-phase transaction: one indirect writing is achieved
by signaling only one I2C start condition by the master.

\begin{enumerate}
  \item The Master I2C device starts an I2C transaction. In the first byte it
specifies the type of transaction issued as a write.
  \item Then, two bytes are received in the slave. At the end of the reception
  of the last bit of this second byte (third since the I2C start condition), the
  finite state machine in \textit{i2c\_slave\_core.vhd} launches the interrupt
  \textit{inst\_wb\_addr}.
 
  \textbf{Address prefetching}: at this point, the Wishbone Address can be
  stored.
  It is found in \textit{DRX0} and \textit{DRX1} registers:
  
  \begin{itemize}
    \item \textit{DRX0}: holds the Wishbone Address Lowest Byte
    \item \textit{DRX1}: holds the Wishbone Address Highest Byte
  \end{itemize}
  
  \item Following the reception of the two bytes corresponding to the Wishbone
  Address, four more bytes will be received. They are the data bytes. Once the
  last bit of this fourth byte is received (seventh byte since the I2C start
  condition), the finite state machine in \textit{i2c\_slave\_core.vhd} launches
  the interrupt \textit{inst\_wr}.
  
  \textbf{Address and Data fetching}: at this point, the \textit{Wishbone
  Address} and the \textit{Data} to be written in that address can be both
  fetched through the \textit{DRX} registers:
  
  \begin{itemize}
    \item \textit{DRX0}: holds the Data Lowest Byte
    \item \textit{DRX1}: holds the Data 2$^{nd}$ Lowest Byte
    \item \textit{DRX2}: holds the Data 2$^{nd}$ Highest Byte
    \item \textit{DRX3}: holds the Data Highest Byte
    \item \textit{DRX4}: holds the Wishbone Address Lowest Byte
    \item \textit{DRX5}: holds the Wishbone Address Highest Byte
  \end{itemize}
  
  \item The Master I2C device stops the I2C transaction. 
\end{enumerate}

\subsubsection{Indirect Read from Master to Slave}

It is a two-phases transaction: one indirect read is achieved
by signaling only two I2C start conditions by the master.\\

\textbf{FIRST PHASE}

\begin{enumerate}
  \item The Master I2C device starts an I2C transaction. In the first byte it
specifies the type of transaction issued as a write.
  \item Then, two bytes are received in the slave. At the end of the reception
  of the last bit of this second byte (third since the I2C start condition), the
  finite state machine in \textit{i2c\_slave\_core.vhd} launches the interrupt
  \textit{inst\_wb\_addr}.
 
  \textbf{Address Prefetching}: at this point, the Wishbone Address can be
  stored.
  It is found in \textit{DRX0} and \textit{DRX1} registers:
  
  \begin{itemize}
    \item \textit{DRX0}: holds the Wishbone Address Lowest Byte
    \item \textit{DRX1}: holds the Wishbone Address Highest Byte
  \end{itemize}
  
    \textbf{Data Prefetching}: it is a good practice to do the \textit{data
  prefetching} of the Wishbone Address (in case this is accessible). The control
  logic attached to the \textit{i2c\_slave\_wb} module should perform a
  wishbone write to the four \textit{DTX[X]} registers:
  
  \begin{itemize}
    \item \textit{DTX0}: holds the Data Lowest Byte
    \item \textit{DTX1}: holds the Data 2$^{nd}$ Lowest Byte
    \item \textit{DTX2}: holds the Data 2$^{nd}$ Highest Byte
    \item \textit{DTX3}: holds the Data Highest Byte
  \end{itemize}
  
  so that the data in the transmission registers is up-to-date, in order to be
  sent through I2C.
  
\end{enumerate}\\
\pagebreak
\textbf{SECOND PHASE}

\begin{enumerate}
  

  \item The Master I2C device (re)starts an I2C transaction. In the first byte
  it specifies the type of transaction issued as a read. At the end of the
  reception of the last bit on the first byte of this \textit{second phase}
  (third byte sinc the I2C start condition from the \textit{first phase}), the
  finite state machine in \textit{i2c\_slave\_core.vhd} launches the interrupt
  \textit{inst\_wb\_addr}.
  
  \item The \textit{i2c\_slave\_wb} module sends the four data bytes in the
  following order:
  
    \begin{enumerate}
    \item Data Lowest Byte
    \item Data 2$^{nd}$ Lowest Byte
    \item Data 2$^{nd}$ Highest Byte
    \item Data Highest Byte
  \end{enumerate}
  
  \item Once the last byte has been already send,  the finite state machine in
  \textit{i2c\_slave\_core.vhd} launches the interrupt \textit{inst\_rd\_addr}.
\end{enumerate}

\pagebreak

\section{Trigger module}
\label{sec:trigger}
\subsection{Structure}

The trigger module contains several blocks related the following way:\\

--  \textbf{\textit{trigger\_top.vhd}} 

----- \textbf{trigger\_regs.vhd}

----- \textbf{trigger\_core.vhd}

--------- debouncer.vhd

--------- monostable.vhd

----- \textbf{TT\_RAMhandler.vhd}

--------- gc\_RAM.vhd (for IDs)

--------- gc\_RAM.vhd (for TTs)

\subsubsection{\textit{trigger\_top.vhd}}

The top module interconnects the three basic building blocks: registers, core
and generic RAM. Each \textit{trigger\_top.vhd} module will control
one output Blocking driver.

Inside \textit{trigger\_top.vhd} there are some constant that are used as
\textit{generic} in both the registers and generic RAMs. The constants are
explained later in the section 'Parameters' and are the following:
\begin{itemize}
  \item \textit{c\_RAM\_SIZE }
  \item \textit{c\_MAX\_GLITCH\_STAGES }
  \item \textit{c\_DEFAULT\_GLITCH\_MASK }
  \item \textit{c\_MIN\_PULSE\_LENGTH }
  \item \textit{c\_MAX\_PULSE\_LENGTH }
  \item \textit{c\_DEFAULT\_PULSE\_LENGTH }
  \item \textit{c\_TAGS\_DATA\_WIDTH } 
\end{itemize}

\subsubsection{trigger\_regs.vhd}\\

It consist of a core that can be accessed via Wishbone and that contains all the
registers which control this trigger core. The minimum and maximum values and
proceeding for configuring them will be explained in the two next following
sections.

\subsubsection{TT\_RAMhandler.vhd}\\

The TT\_RAMhandler is the component that control reads and writes into the RAM
space used for time-tagging pulses. It is subdivided into two separated blocks
of RAM: one for identification of the input and output pulse shape (so called
''ID Block'') and the other one for time-tagging (''TT Block'').

The idea behind seperating the block memories lies in ease the task of updating
the code in case different widths for the ID and TT fields are decided.
\item[]



\subsection{Behaviour}

Once a pulse has been deglitched, which translates into a delay of
\textit{wb\_clk * cycles to match c\_DEFAULT\_GLITCH\_MASK }, a monostable
will reproduce a pulse with a length determined by the CPL field in CTR0
register. The duration of the output pulse will be hence, \textit{CTR0[CPL] *
wb\_clk}. After this time, a preventive action has been taken to not damage the
coupled inductors in \textbf{CONV-TTL-BLO}. A timeout will be run in which no
input pulse will be replicated. The value of this timeout corresponds to
\textit{CTR0[CPL] * wb\_clk}, which is the same as the outputted pulse.

\begin{description}
\item[Min. Deglitch Mask delay] \textit{wb\_clk * 1}
\item[Max. Deglitch Mask delay] \textit{wb\_clk * bits of
c\_DEFAULT\_GLITCH\_MASK }
\item[Min. input pulse length] \textit{c\_DEFAULT\_GLITCH\_MASK * wb\_clk}
\item[Output pulse length] \textit{CTR0[CPL] * wb\_clk}
\item[Inactivity timeout upon output pulse is done] \textit{CTR0[CPL] * wb\_clk}
\end{description}

\subsection{Parameters}


\subsubsection{ \textit{g\_MAX\_GLITCH\_STAGES} }

It specifies the maximum stages used for debouncing an input signal. The input
signal is validated by bit 0 in CTR0. If CRT0[0] is set to 0. Inputs won't be
replicated (it won't even be deglitched).

The value of this parameters express the length in bits of the parameter that
holds the deglitching mask. The value of the Current deGlitching Mask can be
found in CGM in CTR0 register.

\subsubsection{ \textit{g\_DEFAULT\_GLITCH\_MASK} }

It specifies the default value that it is used for the Current deGlitching Mask
for the CGM field in CTR0 register. Only the lower CGM bits specified by the
values of \textit{g\_MAX\_GLITCH\_STAGES} will be used as deglitching mask. It
should be remarked that the input will be validated against a mask, so values
not monotonical can be accepted. Examples are shown at the end of this document.

\subsubsection{ \textit{g\_MIN\_PULSE\_LENGTH} }

It specifies the default value that it is used for the Minimum Pulse Length
for the MinPL field in CTR1 register.

This field overrides the value of CPL in CTR0 in case the user tries to
configure an output pulse with a width lower than MinPL. Therefore CTR0 will be
MinPL.\\

\textbf {\textit {BOUNDING MUST BE IMPLEMENTED}}


\subsubsection{ \textit{g\_MAX\_PULSE\_LENGTH} }

It specifies the default value that it is used for the Maximum Pulse Length
for the MaxPL field in CTR1 register.

This field overrides the value of CPL in CTR0 in case the user tries to
configure an output pulse with a width longer than MaxPL. Therefore CTR0 will be
MaxPL.\\

\textbf {\textit {BOUNDING MUST BE IMPLEMENTED}}

\subsection{ \textit{g\_DEFAULT\_PULSE\_LENGTH} }

It specifies the default value that it is used for the Current Pulse Length
for the CPL field in CTR0 register.

It should be noted that its value is bounded by MinPL and MaxPL fields of CTR1
register.\\

\textbf {\textit {BOUNDING MUST BE IMPLEMENTED}}

\subsection{Registers}

\subsubsection{STATUS}
The STATUS register is a read-only register. It shows the basic configuration of
the trigger HDL core and the status of the trigger core RAM blocks.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
 0 & EN & General ENable\\
 \hline
 1 & CLR & General CLeaR\\
 \hline
 3-2 & x & Reserved\\
 \hline
 4 & EN\_TT & Enable Time-Tagging\\
 \hline
 5 & CLR\_TT & CLeaR Time-Tagging\\
 \hline
 7-6 & x & Reserved\\
 \hline
 8 & EMPTY & RAM empty flag\\
 \hline
 9 & FULL & RAM full flag\\
 \hline
 10 & WA & RAM wrapped around\\
 \hline
 15-11 & x & Reserved\\
 \hline
 31-16 & CPL & Current Pulse Length\\
\hline
\end{tabular}

\subsubsection{CTR0}
The CTR0 register is a read-write register. It allows setting up the basic
configuration of the trigger HDL core, its RAM blocks and both the deglitching
mask and output pulse length to be used.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
0 & EN & General ENable\\
\hline
1 & CLR & General CLeaR\\
\hline
3-2 & x & Reserved\\
\hline
4 & EN\_TT & Enable Time-Tagging\\
\hline
5 & CLR\_TT & Clear Time-Tagging\\
\hline
7-6 & RDM & time-tagging ReaD Mode\\
\hline
15-8 & CGM & Current Glitch Mask\\
\hline
31-16 & CPL & Current Pulse Length\\
\hline
\end{tabular}

\subsubsection{CTR1}
The CTR1 register is a read-write register. It allows setting up the boundaries
that override invalid values of CPL field in CTR0.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
15-0 & MinPL & Minimum Pulse Length\\
\hline
31-16 & MaxPL & Maximum Pulse Length\\
\hline
\end{tabular}

\subsubsection{RAM0}
The RAM0 register is a read-write register. It allows setting up the RAM
and the read request to it.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
0 & EN\_TT & Enable Time-Tagging \\
\hline
1 & CLR\_TT & Clear Time-Tagging \\
\hline
3-2 & RDM & time-tagging ReaD mode\\
\hline
4 & EMPTY & RAM empty\\
\hline
5 & FULL & RAM full\\
\hline
6 & WA & RAM Wrapped Around\\
\hline
7 & RQT & ReQuesT read\\
\hline
31-8 & x & Reserved\\ 
\hline
\end{tabular}

\subsubsection{RAM1}
The RAM1 register is a read-only register. It shows the current read and write
address configured to be accessed.\\

\begin{tabular}{| l | c | c |}
\hline
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
15-0 & CRA & Current Read Address\\
\hline
31-16& CWA & Current Write Address\\
\hline
\end{tabular}

\subsubsection{RAM2}
The RAM2 register is a read-write register. It allows setting up the RAM adress
range to be read.\\

\begin{tabular}{| l | c | c |}
\hline
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
15-0 & SA & Starting read Address\\
\hline
31-16 & EA & Ending read Address\\
\hline
\end{tabular}

\pagebreak

\subsection{Internal Memory Mapping}
The internal registers map is as follow:\\

\begin{tabular}{| c | c | c |}
\hline
\textbf{Address} & \textbf{Register} & \textbf{Access} \\
\hline
\hline
\textbf{0x0} & \textit{STATUS} & Read-only\\
\hline
\textbf{0x1} & \textit{CTR0} & Read-write\\
\hline
\textbf{0x2} & \textit{CTR1} & Read-write\\
\hline
\textbf{0x3} & \multicolumn{2}{l|}{Not used}\\
\hline
\textbf{0x4} & \multicolumn{2}{l|}{Not used}\\
\hline
\textbf{0x5} & \textit{RAM0} & Read-write\\
\hline
\textbf{0x6} & \textit{RAM1} & Read-only\\
\hline
\textbf{0x7} & \textit{RAM2} & Read-write\\
\hline
\end{tabular} 


\subsection{How to use it}
\subsubsection{Initialization}

\begin{enumerate}
  \item Disable trigger core before configuring:
  
\textit{CTR0: write 0 to EN and EN\_TT}\\

  \item Set the minimum and maximum pulse lengths:

\textit{CTR1: writes into MinPL and MaxPL}\\

  \item Set the deglitching mask and pulse length to be used:
  
\textit{CTR0: set CGM and CPL}\\

\item Clearing RAM block up before starting:

\textit{RAM0: write 1 to CLR\_TT}\\

\item Disable RAM clearup and enable module:

\textit{CTR0: write 1 to EN and EN\_TT, write 0 to CLR\_TT}\\
 
\end{enumerate}

\subsubsection{Changing the deglitch mask and stages length}

Three examples are given.\\

\begin {enumerate}
\item[\textbf{Example A}]\\
\begin{itemize}
  \item \textbf{ \textit{g\_MAX\_GLITCH\_STAGES} }: 6
  \item \textbf{ CTR0[CGM] }: 0x0BAA  
\end{itemize}
In this case, only the six less significant bits of CGM field will be used as
mask: ''11 1010''. This mask signal is checked against the sampled input signal.
If it matches, it is considered as a pulse and it will be replicated.\\


\item[\textbf{Example B}]\
The common use will be in the form:
\begin{itemize}
\item \textbf{ \textit{g\_MAX\_GLITCH\_STAGES} }: 6
\item \textbf{ CTR0[CGM] }: 0xFFFF
\end{itemize}

Which translates into \textit{pulses of length \textbf{6 * wb\_clk } or greater should
be replicated}.\\

\item[\textbf{Example C}]\
Reducing the Deglitch Mask delay is achieved by configuring CGM
properly:
\begin{itemize}
\item \textbf{ \textit{g\_MAX\_GLITCH\_STAGES} }: 6
\item \textbf{ CTR0[CGM] }: 0x0007
\end{itemize}

which means \textit{pulses of length \textbf{3 * wb\_clk} or greater should be
replicated}.
\end{enumerate}

\subsubsection{Register writes step-by-step}
\begin{enumerate}
  \item Disable trigger core before configuring:
  
\textit{CTR0: write 0 to EN and EN\_TT}\\

  \item Set the minimum and maximum pulse lengths:

\textit{CTR1: writes into MinPL and MaxPL}\\

  \item Set the deglitching mask and pulse length to be used:
  
\textit{CTR0: set CGM and CPL}\\

\item Reenable module:

\textit{CTR0: write 1 to EN and EN\_TT}\\
\end{enumerate}

\subsubsection{Changing the pulse width}

\begin{enumerate}
  \item Disable trigger core before configuring:
  
\textit{CTR0: write 0 to EN and EN\_TT}\\

  \item Check/set the minimum and maximum pulse lengths:

\textit{CTR1: read/write into MinPL and MaxPL}\\

  \item Set the pulse length to be used:
  
\textit{CTR0: set CPL}\\

\item Reenable module:

\textit{CTR0: write 1 to EN and EN\_TT}\\
\end{enumerate}

\pagebreak

\section{Multiboot manager}
\label{sec:multiboot}


\subsection{Structure}
\begin{tabular}{|l|}
\hline
\textit{NOTE1:} this module is platform specific. It only works with Spartan
6\\
\hline
\textit{NOTE2:} in case the EEPROM memory is replaced, SPI opcode will\\ change.
User should notice this issue.\\
\hline
\end{tabular}\\

The trigger module contains sever 
blocks related the following way:\\

--  \textbf{\textit{multiboot\_top.vhd}}

----- \textbf{multiboot\_regs.vhd}

----- \textbf{multiboot\_core.vhd}

--------- ICAP\_SPARTAN6 (\textit{Xilinx primitive})


\subsubsection{\textit{multiboot\_top.vhd}}

The top file of the module. It interconnects the Wishbone to internal register
module, \textit{multiboot\_regs.vhd}, to the core logic in
\textit{multiboot\_core.vhd}.

No \textit{generics} are implemented in this HDL module.

\subsubsection{multiboot\_regs.vhd}

In this module the registers neeeded for specifiying the memory addresses in
which the FPGA must boot to are defined.

An internal register is defined for selectively controlling operations to be
performed by this module (full ICAP reprogramming process, issuing ICAP
commands, refreshing ICAP registers). The set of operations that can be issued
is restricted for security reasons. The allowed operations are further listed in
the \textit{Register subsection}.

\subsubsection{multiboot\_core.vhd}

It is responsible of accessing ICAP port through the internal
\textit{ICAP\_SPARTAN6 Xilinx primitive}. A finite state machine is implemented
in accordance to Chapter 7 of \cite{UG380}.

\subsubsection{Behaviour}

Following the instructions of \cite{UG380} strictly leads to correct multiboot
of the FPGA. Firstly, registers \textit{GENERAL1}, \textit{GENERAL2},
\textit{GENERAL3} and \textit{GENERAL4} must be programmed with valid values. It
should be keept in mind that the \textit{SPI opcode} in \textit{GENERAL4}
register depends on the \textit{EEPROM chip} mounted on the board.\\
Then, a \textit{full multiboot} command must be performed via ICAP interface
through a write in \textit{CTRL} register in \textit{multiboot module}.

\subsection{Parameters}

No \textit{generic} parameters are offered in this module.

\subsection{Registers}
\subsubsection{CTRL}
The \textit{CTRL} register is a read-write register for \textit{OP} field and a
read-only for \textit{PEND} bit.
It specifies the operations that can be controlled by an user.\\

\begin{tabular}{| l | c | c |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
3-0 & OP   & OPeration to be performed \\
\hline
4   & PEND & operation PENDing \\
\hline
\end{tabular}\\

Whenever an operation is specified by the user, it is passed to ICAP Xilinx
primitive through \textit{multiboot\_core.vhd} and the bit flag \textit{PEND} is
set to '1' until it is completely finished.\\

\textbf{Operations}\\

The valid operations that can be requested are the following:\\

\begin{tabular}{| c | l |}
\hline
\textbf{OP byte} & \textbf{Operation}\\
\hline
\hline
0x0 & \textbf{Full multiboot process} as specified in \cite{UG380}\\
\hline
0x1 & \textbf{Write GENERAL1} register from \\
   & \textit{multiboot\_regs.vhd} into FPGA\\
\hline
0x2 & \textbf{Write GENERAL2} register from \\
    & \textit{multiboot\_regs.vhd} into FPGA\\
\hline
0x3 & \textbf{Write GENERAL3} register from \\
       & \textit{multiboot\_regs.vhd} into FPGA\\
\hline
0x4 & \textbf{Write GENERAL4} register from \\
    & \textit{multiboot\_regs.vhd} into FPGA\\
\hline
0x7 & Perform \textbf{IPROG command}\\
\hline
0xD & \textbf{Refresh STAT} register\\
    & into \textit{multiboot\_regs.vhd} \\
\hline
\end{tabular}\\

Full multiboot process, \textit{OP} = 0x0, comprises commamnds:
\begin{enumerate}
  \item \textit{OP} = 0x1
  \item \textit{OP} = 0x2
  \item \textit{OP} = 0x3
  \item \textit{OP} = 0x4
  \item \textit{OP} = 0x7
\end{enumerate}

\subsubsection{STAT}

The \textit{STAT} register is a read-only register. A \textit{refresh operation}
should be completed before retrieving correct \textit{STAT} information.\\

\begin{tabular}{| l | c | l |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
\hline
 0 & CRC\_ERROR & CRC ERROR detected in bitstream\\
\hline
 1 & ID\_ERROR  & IDCODE not validated\\
\hline
 2 & DCM\_LOCK  & DCMs and PLL are locked \\
\hline
 3 & GTS\_CFG\_B & Global tristate\\
\hline
 4 & GWE & Global Write Enable\\
\hline
 5 & GHIGH\_B & GHIGH\\
\hline
 6 & DEC\_ERROR & DEC\_ERROR\\
\hline
 7 & PART\_SECURED & Decryption is set\\
\hline
 8 & HSWAPEN & HWSAPEN\\
\hline
 11-9 & MODE & MODE pins\\
\hline
 12 & INIT\_B & INIT\_B\\
\hline
 13 & DONE & DONE input pins\\
\hline
 14 & IN\_PWRDWN & suspend status\\
\hline
 15 & SWWD\_STRIKEOUT & config error because of invalid sync\\
\hline
\end{tabular}\\

\subsubsection{GENERAL1}

Bit scrambling is done in VHDL code. Bit order must be as specified below:\\

\begin{tabular}{| l | c | l |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
15-0 & MBT\_ADDR\_L & MultiBoot image ADDRess Lower half\\
\hline
\end{tabular}\\

\subsubsection{GENERAL2}

Bit scrambling is done in VHDL code. Bit order must be as specified below:\\

\begin{tabular}{| l | c | l |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
7-0 & MBT\_ADDR\_L & Multiboot image ADDRess Lower Half\\
\hline
15-8 & SPIO & SPI Opcode\\
\hline
\end{tabular}\\

\subsubsection{GENERAL3}

Bit scrambling is done in VHDL code. Bit order must be as specified below:\\

\begin{tabular}{| l | c | l |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
15-0 & GLD\_ADDR\_L & GolDen image ADDRess Lower half\\
\hline
\end{tabular}\\

\subsubsection{GENERAL4}

Bit scrambling is done in VHDL code. Bit order must be as specified below:\\

\begin{tabular}{| l | c | l |}
\hline
\textbf{Bits} & \textbf{Field} & \textbf{Meaning}\\
\hline
7-0 & GLD\_ADDR\_H & GoLDen image ADDRess Higher Half\\
\hline
15-8 & SPIO & SPI Opcode\\
\hline
\end{tabular}\\

\subsection{Internal Memory Mapping}

The Internal Memory Mapping is as follows:\\

\begin{tabular}{| c | c | c |}
\hline
\textbf{Address} & \textbf{Register} & \textbf{Access} \\
\hline
\hline
\textbf{0x0} & \textit{CTRL} & Read-only\\
\hline
\textbf{0x1} & \textit{STAT} & See \textit{STAT} description\\
\hline
\textbf{0x2} & \multicolumn{2}{l|}{Not used}\\
\hline
\textbf{0x3} & \multicolumn{2}{l|}{Not used}\\
\hline
\textbf{0x4} & \textit{GENERAL1} & Read-write\\
\hline
\textbf{0x5} & \textit{GENERAL2} & Read-write\\
\hline
\textbf{0x6} & \textit{GENERAL3} & Read-only\\
\hline
\textbf{0x7} & \textit{GENERAL4} & Read-write\\
\hline
\end{tabular}


\subsection{How to use it}

It requieres three parameters to be specified:

\begin{itemize}
  \item Address of the Golden Image
  \item Address of the Multiboot Image
  \item SPI Opcode of the EEPROM serial interface 
\end{itemize}

Bad specifications of addresses will not reprogram the FPGA.

\subsubsection{Submitting ICAP instructions}

It can be either a two-step or a single-step process. Two-step processes are
related with changes in \textit{GENERAL[X]} register. Submitting an ICAP
command is a single-step-process (\textit{IPROG} instruction, for instance).

\begin {itemize}
\item[\textbf{Example A:}]\\
\textbf{Full Multiboot Configuration}\\
This is a scenario is useful when the EEPROM memory map has changed for
the allocation of the two FPGA bitstreams.
\begin {enumerate}
  \item Write \textit{GENERAL1} register.
  \item Write \textit{GENERAL2} register.
  \item Write \textit{GENERAL3} register.
  \item Write \textit{GENERAL4} register.
  \item Write \textit{CTRL} register.\\
  \textit{CTRL} should issue a \textbf{Full multiboot process} operation code
  (0x0).
\end {enumerate}
\item[\textbf{Example B:}]\\
\textbf{Change an individual Boot Look Up Address}\\
This is a scenario is useful when the EEPROM memory map has changed for
the allocation of only one of the FPGA bitstreams.
\begin {enumerate}
  \item Write \textit{GENERAL[X]} register. Where X={1,3}
  \item Write \textit{GENERAL[X+1]} register.
  \item Write \textit{CTRL} register.\\
  \textit{CTRL} should issue a \textbf{Write GENERAL[X]} operation code.
  \item Write \textit{CTRL} register.\\
  \textit{CTRL} should issue a \textbf{Write GENERAL[X+1]} operation code.
\end {enumerate}

\item[\textbf{Example C:}]\\
\textbf{Reprogram FPGA without change in Bitstream Location}\\
If the EEPROM memory map has not changed but we want to reload one of the
images, we just issue an \textit{IPROG} instruction through the \textit{ICAP}
interface.
\begin {enumerate}
  \item Write \textit{CTRL} register.\\
  \textit{CTRL} should issue an \textbf{IPROG} operation code(0x7).
\end {enumerate}
\end {itemize}

\pagebreak

\section{EEPROM manager}
\label{sec:EEPROM}

\pagebreak
\bibliographystyle{unsrt}
\bibliography{UserGuide}
\end{document}