Skip to content

C
Conv TTL Blocking
Commit 5e7ec862 authored by Theodor-Adrian Stana's avatar Theodor-Adrian Stana
Browse files
Options

Started vme64x_i2c doc

parent 6602f10f
Hide whitespace changes
Inline Side-by-side
Showing with 188 additions and 42 deletions
hdl/vme64x_i2c/doc/i2c_slave.tex → hdl/vme64x_i2c/doc/i2c_slave/i2c_slave.tex
View file @ 5e7ec862
......@@ -76,11 +76,9 @@ In this way, a device can set a logic low level on the bus by driving the pin an
high level by releasing the pin.
\begin{figure}[b]
\begin{center}
\includegraphics[width=\textwidth]{fig/i2c-bus}
\caption{I$^2$C bus topology}
\label{fig:i2c-bus}
\end{center}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bus}}
\caption{I$^2$C bus topology}
\label{fig:i2c-bus}
\end{figure}
To initiate a transfer, a master on the bus generates a start condition, driving the SDA
......@@ -92,14 +90,12 @@ of the bus by issuing a stop condition. This is done by releasing the SDA line w
line is high. Alternatively, if the master has finished the transfer and still wants to
continue sending data, it can issue a repeated start condition, which is identical to the
start condition. The various types of bit-level transfers are summarized in
Figure~\ref{fig:i2c-bitlevel}.
Fig.~\ref{fig:i2c-bitlevel}.
\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{fig/i2c-bitlevel}
\caption{Bit-level transfers on the I$^2$C bus}
\label{fig:i2c-bitlevel}
\end{center}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bitlevel}}
\caption{Bit-level transfers on the I$^2$C bus}
\label{fig:i2c-bitlevel}
\end{figure}
Since there can be more than one slave on the bus, each bus is assigned an address to which
......@@ -108,11 +104,9 @@ a 7-bit addressing mode and a 10-bit addressing mode. Of the two, the 7-bit addr
the most widely used and also the only mode that the \textit{i2c\_slave} module supports.
\begin{figure}[b]
\begin{center}
\includegraphics[width=\textwidth]{fig/i2c-addr}
\caption{Sending of the address byte by the master}
\label{fig:i2c-addr}
\end{center}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-addr}}
\caption{Sending of the address byte by the master}
\label{fig:i2c-addr}
\end{figure}
By this mode, after the master issues the start condition on the bus, it sends a series of
......@@ -120,7 +114,7 @@ seven address bits MSB-first on the bus, followed by an eighth bit stating wheth
wishes to read from ('1') or write to ('0') the slave. After this series of eight bits, if a
slave with this address exists on the bus, it must acknowledge (ACK) the transfer by driving the
SDA line low. If no master with this address exists, the SDA line remains high
(not acknowledge--NACK) and the master aborts the transfer. Figure~\ref{fig:i2c-addr} shows
(not acknowledge--NACK) and the master aborts the transfer. Fig.~\ref{fig:i2c-addr} shows
how a master sends the address byte to the slave and how a slave acknowledges the transfer.
After a slave acknowledges its address, actual data transfer can begin. Based on the
......@@ -133,18 +127,16 @@ after the ACK/NACK bit has been sent. The master can issue a stop condition as a
an ACK and an NACK. A stop condition can however not follow a start condition without
transferring data.
An example data transfer is shown in Figure~\ref{fig:i2c-transf}. The master first issues a
An example data transfer is shown in Fig.~\ref{fig:i2c-transf}. The master first issues a
start condition and sends the address, which is acknowledged by the slave. Data transfer then
starts, with either the master or the slave sending data. At one point, the master decides to
reverse the order of data transfer and issues a repeated start with the R/$\bar{W}$ bit flipped.
A number of data bytes are transferred, and the master ends the transfer with the stop condition.
\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{fig/i2c-transf}
\caption{Bytes transferred on the I$^2$C bus}
\label{fig:i2c-transf}
\end{center}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-transf}}
\caption{Bytes transferred on the I$^2$C bus}
\label{fig:i2c-transf}
\end{figure}
%==============================================================================
......@@ -156,15 +148,13 @@ A number of data bytes are transferred, and the master ends the transfer with th
This section offers information useful for instantiating the \textit{i2c\_slave} core module.
Table~\ref{tbl:ports} presents a list of ports of the \textit{i2c\_slave} module.
I$^2$C-specific ports should be instantiated as outlined in Figure~\ref{fig:i2c-ports}, via
I$^2$C-specific ports should be instantiated as outlined in Fig.~\ref{fig:i2c-ports}, via
tri-state buffers enabled by the \textit{scl\_en\_o} lines \textit{sda\_en\_o}.
\begin{figure}[h]
\begin{center}
\includegraphics[width=.75\textwidth]{fig/i2c-ports}
\caption{Connecting the I$^2$C ports}
\label{fig:i2c-ports}
\end{center}
\centerline{\includegraphics[width=.75\textwidth]{fig/i2c-ports}}
\caption{Connecting the I$^2$C ports}
\label{fig:i2c-ports}
\end{figure}
\pagebreak
......@@ -197,13 +187,14 @@ To instantiate a tri-state buffer in VHDL:
The rest of the ports should be connected in a normal manner to an external controlling module. A
component declaration of the \textit{i2c\_slave} module is readily available in the
\textit{i2c\_slave\_pkg.vhd} package file. The package also defines constants for the
statuses readable at the \textit{stat\_o} pin. Refer to Section~\ref{sec:oper} for details
about the details regarding the various statuses.
statuses readable at the \textit{stat\_o} pin. Refer to Sec.~\ref{sec:oper} for details
regarding the various statuses.
\begin{table}[h]
\caption{Ports of \textit{i2c\_slave} module}
\label{tbl:ports}
\begin{center}
\centerline
{
\begin{tabular}{l c p{.65\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{Name}} & \multicolumn{1}{c}{\textbf{Size}} & \multicolumn{1}{c}{\textbf{Description}} \\
......@@ -225,8 +216,8 @@ about the details regarding the various statuses.
has performed a valid transfer \\
stat\_o & 3 & Current state of communication \\
\hline
\end{tabular}
\end{center}
\end{tabular}
}
\end{table}
%==============================================================================
......@@ -334,17 +325,15 @@ Below are the steps which should be followed to write one or more bytes to a mas
\label{sec:implem}
This section presents implementation details of the \textit{i2c\_slave} module. A simplified
block diagram of the module is presented in Figure~\ref{fig:i2c-slave-bd}.
block diagram of the module is presented in Fig.~\ref{fig:i2c-slave-bd}.
Deglitched versions of the SCL and SDA lines control operation of the central finite-state
machine (FSM), which sets the outputs and controls the rest of the components in the module.
\begin{figure}[h]
\begin{center}
\includegraphics[width=\textwidth]{fig/i2c-slave-bd}
\caption{Block diagram of \textit{i2c\_slave} module}
\label{fig:i2c-slave-bd}
\end{center}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-slave-bd}}
\caption{Block diagram of \textit{i2c\_slave} module}
\label{fig:i2c-slave-bd}
\end{figure}
The FSM is sensitive to start and stop conditions and falling edges of the SCL line. It
......@@ -358,7 +347,7 @@ in each state.
\label{tbl:fsm}
\centerline
{
\begin{tabular}{l p{.65\textwidth}}
\begin{tabular}{l p{.65\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{State}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
......@@ -390,7 +379,7 @@ in each state.
If '0', go back to \textit{WR} state, otherwise go to \textit{IDLE}
state. \\
\hline
\end{tabular}
\end{tabular}
}
\end{table}
......
hdl/vme64x_i2c/doc/vme64x_i2c/Makefile 0 → 100644
View file @ 5e7ec862
FILE=vme64x_i2c
all:
pdflatex -synctex=1 -interaction=nonstopmode *.tex
bibtex *.aux
pdflatex -synctex=1 -interaction=nonstopmode *.tex
pdflatex -synctex=1 -interaction=nonstopmode *.tex
evince $(FILE).pdf &
clean:
rm -rf *.aux *.dvi *.log $(FILE).pdf *.lof *.lot *.out *.toc *.bbl *.blg *.gz
hdl/vme64x_i2c/doc/vme64x_i2c/vme64x_i2c.bib 0 → 100644
View file @ 5e7ec862
@misc{sysmon-i2c,
author = "{ELMA}",
title = {{Access to board data using SNMP and I2C}},
howpublished = {\url{http://www.ohwr.org/documents/227}}
}
hdl/vme64x_i2c/doc/vme64x_i2c/vme64x_i2c.tex 0 → 100644
View file @ 5e7ec862
%==============================================================================
% Document header
%==============================================================================
\documentclass[a4paper,11pt]{article}
\usepackage[pdfborder= 0 0 0 1]{hyperref}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{rotating}
\usepackage{multirow}
\usepackage{color}
%==============================================================================
% Start of document
%==============================================================================
\begin{document}
\title{VME64x I$^2$C to Wishbone bridge}
\author
{
Theodor-Adrian Stana \\
CERN, BE-CO-HT \\
}
\date{\today}
\maketitle
\thispagestyle{empty}
\begin{figure}
\begin{center}
\includegraphics[scale=.25,keepaspectratio]{fig/cern-logo.png}
\end{center}
\end{figure}
% Break page
\pagebreak
% Generate TOC and pagebreak after it
\tableofcontents
\pagebreak
%==============================================================================
% SEC: Intro
%==============================================================================
\section{Introduction}
\label{sec:intro}
This document describes the \textit{vme64x\_i2c} module, an I$^2$C to Wishbone
bridge for the VME64x crates. The module implements an I$^2$C slave and translates
the protocol defined by ELMA in \cite{sysmon-i2c} into Wishbone accesses to a
Wishbone slave device of choice.
%==============================================================================
% SEC: Protocol
%==============================================================================
\section{ELMA I$^2$C Protocol}
\label{sec:elma-i2c}
\textcolor{red}{WRITE THIS THING}
%==============================================================================
% SEC: Implem
%==============================================================================
\section{Implementation}
\label{sec:implem}
In order to perform low-level I$^2$C transfers, the \textit{i2c\_slave} module
is instantiated and used within the \textit{vme64x\_i2c} module. The outputs of
the \textit{i2c\_slave} module \textcolor{red}{REFERENCE?} are used as controls for an eight-state
finite state machine (FSM), shown in Table~\ref{tbl:state-mach}. When the
\textit{i2c\_slave} module finishes a transfer (signaled by a \textit{done\_p\_o}
pulse), the status is checked and if it is as expected (e.g., a \textit{address good}
in the \textit{ST\_IDLE} state), the FSM advances to the next state.
\begin{table}[h]
\caption{\textit{vme64x\_i2c} state machine}
\label{tbl:state-mach}
\centerline
{
\begin{tabular}{l p{.65\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{State}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
ST\_IDLE & Wait for the \textit{i2c\_slave} module to receive the I$^2$C
address and go to \textit{ST\_WB\_ADR}. The starting value at the
\textit{op\_o} output of the \textit{i2c\_slave} module is stored
for checking in \textit{ST\_OP} \\
ST\_WB\_ADR & Shift in the two address bytes sent via I$^2$C and go to
\textit{ST\_SIM\_WB\_TRANSF} \\
ST\_SIM\_WB\_TRANSF & Start a Wishbone read transfer from address received in previous
state and go to \textit{ST\_OP} if Wishbone address exists (Wishbone
\textit{ack} received, or \textit{ST\_IDLE} otherwise (Wishbone \textit{err}
received) \\
ST\_OP & Check the \textit{op\_o} output of the \textit{i2c\_slave} module.
If different from the value at the start, go to \textit{ST\_SYSMON\_RD\_WB} state
(SysMon is reading from CONV-TTL-BLO), otherwise continue shifting
in bytes (SysMon writing to CONV-TTL-BLO) \\
ST\_SYSMON\_WR & Continue reading up to four bytes sent by the SysMon and go to
\textit{ST\_SYSMON\_WR\_WB}\\
ST\_SYSMON\_WR\_WB & Perform a Wishbone write transfer to the register with the address obtained in
\textit{ST\_WB\_ADR} \\
ST\_SYSMON\_RD\_WB & Perform a Wishbone read transfer from the address obtained in
\textit{ST\_WB\_ADR} and go to \textit{ST\_SYSMON\_RD} \\
ST\_SYSMON\_RD & Shift out the four bytes of the Wishbone register when the \textit{i2c\_slave}
module successfully finishes a write \\
\hline
\end{tabular}
}
\end{table}
It should be noted that where the SysMon appears in the state names, it indicates
what the SysMon action is. That is, if the state of the FSM is \textit{ST\_SYSMON\_WR},
this means the SysMon is writing and the CONV-TTL-BLO is reading.
To better understand how the FSM operates, \textcolor{red}{BYTE ORDER FIGURES} can be consulted,
where each I$^2$C transfer is correlated to the current state of the FSM.
When reading from the SysMon, the \textit{vme64x\_i2c} module will wait in the
\textit{ST\_IDLE} state while the I$^2$C address is sent, then go to the
\textit{ST\_WB\_ADR} state to shift in the address. A Wishbone transfer is
simulated and if the address exists (a Wishbone \textit{ack} is received),
the first byte is shifted in while in the \textit{ST\_OP} state, followed
by the next three bytes while in the \textit{ST\_SYSMON\_WR} state. After that,
the register is written to in the \textit{ST\_SYSMON\_WR\_WB} state.
When writing to the SysMon, the first few steps are the same as for reading from it.
The address is shifted in and checked in the Wishbone transfer simulation state.
In the case of a SysMon reading from a board, however, the I$^2$C transfer
is restarted and the order is reversed (SysMon starts reading). Thus, while in
\textit{ST\_OP}, the FSM detects a different value of \textit{op\_o} and goes into
the \textit{ST\_SYSMON\_RD\_WB} state. Here, an actual Wishbone read transfer is
executed, the value of the register is read and sent via I$^2$C in the\\
\textit{ST\_SYSMON\_RD} state.
%==============================================================================
% Bibliography
%==============================================================================
\pagebreak
\bibliographystyle{ieeetr}
\bibliography{vme64x_i2c}
\end{document}
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