Commit c47eecf9 authored by Theodor-Adrian Stana's avatar Theodor-Adrian Stana

continued work on pts_hdlguide

parent e2084caf
This diff is collapsed.
This diff is collapsed.
No preview for this file type
......@@ -49,9 +49,7 @@ BE-CO-HT\\
\begin{tabular}{l l}
\textit{FPGA} & Field-Programmable Gate Array \\
\textit{PTS} & Production Test Suite \\
\textit{RTM} & Rear Transition Module \\
\textit{RTMM} & RTM Motherboard \\
\textit{RTMP} & RTM Piggyback \\
\textit{HDL} & High-level Description Language \\
\textit{SFP} & Small form-factor pluggable (in the context of SFP connectors) \\
\end{tabular}
......@@ -63,12 +61,12 @@ BE-CO-HT\\
\section{Introduction}
\label{sec:intro}
This document presents a high-level view of the firmware implemented on the FPGA for the
Production Test Suite (PTS) project for the Conv-TTL-Blo board. The document starts with a
description of the folder structure and where the developer should look for specific files.
In the following section, the structure of the top-level HDL file is given along with
hints on where the developer should look in case changes are to be made
to the code. After that, the memory map is presented, followed by sections
describing the logic implemented to run the tests comprising PTS.
Production Test Suite (PTS) project for the Conv-TTL-Blo board. The document starts by
presenting the memory map, followed by sections describing the logic implemented to run
the tests comprising PTS. Then, the folder structure is described, along with hints on where
the developer should look for specific files. This is followed by a presentation on the
structure of the top-level HDL together with hints on where the developer should look in case
changes are to be made to the code.
All the logic implemented on the FPGA is written in VHDL and can be obtained freely by cloning
the OHWR git repository for the Conv-TTL-Blo PTS project at the following link:
......@@ -79,6 +77,140 @@ the OHWR git repository for the Conv-TTL-Blo PTS project at the following link:
\textcolor{red}{REFERENCE THE OTHER DOCUMENTS}
%======================================================================================
% SEC: Memory map
%======================================================================================
\pagebreak
\section{Memory Map}
\label{sec:memmap}
Various peripherals on the Conv-TTL-Blo board can be accessed by sending telnet commands
to the VME crate; these commands are sent to the converter board by means of the serial
I$2$C interface on the VME P1 connector. Each board peripheral is accessible via a
memory-mapped Wishbone interface. A \textit{vme64x\_i2c} component
\textcolor{red}{(reference)} is used alongside a Wishbone crossbar component
\textcolor{red}{(reference)} to translate the I$2$C transfers into Wishbone
transfers. Fig.~\ref{fig:memmapping} shows how these two components are connected to various
other memory-mapped Wishbone slaves.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/memmapping}}
\caption{Memory-mapping several on-board peripherals in FPGA firmware}
\label{fig:memmapping}
\end{figure}
The PTS firmware accesses all peripheral devices on the Conv-TTL-Blo board and sends
device-specific commands to test their functionality. Table~\ref{tbl:memmap} shows a simplified
version of the memory map, with the base addresses of each peripheral. Details
about the memory map of each device can be found by reading the description of the
peripheral devices in the following sections.
\begin{table}[h]
\caption{Memory map of the PTS firmware}
\label{tbl:memmap}
\centerline
{
\begin{tabular}{l l p{.65\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{Address}} & \multicolumn{1}{c}{\textbf{Name}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
0x000 & \textit{pts\_regs} & General-purpose registers \\
0x010 & \textit{onewire\_mst} & One-wire master for thermal sensor \\
0x020 & \textit{dac\_spi\_125} & SPI master to control the 125~MHz DAC \\
0x080 & \textit{dac\_spi\_20} & SPI master to control the 20~MHz DAC \\
0x100 & \textit{clk\_info\_125} & Counters used to observe changes
in the 125~MHz clock \\
0x120 & \textit{clk\_info\_125} & Counters used to observe changes
in the 20~MHz clock \\
0x140 & \textit{sfp\_i2c} & I$2$C master interface for communicating
to SFP EEPROM \\
0x200 & \textit{endpoint} & Endpoint for communicating via the SFP \\
0x400 & \textit{minic} & MiniNIC for communicating via the SFP \\
0x800 & \textit{dpram} & Dual-port RAM for the \textit{endpoint} and
\textit{minic} components \\
0xC00 & \textit{pulse\_cntrs} & Pulse counters for TTL and blocking pulse
repetition tests \\
\hline
\end{tabular}
}
\end{table}
%======================================================================================
% SEC: Memory map
%======================================================================================
\pagebreak
\section{PTS General-Purpose Registers}
\label{sec:pts_regs}
Two registers are implemented as general-purpose registers for the PTS.
The first is a control and status register (CSR), at offset 0x0, followed by a
board ID register at offset 0x4 (see Table~\ref{tbl:pts_regs}). Both registers are 32 bits wide.
\begin{table}[h]
\caption{General-purpose registers for PTS}
\label{tbl:pts_regs}
\centerline
{
\begin{tabular}{l l l l}
\hline
\multicolumn{1}{c}{\textbf{Offset}} & \multicolumn{1}{c}{\textbf{Name}} &
\multicolumn{1}{c}{\textbf{Access}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
0x0 & \textit{csr} & R/W & Control and Status Register \\
0x4 & \textit{board\_id} & R/W & Board ID register \\
\hline
\end{tabular}
}
\end{table}
The board ID register contains 32 read-and-writable bits which can be
used to identify the board as the CONV-TTL-BLO. It is by default set to
read as the ASCII string \textbf{BLO2}, the hex value 0x424C4F32.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/pts-csr}}
\caption{PTS CSR}
\label{fig:pts-csr}
\end{figure}
Fig.~\ref{fig:pts-csr} shows the control and status register of PTS.
It consists of 16 bits of control data and 16 bits of status data. The first
four bits are used to enable various test functionality. The reset bit can be
used to reset all of the logic inside the FPGA when set (logic high). Caution
should therefore be taken when writing the CSR, as an erroneous write might
result in the whole logic resetting itself. When the logic is reset via a write
to this bit, the \textit{writereg} telnet command will return a \textit{Not acknowledged!},
as the reset bit also resets the \textit{vme64x\_i2c} module.
\begin{table}[h]
\caption{CSR fields}
\label{tbl:pts-csr}
\centerline
{
\begin{tabular}{l l p{.5\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{Name}} & \multicolumn{1}{c}{\textbf{Access}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
TPEN & R/W & \textbf{1} -- enable TTL pulse generation \newline
\textbf{0} -- disable TTL pulse generation \\
BPEN & R/W & \textbf{1} -- enable blocking pulse generation \newline
\textbf{0} -- disable blocking pulse generation \\
BLD & R/W & Rear pulse LED line value \\
PLDEN & R/W & \textbf{1} -- enable pulse LED sequencing \newline
\textbf{0} -- disable pulse LED sequencing \\
SLDEN & R/W & \textbf{1} -- enable status LED sequencing \newline
\textbf{0} -- disable status LED sequencing \\
RST & R/W & \textbf{1} -- Reset FPGA logic \newline
\textbf{Note:} Will reset \textit{all} FPGA logic; therefore, it also resets itself. \\
\hline
\end{tabular}
}
\end{table}
The RTM field in the CSR can be used to read the status of the RTM detection
lines and is relevant within the context of the blocking pulse and RTM interface
test.
\pagebreak
\bibliographystyle{ieeetr}
\bibliography{pts_hdlguide}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment