Commit 55aca570 authored by Theodor-Adrian Stana's avatar Theodor-Adrian Stana

Updated vme64x_i2c doc - almost done

Also started making changes to release top file
following discussion with Erik.
parent b24b0a20
......@@ -72,34 +72,35 @@
</files>
<transforms xmlns="http://www.xilinx.com/XMLSchema">
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_copyInitialToXSTAbstractSynthesis" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_copyInitialToXSTAbstractSynthesis" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_schematicsToHdl" xil_pn:prop_ck="3482918740615751616" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_schematicsToHdl" xil_pn:prop_ck="3482918740615751616" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_regenerateCores" xil_pn:prop_ck="-1032337062829449789" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_regenerateCores" xil_pn:prop_ck="-1032337062829449789" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_SubProjectAbstractToPreProxy" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_SubProjectAbstractToPreProxy" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_xawsTohdl" xil_pn:prop_ck="6739244360423696002" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_xawsTohdl" xil_pn:prop_ck="6739244360423696002" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_SubProjectPreToStructuralProxy" xil_pn:prop_ck="-3972139311098429560" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_SubProjectPreToStructuralProxy" xil_pn:prop_ck="-3972139311098429560" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926617" xil_pn:name="TRAN_platgen" xil_pn:prop_ck="-5613713180460514355" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447111" xil_pn:name="TRAN_platgen" xil_pn:prop_ck="-5613713180460514355" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926637" xil_pn:in_ck="1856640128136744979" xil_pn:name="TRANEXT_xstsynthesize_spartan6" xil_pn:prop_ck="-5659100974288834190" xil_pn:start_ts="1369926617">
<transform xil_pn:end_ts="1370447129" xil_pn:in_ck="1856640128136744979" xil_pn:name="TRANEXT_xstsynthesize_spartan6" xil_pn:prop_ck="-5659100974288834190" xil_pn:start_ts="1370447111">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="WarningsGenerated"/>
<status xil_pn:value="ReadyToRun"/>
......@@ -117,11 +118,11 @@
<outfile xil_pn:name="webtalk_pn.xml"/>
<outfile xil_pn:name="xst"/>
</transform>
<transform xil_pn:end_ts="1369926637" xil_pn:in_ck="9180755367508499589" xil_pn:name="TRAN_compileBCD2" xil_pn:prop_ck="1934330619683713069" xil_pn:start_ts="1369926637">
<transform xil_pn:end_ts="1370447129" xil_pn:in_ck="9180755367508499589" xil_pn:name="TRAN_compileBCD2" xil_pn:prop_ck="1934330619683713069" xil_pn:start_ts="1370447129">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
</transform>
<transform xil_pn:end_ts="1369926648" xil_pn:in_ck="-3184428132143472969" xil_pn:name="TRANEXT_ngdbuild_FPGA" xil_pn:prop_ck="7619738475395271108" xil_pn:start_ts="1369926637">
<transform xil_pn:end_ts="1370447139" xil_pn:in_ck="-3184428132143472969" xil_pn:name="TRANEXT_ngdbuild_FPGA" xil_pn:prop_ck="7619738475395271108" xil_pn:start_ts="1370447129">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
<outfile xil_pn:name="_ngo"/>
......@@ -130,7 +131,7 @@
<outfile xil_pn:name="conv_ttl_blo_v2.ngd"/>
<outfile xil_pn:name="conv_ttl_blo_v2_ngdbuild.xrpt"/>
</transform>
<transform xil_pn:end_ts="1369926688" xil_pn:in_ck="-3184428132143472968" xil_pn:name="TRANEXT_map_spartan6" xil_pn:prop_ck="2503688751298223818" xil_pn:start_ts="1369926648">
<transform xil_pn:end_ts="1370447178" xil_pn:in_ck="-3184428132143472968" xil_pn:name="TRANEXT_map_spartan6" xil_pn:prop_ck="2503688751298223818" xil_pn:start_ts="1370447139">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="ReadyToRun"/>
<outfile xil_pn:name="_xmsgs/map.xmsgs"/>
......@@ -143,8 +144,9 @@
<outfile xil_pn:name="conv_ttl_blo_v2_summary.xml"/>
<outfile xil_pn:name="conv_ttl_blo_v2_usage.xml"/>
</transform>
<transform xil_pn:end_ts="1369926727" xil_pn:in_ck="-7407895592276768303" xil_pn:name="TRANEXT_par_spartan6" xil_pn:prop_ck="3214117756270688487" xil_pn:start_ts="1369926688">
<transform xil_pn:end_ts="1370447216" xil_pn:in_ck="-7407895592276768303" xil_pn:name="TRANEXT_par_spartan6" xil_pn:prop_ck="3214117756270688487" xil_pn:start_ts="1370447178">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="WarningsGenerated"/>
<status xil_pn:value="ReadyToRun"/>
<outfile xil_pn:name="_xmsgs/par.xmsgs"/>
<outfile xil_pn:name="conv_ttl_blo_v2.ncd"/>
......@@ -157,7 +159,7 @@
<outfile xil_pn:name="conv_ttl_blo_v2_pad.txt"/>
<outfile xil_pn:name="conv_ttl_blo_v2_par.xrpt"/>
</transform>
<transform xil_pn:end_ts="1369926749" xil_pn:in_ck="-7071212854459536945" xil_pn:name="TRANEXT_bitFile_spartan6" xil_pn:prop_ck="396117104113915555" xil_pn:start_ts="1369926727">
<transform xil_pn:end_ts="1370447238" xil_pn:in_ck="-7071212854459536945" xil_pn:name="TRANEXT_bitFile_spartan6" xil_pn:prop_ck="396117104113915555" xil_pn:start_ts="1370447216">
<status xil_pn:value="SuccessfullyRun"/>
<status xil_pn:value="WarningsGenerated"/>
<status xil_pn:value="ReadyToRun"/>
......@@ -169,7 +171,7 @@
<outfile xil_pn:name="webtalk.log"/>
<outfile xil_pn:name="webtalk_pn.xml"/>
</transform>
<transform xil_pn:end_ts="1369926727" xil_pn:in_ck="-3184428132143473100" xil_pn:name="TRAN_postRouteTrce" xil_pn:prop_ck="445577401284416185" xil_pn:start_ts="1369926716">
<transform xil_pn:end_ts="1370447216" xil_pn:in_ck="-3184428132143473100" xil_pn:name="TRAN_postRouteTrce" xil_pn:prop_ck="445577401284416185" xil_pn:start_ts="1370447205">
<status xil_pn:value="FailedRun"/>
<status xil_pn:value="ReadyToRun"/>
<outfile xil_pn:name="_xmsgs/trce.xmsgs"/>
......
......@@ -559,33 +559,9 @@ begin
(others => '0');
--============================================================================
-- Inverted TTL pulse generation logic
-- General-purpose INV TTL outputs
--============================================================================
-- Trigger for pulse generators
trig_inv <= not inv_in_n_i when (ttl_switch_n_i = '0') else
inv_in_n_i;
-- Instantiate the necessary number of pulse generator components
gen_inv_pulse_generators : for i in 1 to g_nr_inv_chan generate
cmp_inv_pulse_gen : ctb_pulse_gen
generic map
(
g_pulse_width => 125,
g_glitch_filt_len => 4
)
port map
(
clk_i => clk125,
rst_n_i => rst_n,
pulse_type_i => extra_switch_n_i(1),
en_i => '1',
trig_i => trig_inv(i),
pulse_o => inv_outputs(i)
);
end generate gen_inv_pulse_generators;
-- Output assignment
inv_out_o <= not inv_outputs;
inv_out_o <= inv_in_n_i;
-- cmp_tmp_pulse_gen : ctb_pulse_gen_gp
-- generic map
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -47,7 +47,7 @@ CERN, BE-CO-HT \\
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.
Wishbone slave device.
%==============================================================================
% SEC: Protocol
......@@ -55,7 +55,38 @@ Wishbone slave device of choice.
\section{ELMA I$^2$C Protocol}
\label{sec:elma-i2c}
\textcolor{red}{WRITE THIS THING}
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.
Fig.~\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
I$^2$C slave address and the read/write bit cleared, indicating an
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).
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/sysmon-wr}}
\caption{SysMon write operation}
\label{fig:sysmon-wr}
\end{figure}
A read transfer (Fig.~\ref{fig:sysmon-rd})from a VME board is similar to
the write transfer. The differences lie in the retransmission of the
control byte after the register address, this time with the read/write
bit set, to indicate an I$^2$C read. Following the ACK from the slave,
the transfer direction changes and the SysMon will read the four data
bytes sent by the VME board. As with the write transfer, the data bytes
are sent by the VME board in big-endian order.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/sysmon-rd}}
\caption{SysMon read operation}
\label{fig:sysmon-rd}
\end{figure}
%==============================================================================
% SEC: Implem
......@@ -65,15 +96,39 @@ Wishbone slave device of choice.
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.
the \textit{i2c\_slave} module \textcolor{red}{REFERENCE?} are used as controls
for an eight-state finite state machine (FSM), a simplified version of which
is shown in Fig.~\ref{fig:fsm}. Table~\ref{tbl:fsm} also lists the states of
the state machine.
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth, keepaspectratio]{fig/fsm}}
\caption{Main FSM of \textit{vme64x\_i2c} module}
\label{fig:fsm}
\end{figure}
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/sysmon-wr-fsm}}
\caption{FSM states when the SysMon writes to the \textit{vme64x\_i2c}}
\label{fig:sysmon-wr-fsm}
\end{figure}
\begin{figure}[h]
\centerline{\includegraphics[width=\textwidth]{fig/sysmon-rd-fsm}}
\caption{FSM states when the SysMon reads from the \textit{vme64x\_i2c}}
\label{fig:sysmon-rd-fsm}
\end{figure}
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. It should be noted that where the
SysMon appears in the state names, it indicates what the SysMon action is. For example, if the state
of the FSM is \textit{ST\_SYSMON\_WR}, this means the SysMon is writing and the \textit{vme64x\_i2c}
is reading.
\begin{table}[h]
\caption{\textit{vme64x\_i2c} state machine}
\label{tbl:state-mach}
\label{tbl:fsm}
\centerline
{
\begin{tabular}{l p{.65\textwidth}}
......@@ -92,8 +147,8 @@ in the \textit{ST\_IDLE} state), the FSM advances to the next state.
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) \\
(SysMon is reading from \textit{vme64x\_i2c}), otherwise continue shifting
in bytes (SysMon writing to \textit{vme64x\_i2c}) \\
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
......@@ -107,29 +162,30 @@ in the \textit{ST\_IDLE} state), the FSM advances to the next state.
}
\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\\
To better understand how the FSM operates, Figures \ref{fig:sysmon-wr-fsm} and
\ref{fig:sysmon-rd-fsm} can be consulted, where the state of the FSM is shown
during reads and writes from the SysMon.
When reading from the SysMon (Fig.~\ref{fig:sysmon-wr-fsm}), 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 (Fig.~\ref{fig:sysmon-rd-fsm}), 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
%==============================================================================
......
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