Skip to content

C
Conv TTL Blocking - Gateware
Commit 861d6e9b authored by Theodor-Adrian Stana's avatar Theodor-Adrian Stana
Browse files
Options

Changes to i2c docs

parent b7a8c35f
Hide whitespace changes
Inline Side-by-side
Showing with 569 additions and 92 deletions
doc/userguide/userguide-conv-ttl-blo.tex
View file @ 861d6e9b
......@@ -41,7 +41,7 @@
\hline
19-06-2013 & 1.00 & First version \\
21-06-2013 & 1.01 & Added termination resistors to Fig.~\ref{fig:ttl-chan},~\ref{fig:invttl-chan} \\
04-07-2013 & 1.02 & New title page and page layout \\
22-07-2013 & 1.02 & New title page and page layout \\
\hline
\end{tabular}
}
......@@ -365,7 +365,6 @@ pulses.
\noindent Note 2: $V_{IH}$, $V_{IL}$ correspond to the thresholds of input Schmitt triggers. \\
\noindent Note 3: Max. pulse frequency dictated by blocking output max. frequency. \\
\pagebreak
\begin{table}[h]
\caption{Blocking pulse characteristics}
......@@ -392,7 +391,7 @@ pulses.
\end{table}
\noindent Note 1: Pulse amplitude for which a $t_{p,o}$ pulse is replicated at the output. \\
\noindent Note 2: Voltage amplitude between the differential signal lines \\
\noindent Note 2: Voltage amplitude between the differential signal lines. \\
%--------------------------------------------------------------------------------------
% SUBSEC: TTL vs TTL-BAR
......@@ -495,7 +494,7 @@ on the leading edge of the output signal. Jitter appears in the form of pulses b
either 8~ns before or 8~ns after the ideal edge, based on when the input pulse is sampled.
This is shown in Figure~\ref{fig:tpd-jit}.
When SW1.1 is in the \textbf{OFF} (default) position, the giltch filter is disabled and the
When SW1.1 is in the \textbf{OFF} (default) position, the glitch filter is disabled and the
pulse signal is regenerated at the output without being sampled with an on-board clock. This
yields jitter-free pulses at the output, but a glitch on the input will lead to a pulse being
generated at the output.
......@@ -743,7 +742,7 @@ with glitch filter) of the CH1 and CH4 blocking conversions.
%--------------------------------------------------------------------------------------
\subsection{Repeating TTL pulses in TTL-BAR}
When the board has already been plugged in and the switch has been set in, e.g., the
When the board has already been plugged in and the switch has been set in the
\textbf{OFF} position, only TTL-BAR pulses can be input on a front panel replication channel.
If the user desires to input a TTL pulse and repeat it into TTL-BAR, one of the four
general-purpose inverter channels can be used. Figure~\ref{fig:ex-invert-ttl} shows a
......
hdl/elma_i2c/doc/elma_i2c/elma_i2c.bib
View file @ 861d6e9b
......@@ -9,3 +9,9 @@
title = {{Wishbone System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores}},
howpublished = {\url{http://cdn.opencores.org/downloads/wbspec_b4.pdf}}
}
@misc{sysmon,
author = "{ELMA}",
title = {{New SysMon User Manual Rev. 1.11}},
howpublished = {\url{http://www.ohwr.org/documents/226}}
}
hdl/elma_i2c/doc/elma_i2c/elma_i2c.tex
View file @ 861d6e9b
......@@ -40,7 +40,7 @@
\hline
\multicolumn{1}{c}{\textbf{Date}} & \multicolumn{1}{c}{\textbf{Version}} & \multicolumn{1}{c}{\textbf{Change}} \\
\hline
26-06-2013 & 1.00 & First version \\
26-06-2013 & 0.01 & First draft \\
\hline
\end{tabular}
}
......@@ -76,9 +76,24 @@
\label{sec:intro}
This document describes the \textit{elma\_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 \cite{wb-spec}
accesses to a Wishbone slave device.
bridge HDL core for VME64x crates from ELMA. These crates offer the possibility of accessing
boards in VME slots via either VME, or I$^2$C. Boards not using the VME lines
on a slot can implement the \textit{elma\_i2c} module on an FPGA; implements an
I$^2$C slave and translates I$^2$C accesses into Wishbone \cite{wb-spec} accesses to a
Wishbone slave device.
A typical system where the \textit{elma\_i2c} module is employed is shown in
Figure~\ref{fig:sys}. ELMA VME crates contain a SysMon (system monitor) board~\cite{sysmon},
that is mainly used for monitoring VME voltages and controlling the fans of the VME crate.
The SysMon can be connected to via either a serial connection or Telnet. Then, sending
specific commands (see Section \ref{sec:testing}) via one of the two are translated by the
SysMon into I$^2$C accesses following the protocol described in Section~\ref{sec:elma-i2c}.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/sys}}
\caption{Typical system for the \textit{elma\_i2c} module}
\label{fig:sys}
\end{figure}
%==============================================================================
% SEC: Instantiation
......@@ -88,8 +103,8 @@ accesses to a Wishbone slave device.
The ports of the \textit{elma\_i2c} module are shown in Table~\ref{tbl:ports}.
The I$^2$C signals should be connected to tri-state ports, as shown in
Figure~\ref{fig:i2c-ports}, and Wishbone slaves should be connected to the
Wishbone master interface at the \textit{wbm\_*} ports.
Figure~\ref{fig:i2c-ports}; Wishbone slaves should be connected to the
Wishbone master interface ports, prefixed with \textit{wbm}.
\begin{table}[h]
\caption{Ports of \textit{elma\_i2c} module}
......@@ -168,15 +183,99 @@ Wishbone master interface at the \textit{wbm\_*} ports.
% }
%\end{table}
%==============================================================================
% SEC: Testing
%==============================================================================
\section{Testing the \textit{elma\_i2c} module}
\label{sec:testing}
After proper synthesis and download to the FPGA, a Telnet or serial connection
should be made to the SysMon board. Commands can then be sent to the boards via
the SysMon. The two commands relevant for accessing board registers are \textit{readreg}
and \textit{writereg}, outlined in Table~\ref{tbl:cmds}.
\begin{table}[h]
\caption{The \textit{readreg} and \textit{writereg} commands}
\label{tbl:cmds}
\centerline
{
\begin{tabular}{l p{.6\textwidth}}
\hline
\multicolumn{1}{c}{\textbf{Command}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
writereg \textit{slot reg val} & Writes the value \textit{val} to register number
\textit{reg} of board in slot number \textit{slot} \\
readreg \textit{slot reg} & Returns the value of register number \textit{reg} of
board in slot number \textit{slot} \\
\hline
\end{tabular}
}
\end{table}
Register (\textit{reg}) numbers in these commands are decimal numbers starting from 1.
The SysMon translates \textit{reg} numbers into word-aligned addresses, thus in order
to obtain the actual register addres, the following relation should be used:
\begin{center}
$ addr = (reg-1)*4 $
\end{center}
Table~\ref{tbl:reg} shows the \textit{reg} numbers of registers in the address
space 0x00 to 0x20.
\begin{table}[h]
\caption{Translating \textit{reg} numbers to addresses}
\label{tbl:reg}
\centerline
{
\begin{tabular}{c c}
\hline
\textbf{\textit{reg}} & \textbf{Address} \\
\hline
1 & 0x00 \\
2 & 0x04 \\
3 & 0x08 \\
4 & 0x0C \\
5 & 0x10 \\
6 & 0x14 \\
7 & 0x18 \\
8 & 0x1C \\
9 & 0x20 \\
\hline
\end{tabular}
}
\end{table}
The example below shows how to connect to an ELMA crate at IP address 1.2.3.4,
obtaining the value of a register at address 0x10 in a board in VME slot 2,
writing the decimal value 12 to the same register and reading it back to check for
proper modification.
\begin{verbatim}
$ telnet 1.2.3.4
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
login:user
password:**********
%>readreg 2 5
Read Data: 00ABCDEF
%>writereg 2 5 12
Done!
%>readreg 2 5
Read Data: 0000000C
\end{verbatim}
%==============================================================================
% SEC: Protocol
%==============================================================================
\pagebreak
\section{ELMA I$^2$C Protocol}
\label{sec:elma-i2c}
Using the I$^2$C lines on the VME P1 connector, one can access boards placed
in a VME crate. In this purpose, ELMA has defined a higher-level protocol
\cite{sysmon-i2c} that uses I$^2$C as a low-level protocol.
in a VME crate. For this purpose, ELMA has defined a higher-level protocol~\cite{sysmon-i2c}
that uses I$^2$C as a low-level protocol.
Figure~\ref{fig:sysmon-wr} shows a write operation from the SysMon to a VME
board. The process starts with the control byte, containing the board's
......@@ -185,7 +284,7 @@ I$^2$C write. After the slave's ACK, the following two bytes send the
12-bit address in little-endian order (most significant byte first).
After the address has been acknowledged, the following four I$^2$C transfers
are used to transmit the 32-bit data to be written to the board register.
Data transmission occurs with the least significant byte first (big-endian).
Data transmission occurs in big-endian order (least significant byte first).
\begin{figure}[h]
\centerline{\includegraphics[width=.9\textwidth]{fig/sysmon-wr}}
......
hdl/elma_i2c/doc/elma_i2c/fig/sys.svg 0 → 100644
View file @ 861d6e9b
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="497.06299"
height="178.16537"
id="svg2"
version="1.1"
inkscape:version="0.48.3.1 r9886"
sodipodi:docname="sys.svg">
<defs
id="defs4">
<marker
inkscape:stockid="TriangleOutM"
orient="auto"
refY="0"
refX="0"
id="TriangleOutM"
style="overflow:visible">
<path
id="path3928"
d="m 5.77,0 -8.65,5 0,-10 8.65,5 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
transform="scale(0.4,0.4)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="TriangleOutL"
orient="auto"
refY="0"
refX="0"
id="TriangleOutL"
style="overflow:visible">
<path
id="path3925"
d="m 5.77,0 -8.65,5 0,-10 8.65,5 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
transform="scale(0.8,0.8)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="TriangleInM"
orient="auto"
refY="0"
refX="0"
id="TriangleInM"
style="overflow:visible">
<path
id="path3919"
d="m 5.77,0 -8.65,5 0,-10 8.65,5 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
transform="scale(-0.4,-0.4)"
inkscape:connector-curvature="0" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.4"
inkscape:cx="142.2339"
inkscape:cy="34.318633"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="true"
showguides="true"
inkscape:guide-bbox="true"
inkscape:window-width="1855"
inkscape:window-height="1176"
inkscape:window-x="65"
inkscape:window-y="24"
inkscape:window-maximized="1"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0">
<inkscape:grid
type="xygrid"
id="grid2985"
empspacing="5"
visible="true"
enabled="true"
snapvisiblegridlinesonly="true"
units="mm"
spacingx="1mm"
spacingy="1mm"
originx="-39.858889mm"
originy="-214.85889mm" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-141.23228,-112.8858)">
<rect
style="opacity:0.98999999;fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect2987"
width="141.73228"
height="177.16536"
x="141.73228"
y="113.3858" />
<rect
y="113.38581"
x="354.33069"
height="177.16536"
width="283.4646"
id="rect3757"
style="opacity:0.98999999;fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />
<rect
style="opacity:0.98999999;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1.66666675;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect3759"
width="29.527559"
height="118.11024"
x="354.33063"
y="142.91338" />
<text
xml:space="preserve"
style="font-size:16.66666794px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#ffffff;fill-opacity:1;stroke:none;font-family:Sans"
x="167.25984"
y="-363.01941"
id="text3761"
sodipodi:linespacing="125%"
transform="matrix(0,1,-1,0,0,0)"><tspan
sodipodi:role="line"
id="tspan3763"
x="167.25984"
y="-363.01941"
style="font-weight:bold;fill:#ffffff;fill-opacity:1">VME P1</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleInM);marker-end:url(#TriangleOutM)"
d="m 287.00787,184.25195 63.77953,0"
id="path3775"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
x="299.33466"
y="180.70863"
id="text4599"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4601"
x="299.33466"
y="180.70863">SERCLK</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#b2b2b2;fill-opacity:1;stroke:none;font-family:Sans"
x="160.3035"
y="208.28488"
id="text4607"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4609"
x="160.3035"
y="208.28488"
style="font-size:24px;font-weight:bold;fill:#000000;fill-opacity:1">SysMon</tspan></text>
<text
sodipodi:linespacing="125%"
id="text4611"
y="134.64565"
x="423.92236"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
xml:space="preserve"><tspan
style="font-size:24px;font-weight:bold;fill:#000000;fill-opacity:1"
y="134.64565"
x="423.92236"
id="tspan4613"
sodipodi:role="line">VME board</tspan></text>
<rect
style="opacity:0.98999999;fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect4615"
width="205.51183"
height="106.29921"
x="425.19684"
y="148.81888" />
<path
sodipodi:nodetypes="cc"
inkscape:connector-curvature="0"
id="path4619"
d="m 389.76378,184.25195 31.88977,0"
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleInM);marker-end:url(#TriangleOutM)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleInM);marker-end:url(#TriangleOutM)"
d="m 389.76378,219.68502 31.88977,0"
id="path4621"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
sodipodi:linespacing="125%"
id="text4623"
y="180.70863"
x="396.85037"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
xml:space="preserve"><tspan
y="180.70863"
x="396.85037"
id="tspan4625"
sodipodi:role="line">SCL</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
x="396.85037"
y="216.14171"
id="text4627"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4629"
x="396.85037"
y="216.14171">SDA</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
x="509.36975"
y="159.44879"
id="text4631"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4633"
x="509.36975"
y="159.44879"
style="font-size:12px;font-weight:bold;fill:#000000;fill-opacity:1">FPGA</tspan></text>
<path
sodipodi:nodetypes="cc"
inkscape:connector-curvature="0"
id="path4635"
d="m 287.00787,219.68503 63.77953,0"
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleInM);marker-end:url(#TriangleOutM)" />
<text
sodipodi:linespacing="125%"
id="text4637"
y="216.14171"
x="298.89764"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
xml:space="preserve"><tspan
y="216.14171"
x="298.89764"
id="tspan4639"
sodipodi:role="line">SERDAT</tspan></text>
<rect
style="opacity:0.98999999;fill:#b2b2b2;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect4955"
width="60.236233"
height="56.692913"
x="425.19684"
y="173.62202" />
<text
sodipodi:linespacing="125%"
id="text4957"
y="204.5881"
x="431.07422"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
xml:space="preserve"><tspan
style="font-size:10px;font-weight:bold;fill:#000000;fill-opacity:1"
y="204.5881"
x="431.07422"
id="tspan4959"
sodipodi:role="line">elma_i2c</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleInM);marker-end:url(#TriangleOutM)"
d="m 488.97638,201.96848 14.17323,0"
id="path4961"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<rect
y="173.62202"
x="506.6929"
height="56.692913"
width="116.92915"
id="rect4963"
style="opacity:0.98999999;fill:#b2b2b2;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
x="565.16724"
y="192.22726"
id="text4965"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4967"
x="565.16724"
y="192.22726"
style="font-size:10px;font-weight:bold;text-align:center;text-anchor:middle;fill:#000000;fill-opacity:1">Wishbone</tspan><tspan
sodipodi:role="line"
x="565.16724"
y="204.72726"
style="font-size:10px;font-weight:bold;text-align:center;text-anchor:middle;fill:#000000;fill-opacity:1"
id="tspan4969">memory-mapped</tspan><tspan
sodipodi:role="line"
x="565.16724"
y="217.22726"
style="font-size:10px;font-weight:bold;text-align:center;text-anchor:middle;fill:#000000;fill-opacity:1"
id="tspan4971">peripherals</tspan></text>
</g>
</svg>
hdl/elma_i2c/doc/i2c_slave/i2c_slave.tex
View file @ 861d6e9b
......@@ -10,6 +10,8 @@
\usepackage{color}
\usepackage{longtable}
% Header and footer customization
\usepackage{fancyhdr}
\pagestyle{fancy}
......@@ -39,7 +41,7 @@
\hline
\multicolumn{1}{c}{\textbf{Date}} & \multicolumn{1}{c}{\textbf{Version}} & \multicolumn{1}{c}{\textbf{Change}} \\
\hline
26-06-2013 & 1.00 & First version \\
26-06-2013 & 0.01 & First draft \\
\hline
\end{tabular}
}
......@@ -87,77 +89,20 @@ of the bits. The status of the module can be obtained via dedicated ports.
The main features of the \textit{i2c\_slave} module are:
\begin{itemize}
\item simple operation
\begin{itemize}
\item passive until addressed by master
\item read transfers -- presents the user with the received byte at specific port
\item write transfer -- sends the byte at input port to the master
\item communication status can be checked via dedicated port
\end{itemize}
\item 7-bit addressing
\item standard (100~kHz) or fast (400~kHz) modes supported
\item no clock strething, all information provided by the module should be handled
\item standard (100~kHz) and fast (400~kHz) modes supported
\item no clock stretching, all information provided by the module should be handled
externally within the time span of an I$^2$C bit transfer
\item architecture-independent, can be used with various FPGA types or ASICs
\end{itemize}
%==============================================================================
% SEC: I2C bus
%==============================================================================
\section{I$^2$C Bus Protocol}
The I$^2$C bus protocol is a two-wire protocol defined by Philips/NXP. The original
specification \cite{i2c-spec} defines all aspects of the protocol, from hardware
connections on the bus, to bit- and byte-level data transfers and electrical
characteristics of the bus. A summary about the widely-used protocol is given here.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bus}}
\caption{I$^2$C bus topology}
\label{fig:i2c-bus}
\end{figure}
Devices on the I$^2$C bus are connected together via two pins on the bus: the SCL
(serial clock) and SDA (serial data) pins. I$^2$C masters drive the SCL line to send or
receive bits on the SDA line. Both the SCL and SDA lines on an I$^2$C device are open-collector
pins; as Figure~\ref{fig:i2c-bus} shows, one pull-up resistor on the bus connects the line to
VCC and I$^2$C devices connect the SCL and SDA lines to ground when they drive the lines.
In this way, a device can set a logic low level on the bus by driving the pin and a logic
high level by releasing the pin.
A typical I$^2$C bit-level transfer (Figure~\ref{fig:i2c-bitlevel}) follows the following sequence:
\begin{itemize}
\item master sends a start condition, driving the SDA line low while the SCL line is high
\item master issues a series of SCL pulses to a slave to read or write bits;
the SDA line must be stable for the duration of SCL high pulse for the bit to be properly
transferred
\item master sends a stop condition by releasing the SDA line while SCL line is high,
or a repeated start (similar to start) condition if it wants to continue data transfer
\end{itemize}
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bitlevel}}
\caption{Bit-level transfers on the I$^2$C bus}
\label{fig:i2c-bitlevel}
\end{figure}
Data are transferred on the bus in bytes, one bit at a time starting with the most significant bit.
After each sent byte, the other communicating party ACKs~('0') or NACKs~('1') the transfer on a
9$^{th}$ SCL cycle. Any number of bytes can be sent during a transfer, the master decides when data
transfer should stop by sending the stop condition. The folowing steps comprise a complete I$^2$C
data transfer (Figure~\ref{fig:i2c-transf}):
\begin{itemize}
\item master sends start condition
\item master sends slave address (7 bits of address + one R/W bit)
\item if a slave with this address exists, it ACKs ('0') the master
\item based on the R/W bit ('0' for read from slave, '1' for write to slave), the master either
reads or writes a byte bit by bit from/to the slave
\item the receiver ACKs ('0') or NACKs ('1') the byte on the ninth SCL cycle
\item any number of bytes may be sent, each followed by an ACK or NACK from the receiver
\item \textbf{optional:} the master may (or may not) reverse data transfer by issuing a repeated start and sending the
slave address with the R/W bit flipped
\item \textbf{optional:} any number of bytes may be sent, each followed by an ACK or NACK from the receiver
\item the master ends data transfer by sending the stop condition
\end{itemize}
\begin{figure}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-transf}}
\caption{Bytes transferred on the I$^2$C bus}
\label{fig:i2c-transf}
\end{figure}
%==============================================================================
% SEC: Instantiation
%==============================================================================
......@@ -238,9 +183,74 @@ regarding the various statuses.
}
\end{table}
%==============================================================================
% SEC: I2C bus
%==============================================================================
\section{I$^2$C Bus Protocol}
The I$^2$C bus protocol is a two-wire protocol defined by Philips/NXP. The original
specification \cite{i2c-spec} defines all aspects of the protocol, from hardware
connections on the bus, to bit- and byte-level data transfers and electrical
characteristics of the bus. A summary of the protocol is given here.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bus}}
\caption{I$^2$C bus topology}
\label{fig:i2c-bus}
\end{figure}
Devices on the I$^2$C bus are connected together via two pins on the bus: the SCL
(serial clock) and SDA (serial data) pins. I$^2$C masters drive the SCL line to send or
receive bits on the SDA line. Both the SCL and SDA lines on an I$^2$C device are open-collector
pins; as Figure~\ref{fig:i2c-bus} shows, one pull-up resistor on the bus connects the line to
VCC and I$^2$C devices connect the SCL and SDA lines to ground when they drive the lines.
In this way, a device can set a logic low level on the bus by driving the pin and a logic
high level by releasing the pin.
A typical I$^2$C bit-level transfer (Figure~\ref{fig:i2c-bitlevel}) follows the following sequence:
\begin{itemize}
\item master sends a start condition, driving the SDA line low while the SCL line is high
\item master issues a series of SCL pulses to a slave to read or write bits;
the SDA line must be stable for the duration of SCL high pulse for the bit to be properly
transferred
\item master sends a stop condition by releasing the SDA line while SCL line is high,
or a repeated start (similar to start) condition if it wants to continue data transfer
\end{itemize}
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/i2c-bitlevel}}
\caption{Bit-level transfers on the I$^2$C bus}
\label{fig:i2c-bitlevel}
\end{figure}
Data are transferred on the bus in bytes, one bit at a time starting with the most significant bit.
After each sent byte, the other communicating party ACKs~('0') or NACKs~('1') the transfer on a
9$^{th}$ SCL cycle. Any number of bytes can be sent during a transfer, the master decides when data
transfer should stop by sending the stop condition. The folowing steps comprise a complete I$^2$C
data transfer (Figure~\ref{fig:i2c-transf}):
\begin{itemize}
\item master sends start condition
\item master sends slave address (7 bits of address + one R/W bit)
\item if a slave with this address exists, it ACKs ('0') the master
\item based on the R/W bit ('0' for read from slave, '1' for write to slave), the master either
reads or writes a byte bit by bit from/to the slave
\item the receiver ACKs ('0') or NACKs ('1') the byte on the ninth SCL cycle
\item any number of bytes may be sent, each followed by an ACK or NACK from the receiver
\item \textbf{optional:} the master may (or may not) reverse data transfer by issuing a repeated start and sending the
slave address with the R/W bit flipped
\item \textbf{optional:} any number of bytes may be sent, each followed by an ACK or NACK from the receiver
\item the master ends data transfer by sending the stop condition
\end{itemize}
\begin{figure}
\centerline{\includegraphics[width=\textwidth]{fig/i2c-transf}}
\caption{Bytes transferred on the I$^2$C bus}
\label{fig:i2c-transf}
\end{figure}
%==============================================================================
% SEC: Operation
%==============================================================================
\pagebreak
\section{Operation}
\label{sec:oper}
......@@ -293,7 +303,7 @@ the status signals a successful read ("10"). The received byte should be read fr
\textit{ack\_n\_i} pin. The \textit{i2c\_slave} module does not implement clock stretching,
so the \textit{ack\_n\_i} pin should be set before the SCL line goes high.
Following are the steps that should be performed to read one or more bytes sent by the master:
The steps below should be followed when reading one or more bytes sent by the master:
\begin{enumerate}
\item Wait for \textit{done\_p\_o} to go high, signaling the I$^2$C address of the slave
......@@ -318,7 +328,7 @@ successfully sent, the \textit{done\_p\_o} is high for one clock cycle and the \
port has the value "11", signaling the slave has successfully sent a byte and is
awaiting the loading of another byte.
Below are the steps which should be followed to write one or more bytes to a master:
The steps below should be followed when writing one or more bytes to a master:
\begin{enumerate}
\item Wait for \textit{done\_p\_o} to go high, signaling the I$^2$C address of the slave
......@@ -337,6 +347,7 @@ Below are the steps which should be followed to write one or more bytes to a mas
%==============================================================================
% SEC: Implementation
%==============================================================================
\pagebreak
\section{Implementation}
\label{sec:implem}
......@@ -358,15 +369,23 @@ are loaded and when they shift, and acknowledging to the address and bytes sent
master. Table~\ref{tbl:fsm} lists the states of the FSM and the operations performed
in each state.
\begin{table}[h]
\begin{longtable}{l p{.7\textwidth}}
\caption{The states of the \textit{i2c\_slave} FSM}
\label{tbl:fsm}
\centerline
{
\begin{tabular}{l p{.7\textwidth}}
\label{tbl:fsm} \\
\hline
\multicolumn{1}{c}{\textbf{State}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
\endfirsthead
\hline
\multicolumn{1}{c}{\textbf{State}} & \multicolumn{1}{c}{\textbf{Description}} \\
\hline
\endhead
\hline
\endfoot
\textit{IDLE} & Idle state, FSM default state after reset and the state returned to after
reception of a stop condition. \\
\textit{STA} & State reached after a start condition is received. On the falling edge
......@@ -392,10 +411,48 @@ in each state.
eight bits have been shifted out, \textit{done\_p\_o} is set.\\
\textit{WR\_ACK} & Read ACK bit sent by master. If '0', go back to \textit{WR} state, otherwise
go to \textit{IDLE} state. \\
\hline
\end{tabular}
}
\end{table}
\end{longtable}
%\pagebreak
%\begin{table}[h]
% \caption{The states of the \textit{i2c\_slave} FSM}
% \label{tbl:fsm}
% \centerline
% {
% \begin{tabular}{l p{.7\textwidth}}
% \hline
% \multicolumn{1}{c}{\textbf{State}} & \multicolumn{1}{c}{\textbf{Description}} \\
% \hline
% \textit{IDLE} & Idle state, FSM default state after reset and the state returned to after
% reception of a stop condition. \\
% \textit{STA} & State reached after a start condition is received. On the falling edge
% of SCL, the FSM transitions to \textit{ADDR} state. \\
% \textit{ADDR} & Shift in 7 address bits and R/W bit and go to \textit{ADDR\_ACK}
% state. Each bit is shifted in on the falling edge of SCL. If the
% received address matches, \textit{op\_o} and \textit{done\_p\_o} are set. \\
% \textit{ADDR\_ACK} & Check received address and send the ACK value at \textit{ack\_n\_i} if
% the address corresponds to \textit{i2c\_addr\_i}. If the R/W bit is high,
% go to \textit{RD} state, otherwise go to \textit{WR\_LOAD\_TXSR} state.
% If received address does not match, NACK and go to \textit{IDLE}
% state. \\
% \textit{RD} & Shift in eight bits sent by master and go to \textit{RD\_ACK} state. Each bit
% is shifted in on the falling edge of SCL. When eight bits have been shifted in,
% set \textit{done\_p\_o}. \\
% \textit{RD\_ACK} & Read \textit{ack\_n\_i} and forward it to \textit{sda\_o} (ACK/NACK
% from external controller). If \textit{ack\_n\_i} is '0', then go back to
% \textit{RD} state, else to \textit{IDLE} state. \\
% \textit{WR\_LOAD\_TXSR} & Load TX shift register with data at \textit{tx\_byte\_i} input
% and go to \textit{WR} state. \\
% \textit{WR} & Shift out the eight bits of the TXSR starting with MSB and go to
% \textit{WR\_ACK} state. TXSR shifts left on falling edge of SCL. When
% eight bits have been shifted out, \textit{done\_p\_o} is set.\\
% \textit{WR\_ACK} & Read ACK bit sent by master. If '0', go back to \textit{WR} state, otherwise
% go to \textit{IDLE} state. \\
% \hline
% \end{tabular}
% }
%\end{table}
%==============================================================================
% Bibliography
......
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