1125 Kasli-SoC #70
173
1124.tex
@ -1,4 +1,5 @@
|
||||
\include{preamble.tex}
|
||||
\input{preamble.tex}
|
||||
\input{shared/coredevice.tex}
|
||||
\graphicspath{{images/1124}{images}}
|
||||
|
||||
\title{1124 Carrier Kasli 2.0}
|
||||
@ -13,28 +14,28 @@
|
||||
\section{Features}
|
||||
|
||||
\begin{itemize}
|
||||
\item{4 SFP 6Gb/s slots for Ethernet and DRTIO}
|
||||
\item{12 EEM ports for daughtercards}
|
||||
\item{4 MMCX clock outputs}
|
||||
\item{Xilinx Artix-7 FPGA core}
|
||||
\item{DDR3 SDRAM}
|
||||
\item{4 SFP 6Gb/s slots for Ethernet \& DRTIO at 2.5Gb/s}
|
||||
\item{12 EEM ports for daughtercards}
|
||||
\item{4 MMCX clock outputs}
|
||||
\item{Xilinx Artix-7 FPGA core}
|
||||
\item{DDR3 SDRAM}
|
||||
\end{itemize}
|
||||
|
||||
\section{Applications}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Run ARTIQ kernels}
|
||||
\item{Communicate with the host}
|
||||
\item{Control other Sinara EEM cards}
|
||||
\item{Distributed Real-Time I/O}
|
||||
\item{Run ARTIQ kernels}
|
||||
\item{Communicate with the host}
|
||||
\item{Control other Sinara EEM cards}
|
||||
\item{Distributed Real-Time I/O}
|
||||
\end{itemize}
|
||||
|
||||
\section{General Description}
|
||||
The 1124 Kasli 2.0 Carrier card is an 8hp EEM module, designed to run ARTIQ kernels sent from a host machine over the network. It supports up to 12 EEM connections to other EEM cards in the ARTIQ-Sinara family and up four SFP connections, used for comunications with other carriers and/or Ethernet.
|
||||
The 1124 Kasli 2.0 Carrier card is an 8hp EEM module, designed to run ARTIQ kernels sent from a host machine over the network. It supports up to 12 EEM connections to other EEM cards in the ARTIQ/Sinara family and up four SFP connections, used for comunications with other carriers and/or Ethernet.
|
||||
|
||||
Real-time control of EEM daughtercards is implemented using the ARTIQ RTIO system. 1ns temporal resolution can be achieved for TTL events.
|
||||
Real-time control of EEM daughtercards is implemented using the ARTIQ RTIO system. 1ns temporal resolution can be achieved for TTL events.
|
||||
|
||||
4 SFP 6Gb/s slots are provided. One may be used for Ethernet, which supports communication with a host machine. Remaining slots can be used by the ARTIQ Distributed Real-Time Input/Output (DRTIO) system, which allows for the use of additional core devices (e.g. Kasli 2.0, Kasli-SoC) as satellite cards, capable of running subkernels or distributing commands from the \mbox{DRTIO} master.
|
||||
4 SFP 6Gb/s slots are provided. One may be used for Ethernet, which supports communication with a host machine. Remaining slots can be used by the ARTIQ Distributed Real-Time Input/Output (DRTIO) system, which allows for the use of additional core devices (e.g. Kasli 2.0, Kasli-SoC) as satellite cards, capable of running subkernels or distributing commands from the \mbox{DRTIO} master.
|
||||
|
||||
% Switch to next column
|
||||
\vfill\break
|
||||
@ -163,142 +164,74 @@ Real-time control of EEM daughtercards is implemented using the ARTIQ RTIO syste
|
||||
\caption{Kasli 2.0 front panel}
|
||||
\end{figure}
|
||||
|
||||
% For wide tables, a single column layout is better. It can be switched
|
||||
% page-by-page.
|
||||
% END PAGE ONE (for wide pages a single-column layout is preferable)
|
||||
|
||||
\onecolumn
|
||||
|
||||
\sourcesection{Kasli 2.0}{https://github.com/sinara-hw/Kasli}
|
||||
|
||||
\section{Electrical Specifications}
|
||||
External clock parameters are derived based on the internal termination specified in
|
||||
UG471\footnote{\label{ug471}\url{https://docs.xilinx.com/v/u/en-US/ug471\_7Series\_SelectIO}}
|
||||
and the voltage range specified in
|
||||
DS181\footnote{\label{ds181}\url{https://docs.xilinx.com/v/u/en-US/ds181\_Artix\_7\_Data\_Sheet}}. These figures account for the insertion loss of the RF transformer (TC2-1TX+\footnote{\label{rf_trans}\url{https://www.minicircuits.com/pdfs/TC2-1TX+.pdf}}).
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{threeparttable}
|
||||
\caption{Recommended Operating Conditions}
|
||||
\begin{tabularx}{0.85\textwidth}{l | c c c | c | X}
|
||||
\thickhline
|
||||
\textbf{Parameter} & \textbf{Min.} & \textbf{Typ.} & \textbf{Max.} &
|
||||
\textbf{Unit} & \textbf{Conditions} \\
|
||||
\hline
|
||||
Clock input & & & & &\\
|
||||
\hspace{3mm} Input frequency & & 125 & & MHz & Si5324 synthesizer bypassed \\
|
||||
\cline{2-6}
|
||||
% 100R termination & 100/350/600 mV differential input after the transformer.
|
||||
& \multicolumn{3} {c|}{10/100/125} & MHz & RTIO clock synthesized from input \\
|
||||
\cline{2-6}
|
||||
\hspace{3mm} Power & -9 & 1.5 & 5.5 & dBm & \\
|
||||
\hline
|
||||
Power supply rating & \multicolumn{4}{c|}{12V, 5A} & \\
|
||||
\thickhline
|
||||
\end{tabularx}
|
||||
\end{threeparttable}
|
||||
\end{table}
|
||||
|
||||
Power is to be supplied through the barrel connector in the front panel, size 5.5 mm OD, 2.5 mm ID, and is passed on to daughtercards through the EEM connections. Locking barrel connectors are supported.
|
||||
External clock parameters are derived based on the internal termination specified in
|
||||
UG471\footnote{\label{ug471}\url{https://docs.amd.com/v/u/en-US/ug471_7Series_SelectIO}}
|
||||
and the voltage range specified in
|
||||
DS181\footnote{\label{ds181}\url{https://docs.xilinx.com/v/u/en-US/ds181\_Artix\_7\_Data\_Sheet}}. These figures account for the insertion loss of the RF transformer (TC2-1TX+\footnote{\label{rf_trans}\url{https://www.minicircuits.com/pdfs/TC2-1TX+.pdf}}).
|
||||
|
||||
\spectable
|
||||
|
||||
\section{FPGA}
|
||||
|
||||
Kasli 2.0 features an XC7A100T-3FGG484E Xilinx Artix-7 FPGA to facilitate reconfigurable high-speed real-time control of inputs and outputs. Most commonly, this FPGA is flashed with binaries compiled from the ARTIQ (Advanced Real-Time Infrastructure for Quantum physics) control system, which equips the carrier board with specialized gateware for handling other Sinara EEMs and an on-FPGA CPU for running ARTIQ experiment \mbox{kernels}.
|
||||
Kasli 2.0 features an XC7A100T-3FGG484E Xilinx Artix-7 FPGA to facilitate reconfigurable high-speed real-time control of inputs and outputs. Most commonly, this FPGA is flashed with binaries compiled from the ARTIQ (Advanced Real-Time Infrastructure for Quantum physics) control system, which equips the carrier board with specialized gateware for handling other Sinara EEMs and an on-FPGA CPU for running ARTIQ experiment \mbox{kernels}.
|
||||
|
||||
ARTIQ is open-source and can be found in the repository \url{https://github.com/m-labs/artiq}. Orders of Sinara hardware are normally accompanied with precompiled binaries. Long-term support for ARTIQ systems can also be purchased.
|
||||
A micro-USB located on the front panel is equipped for JTAG, I2C, and UART serial output. The serial interface runs at 115200bps 8-N-1.
|
||||
|
||||
A micro-USB located on the front panel is equipped for JTAG, I2C, and UART serial output. The serial interface runs at 115200bps 8-N-1.
|
||||
\artiqsection
|
||||
|
||||
\subsection{Note on distributed RTIO (DRTIO)}
|
||||
|
||||
DRTIO is the time and data transfer system that allows ARTIQ RTIO channels to be distributed among several core device carrier boards, synchronized and controlled by a central core device. The system itself is more fully described in the ARTIQ documentation\footnote{\label{manual-drtio}\url{https://m-labs.hk/artiq/manual/drtio.html}}. With ARTIQ firmware/gateware, supported core devices, including Kasli 2.0, can take one of three roles:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Master} \\
|
||||
The DRTIO master is unique in a DRTIO system. It requires a direct network connection to the host machine. It may make downstream connections to satellites. It controls its own local RTIO channels and the downstream DRTIO satellite(s).
|
||||
\item \textbf{Satellite} \\
|
||||
Any other core devices in a DRTIO system are DRTIO satellites. They require an upstream connection to one other core device, master or satellite, through which communications will ultimately be chained to the master. They may make further downstream connections to other satellites. They may control RTIO channels through subkernels or simply pass on communications from the master.
|
||||
\item \textbf{Standalone}\\
|
||||
When run in a non-distributed ARTIQ configuration, with a single central core device but no satellites, that core device is instead known as standalone.
|
||||
\end{enumerate}
|
||||
\noteondrtio{Kasli 2.0}
|
||||
|
||||
\section{Communication Interfaces}
|
||||
architeuthis marked this conversation as resolved
Outdated
|
||||
|
||||
Communication between devices is implemented using 1000Base-T small form-factor pluggable (SFP) interfaces. Four are available on the Kasli 2.0. Appropriate SFP transceivers must be plugged inside the corresponding SFP cages. Each SFP connector possesses an indicator LED.
|
||||
Communication between devices is implemented using 1000Base-T small form-factor pluggable (SFP) interfaces. Four are available on the Kasli 2.0. Appropriate SFP transceivers must be plugged inside the corresponding SFP cages. Each SFP connector possesses an indicator LED.
|
||||
|
||||
\subsection{Upstream connection}
|
||||
Transceiver maximum speed is 6.6 Gb/s\footnote{\url{https://www.amd.com/en/products/adaptive-socs-and-fpgas/technologies/high-speed-serial.html}}. DRTIO is normally run at 2.5 Gb/s with 8b10b encoding.
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
Power bricks we sell are 12V 5.43A already. And even that can be not enough if there's enough power hungry peripherals... that figure probably should be revisited at some point. Power bricks we sell are 12V 5.43A already. And even that can be not enough if there's enough power hungry peripherals... that figure probably should be revisited at some point.
architeuthis
commented
I.e. "12V, 5.43A" better here ...? I.e. "12V, 5.43A" better here ...?
mwojcik
commented
Actual value would be the theoretical maximum supported by the PCB (with maximum power draw from all the peripherals), and we haven't really calculated it. Nor that it matters. I think it's OK to leave it as-is. Actual value would be the theoretical maximum supported by the PCB (with maximum power draw from all the peripherals), and we haven't really calculated it. Nor that it matters.
I think it's OK to leave it as-is.
|
||||
|
||||
A Kasli 2.0 board must acquire an upstream connection through the \texttt{SFP0} slot.
|
||||
\subsection{Upstream connection}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Standalone/Master} \\
|
||||
An Ethernet-capable SFP transceiver should be inserted into the \texttt{SFP0} slot. Typically, a 10000Base-X RJ45 SFP module is used, with an network-connected Ethernet cable attached to the module.
|
||||
\item \textbf{Satellite} \\
|
||||
The \texttt{SFP0} port should be connected to one of the free SFP slots on an upstream core device, using a cable connection with SFP transceivers.
|
||||
\end{itemize}
|
||||
A Kasli 2.0 board must acquire an upstream connection through the \texttt{SFP0} slot.
|
||||
|
||||
\subsection{Downstream connection}
|
||||
Kasli 2.0 supports up to 3 DRTIO satellite connections per device. Any of the 3 downstream SFP ports (i.e. \texttt{SFP1}, \texttt{SFP2}, \texttt{SFP3}) may be used.
|
||||
\begin{itemize}
|
||||
\item \textbf{Standalone/Master} \\
|
||||
An Ethernet-capable SFP transceiver should be inserted into the \texttt{SFP0} slot. Typically, a 10000Base-X RJ45 SFP module is used, with an network-connected Ethernet cable attached to the module.
|
||||
\item \textbf{Satellite} \\
|
||||
The \texttt{SFP0} port should be connected to one of the free SFP slots on an upstream core device, using a cable or fibre connection with SFP transceivers.
|
||||
\end{itemize}
|
||||
|
||||
\section{Clock Routing}
|
||||
\subsection{Standalone/Master}
|
||||
The RTIO clock is typically synthesized by the Si5324 clock multiplier and distributed by the ADCLK948 clock fanout buffer to both the FPGA and the MMCX connectors. Alternatively, an external reference can be supplied through the front panel SMA connector. It is then buffered in the FPGA and sent to the Si5324 for clock synthesis. Kasli 2.0 supports a set of RTIO clock options:
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\begin{tabular}{|c|c|c|}
|
||||
\hline
|
||||
RTIO frequency & Configuration & Clock generation \\ \hline
|
||||
100 MHz & \texttt{int\char`_100} & internal crystal oscillator using PLL, 100 MHz output \\ \hline
|
||||
\multirow{4}{*}{125 MHz} & \texttt{int\char`_125} & internal crystal oscillator using PLL, 125 MHz output (default) \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_10to125} & external 10 MHz reference using PLL, 125 MHz output \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_100to125} & external 100 MHz reference using PLL, 125 MHz output \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_125to125} & external 125 MHz reference using PLL, 125 MHz output \\ \hline
|
||||
150 MHz & \texttt{int\char`_150} & internal crystal oscillator using PLL, 150 MHz output \\ \hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
\subsection{Downstream connection}
|
||||
Kasli 2.0 supports up to 3 DRTIO satellite connections per device. Any of the 3 downstream SFP ports (i.e. \texttt{SFP1}, \texttt{SFP2}, \texttt{SFP3}) may be used. The destination on port \texttt{SFPn} normally receives the destination number \texttt{n}.
|
||||
|
||||
The clock synthesizer may also be bypassed, using the \texttt{ext0\char`_bypass} option, which will accept a RTIO clock directly supplied to the SMA connector. The resulting signal is then routed to both the RTIO system and downstream satellites.
|
||||
|
||||
Clocking options in a running system should be configured by setting the value of the \texttt{rtio\char`_clock} key to the desired configuration through \texttt{artiq\char`_coremgmt}. For example, a RTIO frequency of 125MHz will be synthesized from an external 10 MHz signal after issuing the following command:
|
||||
|
||||
\begin{minted}{bash}
|
||||
artiq_coremgmt config write -s rtio_clock ext0_synth0_10to125
|
||||
\end{minted}
|
||||
|
||||
and rebooting.
|
||||
|
||||
\subsection{Satellite}
|
||||
The RTIO clock is recovered from the SFP transceiver connected to the upstream device. The resulting signal is then cleaned up by the Si5324 and routed to both the RTIO system and downstream satellites.
|
||||
|
||||
\subsection{WRPLL}
|
||||
|
||||
Kasli 2.0 can be configured to use WRPLL, a clock recovery method making use of White Rabbit's DDMTD (Digital Dual Mixer Time Difference) and the card's Si549 oscillators, both to lock the main RTIO clock and to lock satellite clocks to master.
|
||||
\clockingsection{Kasli 2.0}{FPGA}
|
||||
|
||||
\section{User LEDs}
|
||||
|
||||
Kasli 2.0 supplies three user LEDs for debugging purposes. Two are located on the front panel. The third is located on the PCB itself, beside the SFP cage. An additional ERR LED on the front panel is used by ARTIQ firmware to indicate a runtime panic.
|
||||
Kasli 2.0 supplies three user LEDs for debugging purposes. Two are located on the front panel. The third is located on the PCB itself, beside the SFP cage. An additional ERR LED on the front panel is used by ARTIQ firmware to indicate a runtime panic.
|
||||
|
||||
\newpage
|
||||
\sysdescsection
|
||||
|
||||
\codesection{Kasli 2.0 1124 carrier}
|
||||
An example description file for a system using 1124 Kasli 2.0 as a master core device might begin:
|
||||
|
||||
\subsection{Direct Memory Access (DMA)}
|
||||
Instead of directly emitting RTIO events, sequences of RTIO events can be recorded in advance and stored in the local SDRAM. The event sequence can then be replayed at a specified timestamp. This is of special advantage in cases where RTIO events are too closely placed to be generated as they are executed, as events can be replayed at a higher speed than the on-FPGA CPU alone is capable of.
|
||||
\begin{tcolorbox}[colback=white]
|
||||
\begin{minted}{json}
|
||||
"target": "kasli",
|
||||
"variant": "my_variant",
|
||||
"hw_rev": "v2.0",
|
||||
"base": "master",
|
||||
"peripherals": [ ]
|
||||
\end{minted}
|
||||
\end{tcolorbox}
|
||||
|
||||
The following example records an LED event sequence and replays it twice consecutively using \texttt{CoreDMA}. When run, the LED should blink twice.
|
||||
\coresysdesc
|
||||
|
||||
\inputcolorboxminted{firstline=10,lastline=29}{examples/dma.py}
|
||||
|
||||
Stored waveforms can be referenced and replayed in different kernels, but cannot be retrieved and must be regenerated if the core device is rebooted.
|
||||
|
||||
\newpage
|
||||
|
||||
\subsection{Dataset manipulation with core device cache}
|
||||
Experiments may require values computed or found in previously executed kernels. To avoid invoking an RPC or sacrificing the pre-computation in \texttt{prepare()} stage, data can be stored in the core device cache.
|
||||
|
||||
The following code snippets describe two experiments, in which the data from the first experiment is cached. The data is then retrieved and printed in hexadecimal form in the second experiment.
|
||||
|
||||
\inputcolorboxminted{firstline=9,lastline=16}{examples/cache.py}
|
||||
\inputcolorboxminted{firstline=24,lastline=35}{examples/cache.py}
|
||||
|
||||
Similar to DMA, cached data is no longer retrievable once the core device has been rebooted.
|
||||
\coredevicecode{Kasli 2.0 1124 carrier}
|
||||
|
||||
\ordersection{1124 Carrier Kasli 2.0}
|
||||
|
||||
|
144
1125.tex
Normal file
@ -0,0 +1,144 @@
|
||||
\input{preamble}
|
||||
\input{shared/coredevice}
|
||||
\graphicspath{{images/1125}{images}}
|
||||
|
||||
\title{1125 Carrier Kasli-SoC}
|
||||
\author{M-Labs Limited}
|
||||
\date{December 2024}
|
||||
\revision{Revision 1} % potentially publishable pending whether block diagram is necessary
|
||||
\companylogo{\includegraphics[height=0.73in]{artiq_sinara.pdf}}
|
||||
|
||||
\begin{document}
|
||||
\maketitle
|
||||
|
||||
\section{Features}
|
||||
|
||||
\begin{itemize}
|
||||
\item{RJ45 10/100/1000T Ethernet connector}
|
||||
\item{4 SFP 12Gb/s slots for DRTIO at 2.5Gb/s}
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
The 6Gb/s bugs me even on the kasli datasheet, as the kasli fpga GTP transceiver max speed is around 6Gb/s but the DRTIO are running at 2.5Gb/s with 8b10b encoding. So if we are running this logic of using the max speed of the transceivers, the kasli-soc should be 12.5Gb/s. Though, I am not sure any SFP module support that kind of speed. (see https://www.amd.com/en/products/adaptive-socs-and-fpgas/technologies/high-speed-serial.html for the MGT linerate) The 6Gb/s bugs me even on the kasli datasheet, as the kasli fpga GTP transceiver max speed is around 6Gb/s but the DRTIO are running at 2.5Gb/s with 8b10b encoding. So if we are running this logic of using the max speed of the transceivers, the kasli-soc should be 12.5Gb/s. Though, I am not sure any SFP module support that kind of speed. (see https://www.amd.com/en/products/adaptive-socs-and-fpgas/technologies/high-speed-serial.html for the MGT linerate)
architeuthis
commented
Is having both numbers (current revision) better? Is having both numbers (current revision) better?
sb10q
commented
Yes. Yes.
Also the CoaXpress adapter will use the SFPs at maximum speed on SoC.
|
||||
\item{12 EEM ports for daughtercards}
|
||||
\item{Xilinx Zynq-7000 SoC with Kintex-7 FPGA}
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
The product stack is called "Zynq 7000 Soc" (see https://www.amd.com/en/products/adaptive-socs-and-fpgas/soc/zynq-7000.html) The product stack is called "Zynq 7000 Soc" (see https://www.amd.com/en/products/adaptive-socs-and-fpgas/soc/zynq-7000.html)
|
||||
\item{SD card flash memory}
|
||||
\end{itemize}
|
||||
|
||||
\section{Applications}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Run ARTIQ kernels}
|
||||
\item{Communicate with the host}
|
||||
\item{Control other Sinara EEM cards}
|
||||
\item{Distributed Real-Time I/O}
|
||||
\end{itemize}
|
||||
|
||||
\section{General Description}
|
||||
|
||||
The 1125 Kasli-SoC Carrier card is an 8hp EEM module, designed to run ARTIQ-Zynq kernels sent over the network from a host machine. Kasli-SoC is built around a Xilinx Zynq-7000 SoC, capable of running more complex computations at high speed than its sister card 1124 Kasli 2.0. It supports up to 12 EEM connections to other EEM cards in the ARTIQ-Sinara family and up four SFP connections for comunications with other carriers. A dedicated Ethernet port is used for communications with the host.
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
Zynq-7000 Zynq-7000
|
||||
|
||||
Real-time control of EEM daughtercards is implemented using the ARTIQ RTIO system. 1ns temporal resolution can be achieved for TTL events.
|
||||
|
||||
4 SFP 12Gb/s slots are provided. These can be used by the ARTIQ Distributed Real-Time Input/Output (DRTIO) system, which allows for the use of additional core devices (e.g. Kasli or other Kasli-SoCs) as satellite cards, capable of running subkernels or relaying commands to a larger number of peripherals.
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
Kasli 1.0/1.1 is also supported. I'd put it as Kasli 1.0/1.1 is also supported.
I'd put it as ``e.g. Kasli or another Kasli-SoC`` (technically it's also compatible with kc705/zc706 but most users will not even see these boards)
mwojcik
commented
``distributing commands`` sounds a bit weird too
I assume that's for RTIO - that is, controlling the peripherals - and it's the primary function that should be put first.
and of course yes, it can distribute them (to further satellites) but it also adheres to the commands, but this time I don't know how to put it better
architeuthis
commented
The idea was distributing commands [to the peripherals] as opposed to controlling them directly. Better like so? The idea was distributing commands [to the peripherals] as opposed to controlling them directly. Better like so?
mwojcik
commented
'to the peripherals' clears it up nicely I think. 'to the peripherals' clears it up nicely I think.
|
||||
|
||||
% Switch to next column
|
||||
\vfill\break
|
||||
|
||||
% TODO, possibly: block diagram
|
||||
|
||||
\begin{figure}[hbt!]
|
||||
\centering
|
||||
\includegraphics[height=3in]{photo1125.jpg}
|
||||
\caption{Kasli-SoC card}
|
||||
\includegraphics[angle=90,height=1in]{Kasli-SoC_FP.pdf}
|
||||
\caption{Kasli-SoC front panel}
|
||||
\end{figure}
|
||||
|
||||
% END PAGE ONE (for wide pages a single-column layout is preferable)
|
||||
\onecolumn
|
||||
|
||||
\sourcesection{Kasli-SoC}{https://github.com/sinara-hw/Kasli-SOC/}
|
||||
|
||||
\section{Electrical Specifications}
|
||||
|
||||
External clock parameters are derived based on the internal termination specified in
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
Looking at Kasli 2.0's specs, they're the same for Kasli-SoC. Looking at Kasli 2.0's specs, they're the same for Kasli-SoC.
morgan
commented
The kasli used the "DC and AC Switching Characteristics" instead of product overview datasheet, here's the Zynq-7000 version for that DS191 The kasli used the "DC and AC Switching Characteristics" instead of product overview datasheet, here's the Zynq-7000 version for that [DS191](https://docs.amd.com/v/u/en-US/ds191-XC7Z030-XC7Z045-data-sheet)
|
||||
UG471\footnote{\label{ug471}\url{https://docs.amd.com/v/u/en-US/ug471_7Series_SelectIO}}
|
||||
and the voltage range specified in
|
||||
DS191\footnote{\label{ds191}\url{https://docs.amd.com/v/u/en-US/ds191-XC7Z030-XC7Z045-data-sheet}}. These figures account for the insertion loss of the RF transformer (TC2-1TX+\footnote{\label{rf_trans}\url{https://www.minicircuits.com/pdfs/TC2-1TX+.pdf}}).
|
||||
|
||||
\spectable
|
||||
|
||||
\section{SoC}
|
||||
|
||||
Kasli-SoC features a XC7Z030-3FFG676E Xilinx Zynq-7000 System-on-Chip with a Kintex-7 FGPA and an Cortex-A9 dual-core processor to facilitate high-speed real-time control of inputs and outputs. The use of the SoC allows for more complex computations at higher speed than Kasli 2.0's purely on-FPGA CPU. Usually, the SoC is flashed with firmware and gateware binaries compiled from the ARTIQ (Advanced Real-Time Infrastructure for Quantum physics) control system, which equips the carrier board with the ability to control other Sinara EEMs and run ARTIQ experiment kernels.
|
||||
|
||||
A micro-USB located on the front panel is equipped for JTAG, I2C, and UART serial output. The serial interface runs at 115200bps 8-N-1.
|
||||
|
||||
\artiqsection
|
||||
|
||||
ARTIQ-supported core devices based on Zynq-7000 SoCs, including Kasli-SoC, require firmware and gateware compiled from the ARTIQ-Zynq port, which can be found in the repository \url{https://git.m-labs.hk/M-Labs/artiq-zynq}.
|
||||
|
||||
\noteondrtio{Kasli-SoC}
|
||||
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
Alternatively, there's a Molex connector on the back of the card, to be used with the 1106 EEM AC Power Module. (also applies to Kasli 2.0) Alternatively, there's a Molex connector on the back of the card, to be used with the 1106 EEM AC Power Module. (also applies to Kasli 2.0)
|
||||
\section{Communication Interfaces}
|
||||
|
||||
Communication between core devices is implemented with 1000Base-T small form-factor pluggable (SFP) interfaces. Four are available on 1125 Kasli-SoC. Each SFP connector possesses an indicator LED.
|
||||
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
FYI the exact part number is XC7Z030-3FFG676E FYI the exact part number is XC7Z030-3FFG676E
|
||||
Transceiver maximum speed is 12.5 Gb/s\footnote{\url{https://www.amd.com/en/products/adaptive-socs-and-fpgas/technologies/high-speed-serial.html}}. DRTIO is normally run at 2.5 Gb/s with 8b10b encoding.
|
||||
|
||||
Additionally, a RJ45 10/100/1000T Ethernet port is featured for network connection to a host machine.
|
||||
|
||||
\subsection{Upstream connection}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Standalone/Master} \\
|
||||
A network-connected Ethernet cable should be attached the front panel Ethernet port to enable communication with a host machine.
|
||||
\item \textbf{Satellite} \\
|
||||
Satellites must acquire an upstream connection to another satellite or the master. The \texttt{SFP0} port should be connected to one of the free SFP slots on an upstream core device, using a cable or fibre connection with SFP transceivers.
|
||||
\end{itemize}
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
I don't think we support SFP -> RJ45 on soc, maybe I am wrong I don't think we support SFP -> RJ45 on soc, maybe I am wrong
mwojcik
commented
we don't we don't
|
||||
|
||||
\subsection{Downstream connection}
|
||||
Kasli-SoC supports up to 4 DRTIO satellite connections per device. Any of the 4 downstream SFP ports (i.e. \texttt{SFP0}, \texttt{SFP1}, \texttt{SFP2}, \texttt{SFP3}) may be freely used. Port \texttt{SFPn} normally receives the destination number \texttt{n + 1}.
|
||||
|
||||
\clockingsection{Kasli-SoC}{SoC}
|
||||
|
||||
\newpage
|
||||
|
||||
\section{Configuring Boot Mode}
|
||||
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
cable (direct attach cable) or fiber connection cable (direct attach cable) _or fiber_ connection
architeuthis
commented
Only for SoC or in both sheets? Only for SoC or in both sheets?
mwojcik
commented
both both
|
||||
Kasli-SoC is capable of booting either remotely, over JTAG USB, or directly from the SD card. See the ARTIQ manual for more instructions on how to correctly flash and boot a core device. Boot mode must be configured by flipping physical switches on the board. The boot mode DIP switches are located in the middle of the board. To boot from USB, flip both switches towards the label \texttt{JTAG}. To boot from the SD card, flip both switches towards the label \texttt{SD}.
|
||||
|
||||
\begin{figure}[hbt!]
|
||||
\centering
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
ensuring? Not much care by default, I'd say - default routing table goes dest 1 - sfp0, dest 2 - sfp1 etc.; ``though some care is required with the enusing DRTIO destination numbers.``
ensuring?
Not much care by default, I'd say - default routing table goes dest 1 - sfp0, dest 2 - sfp1 etc.;
architeuthis
commented
"ensuing". but nvm, I entirely misread what I thought I was referencing. "ensuing". but nvm, I entirely misread what I thought I was referencing.
|
||||
\includegraphics[height=3in]{kasli-soc_dip_switches.jpg}
|
||||
\caption{Position of DIP switches, SD card, and reset pins}
|
||||
\end{figure}
|
||||
|
||||
\subsection{POR jumpers and POR reset}
|
||||
|
||||
A known Xilinx hardware bug prevents repeatedly booting over JTAG without a POR reset. If necessary, repeated boots can be made possible by physically setting jumpers on both the \texttt{PS\_POR\_B} and \texttt{PS\_SRST\_B} pins (marked in figure above) and triggering a reset over JTAG, see also the M-Labs POR reset script.\footnote{\url{https://git.m-labs.hk/M-Labs/zynq-rs/src/branch/master/kasli_soc_por.py}}
|
||||
|
||||
\section{User LEDs}
|
||||
|
||||
Kasli-SoC designates two user LEDs for debugging purposes. One is located on the PCB; it can be found at the very bottom left of the board, below the SFP cage, labeled \texttt{USER0}. The second is located on the front panel, besides the Ethernet port, labeled \texttt{L1}.
|
||||
|
||||
\sysdescsection
|
||||
|
||||
An example description file for a system using 1125 Kasli-SoC as a master core device might begin:
|
||||
|
||||
\begin{tcolorbox}[colback=white]
|
||||
\begin{minted}{json}
|
||||
"target": "kasli_soc",
|
||||
"variant": "my_variant",
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
is is ``LD1`` available for the kernels anyway?
architeuthis
commented
A second LED is. I'm not 100% that this is LD1 but I thought that's what I remembered it being. [_A_ second LED is](https://github.com/m-labs/migen/blob/c19ae9f8ae162ffe2d310a92bfce53ac2a821bc8/migen/build/platforms/sinara/kasli_soc.py#L7C27-L7C31). I'm not 100% that this is LD1 but I thought that's what I remembered it being.
mwojcik
commented
LD1 is a visual Loss of Lock indicator for Si5324: The second USER LED is visible on the front panel, below the Ethernet port. LD1 is a visual Loss of Lock indicator for Si5324:
![image](/attachments/4ad16341-96be-4b9a-9fc7-23b92b8b0eaf)
The second USER LED is visible on the front panel, below the Ethernet port.
architeuthis
commented
Oops. Got it. (That isn't marked on the FP diagram used in the shop, though.) Oops. Got it. (That isn't marked on the FP diagram used in the shop, though.)
|
||||
"hw_rev": "v1.0",
|
||||
"base": "master",
|
||||
"peripherals": [ ]
|
||||
\end{minted}
|
||||
\end{tcolorbox}
|
||||
|
||||
\coresysdesc
|
||||
|
||||
\coredevicecode{1125 Kasli-SoC carrier}
|
||||
|
||||
\ordersection{1125 Carrier Kasli-SoC}
|
||||
|
||||
\finalfootnote
|
||||
|
||||
\end{document}
|
2
Makefile
@ -1,4 +1,4 @@
|
||||
inputs = 1124 2118-2128 2238 2245 4410-4412 4456 5108 5432 5518-5528 5568 7210
|
||||
inputs = 1124 1125 2118-2128 2238 2245 4410-4412 4456 5108 5432 5518-5528 5568 7210
|
||||
dir = build
|
||||
|
||||
all: $(inputs)
|
||||
|
BIN
images/1125/Kasli-SoC_FP.pdf
Normal file
BIN
images/1125/kasli-soc_dip_switches.jpg
Normal file
After Width: | Height: | Size: 204 KiB |
BIN
images/1125/photo1125.jpg
Normal file
After Width: | Height: | Size: 304 KiB |
22
preamble.tex
@ -43,18 +43,26 @@
|
||||
BOMs) can be found in detail at the repositories \url{#3} and \url{#4}.
|
||||
}
|
||||
|
||||
\newcommand{\sysdescsection}{
|
||||
\section{ARTIQ System Description Entry}
|
||||
|
||||
ARTIQ/Sinara firmware/gateware is generated according to a JSON system description file, allowing gateware to be specific to and optimized for a certain system configuration.
|
||||
% It isn't possible to use verbatim environments within \newcommand macros
|
||||
% so the minted colorbox is easier to use directly in each file
|
||||
}
|
||||
|
||||
\newcommand{\codesection}[1]{
|
||||
\section{Example ARTIQ Code}
|
||||
The sections below demonstrate simple usage scenarios of extensions on the ARTIQ control system. These extensions make use of the resources of the #1. They do not exhaustively demonstrate all the features of the ARTIQ system.
|
||||
|
||||
The full documentation for ARTIQ software and gateware, including guides for their use, is available at \url{https://m-labs.hk/artiq/manual/}. Please consult the manual for details and reference material of the functions and structures used here.
|
||||
}
|
||||
|
||||
\newcommand*{\ordersection}[1]{
|
||||
\section{Ordering Information}
|
||||
To order, please visit \url{https://m-labs.hk} and choose #1 in the ARTIQ/Sinara hardware selection tool. Cards can be ordered as part of a fully-featured ARTIQ/Sinara crate or standalone through the 'Spare cards' option. Otherwise, orders can also be made by writing directly to \url{mailto:sales@m-labs.hk}.
|
||||
}
|
||||
|
||||
\newcommand{\codesection}[1] {
|
||||
\section{Example ARTIQ Code}
|
||||
The sections below demonstrate simple usage scenarios of extensions on the ARTIQ control system. These extensions make use of the resources of the #1. They do not exhaustively demonstrate all the features of the ARTIQ system.
|
||||
|
||||
The full documentation for ARTIQ software and gateware, including the guide for its use, is available at \url{https://m-labs.hk/artiq/manual/}. Please consult the manual for details and reference material of the functions and structures used here.
|
||||
}
|
||||
|
||||
\newcommand*{\finalfootnote}{
|
||||
\section*{}
|
||||
\vspace*{\fill}
|
||||
|
119
shared/coredevice.tex
Normal file
@ -0,0 +1,119 @@
|
||||
\newcommand{\spectable} {
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{threeparttable}
|
||||
\caption{Recommended Operating Conditions}
|
||||
\begin{tabularx}{0.85\textwidth}{l | c c c | c | X}
|
||||
\thickhline
|
||||
\textbf{Parameter} & \textbf{Min.} & \textbf{Typ.} & \textbf{Max.} &
|
||||
\textbf{Unit} & \textbf{Conditions} \\
|
||||
\hline
|
||||
Clock input & & & & &\\
|
||||
\hspace{3mm} Input frequency & & 125 & & MHz & Si5324 synthesizer bypassed \\
|
||||
\cline{2-6}
|
||||
% 100R termination & 100/350/600 mV differential input after the transformer.
|
||||
& \multicolumn{3} {c|}{10/80/100/125} & MHz & RTIO clock synthesized from input \\
|
||||
\cline{2-6}
|
||||
\hspace{3mm} Power & -9 & 1.5 & 5.5 & dBm & \\
|
||||
\hline
|
||||
Power supply rating & \multicolumn{4}{c|}{12V, 5A} & \\
|
||||
\thickhline
|
||||
\end{tabularx}
|
||||
\end{threeparttable}
|
||||
\end{table}
|
||||
|
||||
Power is to be supplied either through the barrel connector in the front panel (size 5.5 mm OD, 2.5 mm ID) or the Molex connector at the back of the card (compatible with e.g. Sinara 1106 EEM AC Power Module). It is passed on to daughtercards through the EEM connections. Locking barrel connectors are supported.
|
||||
}
|
||||
|
||||
\newcommand{\artiqsection} {
|
||||
\section{Firmware/ARTIQ}
|
||||
|
||||
ARTIQ is open-source and can be found in the repository \url{https://github.com/m-labs/artiq}. Orders of Sinara hardware are normally preflashed with suitable firmware and gateware binaries. Long-term support for ARTIQ systems can also be purchased, including updated binaries through AFWS (the ARTIQ Firmware Service).
|
||||
}
|
||||
|
||||
\newcommand{\noteondrtio}[1]{
|
||||
|
||||
\subsection{Note on distributed RTIO (DRTIO)}
|
||||
|
||||
DRTIO is the time and data transfer system which allows ARTIQ RTIO channels to be distributed among several core device carrier boards, synchronized and controlled by a central master device. The system itself is described in more detail in the ARTIQ documentation\footnote{\label{manual-drtio}\url{https://m-labs.hk/artiq/manual/drtio.html}}. Within ARTIQ, core devices, including #1, can take one of three roles:
|
||||
\begin{enumerate}%[topsep=2pt, itemsep=2pt]
|
||||
architeuthis marked this conversation as resolved
Outdated
morgan
commented
ext0_synth0_80to125 is missing ext0_synth0_80to125 is missing
|
||||
\item \textbf{Master} \\
|
||||
A DRTIO system must contain one DRTIO master. It controls its own local RTIO channels and the downstream DRTIO satellite(s). It requires a direct network connection to the host machine. It may make downstream connections to satellites.
|
||||
architeuthis marked this conversation as resolved
Outdated
mwojcik
commented
150MHz was deprecated too 150MHz was deprecated too
|
||||
\item \textbf{Satellite} \\
|
||||
Other core devices in a DRTIO system are DRTIO satellites. They require an upstream connection to one other core device, master or satellite, through which communications are carried to the master. They may make further downstream connections to other satellites. They may control their local RTIO channels directly through subkernels or simply pass on communications from the master.
|
||||
\item \textbf{Standalone}\\
|
||||
When run in a non-distributed ARTIQ configuration, with a single central core device but without satellites, that core device is known as standalone.
|
||||
\end{enumerate}
|
||||
|
||||
}
|
||||
|
||||
\newcommand{\clockingsection}[2]{
|
||||
|
||||
\section{Clock Routing}
|
||||
|
||||
\subsection{Standalone/Master}
|
||||
|
||||
The RTIO clock is typically synthesized by the Si5324 clock multiplier and distributed by the ADCLK948 clock fanout buffer to both the #2 and the MMCX connectors. Alternatively, an external reference can be supplied through the front panel SMA connector. It is then buffered in the #2 and sent to the Si5324 for clock synthesis. #1 supports a set of RTIO clock options:
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\begin{tabular}{|c|c|c|}
|
||||
\hline
|
||||
RTIO frequency & Configuration & Clock generation \\ \hline
|
||||
100 MHz & \texttt{int\char`_100} & internal crystal oscillator using PLL, 100 MHz output \\ \hline
|
||||
\multirow{5}{*}{125 MHz} & \texttt{int\char`_125} & internal crystal oscillator using PLL, 125 MHz output (default) \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_10to125} & external 10 MHz reference using PLL, 125 MHz output \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_80to125} & external 80 MHz reference using PLL, 125 MHz output \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_100to125} & external 100 MHz reference using PLL, 125 MHz output \\ \cline{2-3}
|
||||
& \texttt{ext0\char`_synth0\char`_125to125} & external 125 MHz reference using PLL, 125 MHz output \\ \hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
sb10q
commented
Not sure if we should keep this here or have it only in the ARTIQ manual? Not sure if we should keep this here or have it only in the ARTIQ manual?
These options are software defined.
|
||||
|
||||
The clock synthesizer may also be bypassed, using the \texttt{ext0\char`_bypass} option, which will accept a RTIO clock directly supplied to the SMA connector. The resulting signal is then routed to both the RTIO system and downstream satellites.
|
||||
|
||||
Clocking options in a running system should be configured by setting the value of the \texttt{rtio\char`_clock} key to the desired configuration through the ARTIQ \texttt{artiq\char`_coremgmt} command. For example, a RTIO frequency of 125MHz will be synthesized from an external 10 MHz signal after issuing the following command:
|
||||
|
||||
\begin{center}
|
||||
\texttt{artiq\_coremgmt config write -s rtio\_clock ext0\_synth0\_10to125}
|
||||
\end{center}
|
||||
|
||||
and rebooting.
|
||||
|
||||
\subsection{Satellite}
|
||||
The RTIO clock is recovered from the SFP transceiver connected to the upstream device. The resulting signal is then cleaned up by the Si5324 and routed to both the RTIO system and downstream satellites.
|
||||
|
||||
\subsection{WRPLL}
|
||||
|
||||
#1 can be configured to use WRPLL, a clock recovery method making use of White Rabbit's DDMTD (Digital Dual Mixer Time Difference) and the card's Si549 oscillators, both to lock the main RTIO clock and to lock satellite clocks to master.
|
||||
}
|
||||
|
||||
\newcommand{\coresysdesc}{ % again including the minted JSON snippet through a macro isn't practical
|
||||
|
||||
where the \texttt{peripherals} list contains the corresponding entries for peripherals (daughtercards) in use.
|
||||
|
||||
For all accepted keys and values, see the JSON schema \texttt{coredevice\_generic.schema.json} in the ARTIQ repository.\footnote{\url{https://github.com/m-labs/artiq/blob/release-8/artiq/coredevice/coredevice_generic.schema.json}}.
|
||||
}
|
||||
|
||||
\newcommand{\coredevicecode}[1] {
|
||||
\codesection{#1}
|
||||
|
||||
\subsection{Direct Memory Access (DMA)}
|
||||
|
||||
Instead of directly emitting RTIO events, sequences of RTIO events can be recorded in advance and stored in the local SDRAM. The event sequence can then be replayed at a specified timestamp. This is of special advantage in cases where RTIO events are too closely placed to be generated as they are executed, as events can be replayed at a higher speed than the on-FPGA CPU alone is capable of.
|
||||
|
||||
The following example records an LED event sequence and replays it twice consecutively using \texttt{CoreDMA}. When run, the LED should blink twice.
|
||||
|
||||
\inputcolorboxminted{firstline=10,lastline=29}{examples/dma.py}
|
||||
|
||||
Stored waveforms can be referenced and replayed in different kernels, but cannot be retrieved and must be regenerated if the core device is rebooted.
|
||||
|
||||
\subsection{Dataset manipulation with core device cache}
|
||||
Experiments may require values computed or found in previously executed kernels. To avoid invoking an RPC or sacrificing the pre-computation in \texttt{prepare()} stage, data can be stored in the core device cache.
|
||||
|
||||
The following code snippets describe two experiments, in which the data from the first experiment is cached. The data is then retrieved and printed in hexadecimal form in the second experiment.
|
||||
|
||||
\inputcolorboxminted{firstline=9,lastline=16}{examples/cache.py}
|
||||
\inputcolorboxminted{firstline=24,lastline=35}{examples/cache.py}
|
||||
|
||||
Similar to DMA, cached data is no longer retrievable once the core device has been rebooted.
|
||||
}
|
80MHz is also supported