Preliminary WRXI notes
Introduction
This is a set for preliminary notes for White Rabbit eXtensions for Instrumentation (WRXI). In time, these notes will evolve in a more concrete description of the project, list of requirements, specifications, etc.
A preliminary WRXI development roadmap is also available.
Adding WR support to an instrument
via FPGA (re)design
CERN currently provides the White Rabbit PTP Core (WRPC), an Ethernet MAC implementation capable of providing precise timing. WRPC simplifies the process of adding WR support in an FPGA design, by encapsulating all WR time-specific functionality and providing a standard MAC interface to the FPGA fabric for sending and receiving Ethernet frames.
The WRPC also includes a timing interface which provides current time to the FPGA fabric, in a form that can be easily used. It consists of a 1-PPS signal and a UTC timecode aligned to the time of WR Master.
Furthermore, the WRPC can "discipline" other clock signals via a loop-back mechanism. The FPGA provides the clock signals to the WRPC, and the WRPC generates a set of signals to control an external DAC, which in turns controls the clock source (eg. a VCXO).
Thus, within WRPC, there are multiple ways of synchronizing the instrument to WR time. One is to simply use the provided timing interface for timestamping and/or event scheduling. The other is to align the system clock(s) to the WR clock via the look-back mechanism. Depending on the instrument and its functionality, either or both methods might be applicable and/or required.
Adding a WRPC core to an FPGA design is a relatively straight-forward procedure. It is further supported by the White Rabbit Node Reference Design, which provides a good starting point.
Reported FPGA utilization summary for a WRPC implementation for a Spartan-6, XC6SLX45T (using WRPC v2.1, Xilinx ISE 13.4) is approximately 40% of logic, 50% of on-chip memory and 50% of clocking resources.
via external system
It is also possible, in order to provide WR support to an existing instrument to build a system around it, which will act as a WR bridge. This system will include an external WR interface, as well as one or more internal interfaces for communicating with and controlling the "legacy" instrument (such as GPIB, standard Ethernet, USB, external trigger outputs, etc.)
In terms of hardware, such a system could be built with readily available modules from the BE-CO-HT standard hardware toolkit. To serve as a very basic example, a WR-enabled fmc-delay-1ns-8cha mounted on a spec board, when augmented with the WRXI protocol, could maintain the necessary time synchronization with the WR network and receive commands to generate scheduled signals on its four outputs, with very precise timing. The scheduled signals in turn could be used to trigger a legacy instrument at a predefined time with very accurate timing. A very similar approach has been already followed within the scope of the LHC Instability Trigger Distribution project (LIST).
WRXI protocol design and implementation ideas
Mock Turtle -based solution
Mock Turtle is not a communication protocol. It is instead a soft-core multi-core processor, aiming at deterministic system control. However, it is listed here because, combined with WRPC and etherbone-core, it has been used already to implement a message exchanging mechanism over WR, via message queues.
The main advantage of the node core is that it casts the development effort from HDL for the FPGA to C code for the embedded soft-core processor.
Projects utilizing the Mock Turtle include:
All of the above-listed projects utilize custom communication protocols based on the message queue mechanism provided by the Mock Turtle..
In the frame of WRXI, the node core could be used in combination with WRPC (and perhaps also the etherbone-core) in order to simplify the development of a custom communication protocol.
LXI
LAN eXtensions for Instrumentation (LXI) is a standard developed and maintained by the LXI Consortium, which defines a standardized communication protocol over Ethernet, aimed at instrumentation, test and measurement systems.
The LXI specifications include a set of core features, which all LXI-enabled instruments should implement, as well as a set of optional extended features. Of particular interest to the WRXI project are the following extended features.
- LXI Clock Synchronization: LXI achieves clock synchronization across an Ethernet network via IEEE-1588 PTP. For this purpose, the consortium has defined an LXI IEEE 1588 Profile. For more information, refer to the LXI specification[1], all the links proposed in section 1.4.4.2.5 (and section 3.2 in particular).
- LXI Event Messaging: LXI allows event messaging between nodes within the network, without the need for an external controller. For more information, refer to the LXI specification[1], all the links proposed in section 1.4.4.2.4 (and sections 3.3, 3.5 in particular, as well as section 4 for the LXI event message format).
- LXI Timestamped Data: LXI devices can assign a timestamp to all measurement data. When combined with the clock synchronization extended feature, all such timestamps are derived from the local IEEE 1588 synchronized clock. For more information, refer to the LXI specification[1], all the links proposed in section 1.4.4.2.6 (and section 3.6 in particular).
LXI requires that each LXI device is accompanied by an IVI driver. Of particular interest to the WRXI project is the IVI-3.15: IviLxiSync Specification, which defines the API for controlling the arming, triggering, and event functionality of LXI devices that implement the above-described extended functions.
LXI is very attractive for WRXI, because it already proposes and implements all the necessary mechanisms to achieve the goals of the WRXI project. Furthermore, LXI utilizes PTP for clock synchronization, and WR is already backwards-compatible with PTP. This allows to envisage the following scenarios for a WRXI protocol based on LXI.
1st scenario: custom protocol, inspired from LXI
In this scenario, WRXI is a custom protocol, probably borrowing heavily from LXI. This is the most flexible solution, since we will be free to implement the protocol in any way we choose. However, instruments implementing the WRXI protocol will not be compatible with other instruments. Nevertheless, given the fact that the design of WRXI will be similar to LXI, it should be possible to produce a WRXI-to-LXI bridge device, which will allow to add LXI instruments to a WRXI network.
2nd scenario: partial LXI compatibility
In this scenario, WRXI will have partial LXI compatibility, implementing a subset of the rules of the LXI specification[1]. It remains to be investigated whether there exists such a subset which would allow a LXI instrument to be plugged to an WRXI network (and vice versa) and expose its most of its functionality.
If it is possible to find such a subset, it might also be feasible to start with partial compatibility and gradually move to full conformance (see 3rd scenario).
3rd scenario: full LXI conformance
In this scenario, WRXI will fully conform to the LXI specification[1], and WRXI devices could even apply for LXI certification. The downside of this scenario is that WRXI devices will have to implement a large number of features which might be not necessary (eg. TCP communication in addition to multicast UDP, and embedded web servers able to serve graphical control interfaces).