View and Download the full PDF
Open-VTI Backplane Standard #
ABSTRACT #
This document defines the Open-VTI backplane standard used on the HILTOP platform.
AUTHOR – Tim Telford
DATE – 21st December 2023
DOCUMENT NUMBER – DR016
REVISION – Issue 1.0
Devtank Ltd
Definitions #
Term/Acronym | Definition
Open-VTI | Open Versatile Test Interface Standard
PXI | PCI eXtensions for Instrumentation.
USB | Universal Serial Bus
SPI | Serial Peripheral Interface
I2C | Inter-Integrated Circuit bus standard
PCI | Peripheral Component Interconnect
LVDS | Low Voltage Differential Signalling
FPGA | Field-Programmable Gate Array
PLD | Programmable Logic Device
ASIC | Application Specific Integrated Circuit
SoM | System-On-Module
Introduction #
This document defines the Open-VTI standard originally developed at Devtank Ltd to support a low cost, flexible and developer friendly backplane architecture for our HILTOP Test and Measurement Platform. This document describes the features and implementation details required for anyone wishing to develop products and solutions using the bus standard.
Background #
When researching the market for test and measurement modular solutions a number of standards were considered including the popular PXI architecture which makes use of the PCI electrical specification with Eurocard mechanical packaging and desktop PC technology..
When developing solutions with single board computers and system on modules such as those offered by Raspberry Pi & Beagle Bone, PCI buses are often not available and not required for a large number of use cases. The PXI feature set is very comprehensive and a number of features were carried across to the Open-VTI standard, to provide similar functionality but in a lighter weight form.
The aim of this standard is to enable rapid deployment of single board computer based test solutions using standardised protocols such as USB2.0, SPI and I2C thus providing a lower barrier to entry and easy adoption. Advanced features are still available for demanding applications and this bus topology should satisfy a large majority of test requirements that a typical test engineer will require.
Architecture #
Open-VTI offers a number of features which are documented in the following section. Existing PXI users will be familiar with some of these features as many of the same principles are carried across. The backplane system currently supports up to 6 card slots (plug-in card modules) connected to one master controller (typically single board computer motherboard in the case of the Devtank HILTOP). Each card slot is designed to work with a plug-in card module, providing specific test,
measurement and control functionality. Cards can be developed by users to suit custom requirements or purchased from companies such as Devtank Ltd.
Mechanical Architecture #
The backplane is designed to fit into a standard 3U industrial chassis which uses the Eurocard form factor. Card slots are spaced 6HP (30.48mm) apart. The maximum supported Eurocard format is 160mm x 100mm, to fit a standard 3U chassis. At the time of writing this document, two versions of the backplane are available from Devtank with either 3 or 6 card slots (3 card version shown below). These will fit either a 63HP or 84HP HILTOP chassis in conjunction with HILTOP motherboard (system controller). The controller is accessed via a standard 64pin PCI-E edge connector. Note other motherboards can be used if they follow the specification as documented. An 84HP chassis will fit a standard 19” rack allowing up to 6 plug-in card modules. The Eurocard connectors adopted for Open-VTI are the DIN41612 Type C connector family with 96pins. These can be purchased along with Eurocard prototyping boards from most major electronic parts distributors. This format enables rapid development cycles and allows testing on the backplane before production boards are ordered.
Electrical Architecture #
The bus architecture provides the following features to each card slot:
• System Clock & Trigger
• Shutdown, Reset & Port Select
• USB 2.0
• Local Bus
• SPI Bus
• I2C Bus
• PWM
• GPIO (Master Controller)
• Power Supply Rails
Optional features are available using the onboard backplane expansion socket (SO-DIMM 200pin DDR2) to host an FPGA/ASIC/SoM device. The choice of device is flexible and user configurable but the following default I/O connectivity is provided per card slot.
• LVDS High Speed Bus
• LVDS Master Clock
• GPIO (Exp. Device)
These features are described in more detail in the proceeding sections.
System Clock #
A single ended clock signal that can be driven from master controller or backplane expansion device.
System Trigger #
Matched length master trigger line for accurate synchronisation of cards. Can be driven from master controller or expansion device on backplane.
Shutdown, Reset #
Shutdown and Reset signals are global logic lines (3.3V TTL) which are provided by the master controller. For the HILTOP implementation, reset is driven by a global reset device (STM6719SFWB6F) on the system controller motherboard. This device provides a controlled reset of all connected devices on both motherboard and backplane during the DC power switch on event.
Port Select #
Port select lines are provided to address the AT25DN512 EEPROM device fitted to each plug-in card module on a per slot basis. The EEPROM device is a mandatory requirement for each plug-in card module which is connected to the master controller using the SPI0 bus. Each port select line (1-6) is effectively just a dedicated chip select line to address individual cards and determine their function/card type and any auxiliary information such as calibration data.
USB 2.0 #
A USB2.0 bus to each card slot from the system controller (via Hub device). This device supports high speed data rate of 480Mbps using the onboard hub (USB2517), but data rates are ultimately governed by the downstream card peripherals connected and signal integrity of the combined backplane/card solution. USB2.0 is the primary means of communication with a plug-in card/test module. USB protocol is used for payload, debug and re-programming of any plug-in modules.
Protocol used is command and response text interface type and is described in the software section of this document.
Local Bus #
Each card slot is daisy chained to its neighbouring slot with a bus upto 8 lines. The bus lines can be used for analogue, digital or power and can support upto 3A current capacity with a 20°C temperature rise. In the case of an intermediate slot, the left and right hand neighbouring slots will be connected which allows multi-card solutions to be realised.
SPI Bus #
Two SPI buses are provided from the motherboard system controller. SPI0 bus is reserved for communication with the plug-in card modules EEPROM device see above. SPI1 can be used to connect SPI enabled peripherals directly to the master controller.
I2C Bus #
Two I2C buses are provided from the motherboard system controller. I2C0 bus is reserved for system controller functionality and should not be used without prior knowledge of its connectivity. I2C1 can be used to connect I2C enabled peripherals directly to the master controller.
PWM #
Two dedicated PWM lines are provided from the system controller and shared with all backplane card slots. These can be used for a variety of applications by the user.
GPIO #
A total of 10 x GPIO lines are provided from the system controller and shared with all backplane card slots. These signals are application specific and the user must be aware of compatibility constraints where multiple plug-in modules are connected to a backplane. System controller GPIO lines are also routed via the backplane expansion module using 0R resistor links. In addition the backplane expansion module provides 10 dedicated GPIO lines per card slot. This provides another communication option between master controller and backplane expansion module (e.g.FPGA/PLD).
Power Supply Rails #
A mixture of DC power rails are provided per card slot to suit the typical design requirements required for a plug-in card/test module. Each power supply rail is current limited through the provision of resettable poly-fuses fitted to the backplane on a per card slot basis.
• +12V ±5%, 0.75A
• +5V ±5%, 0.5A
• -5V ±5%, 0.5A
• +3V3 ±5%, 0.75A
• +VADJ ±2.5%, 1A
Note: +12V, +5V, -5V & +3V3 are sourced from the main system ATX power supply and conform with the ATX v2.2 standard.
+VADJ is a software controllable DC buck-boost output range of 2-30VDC and is derived from the master-controller (HILTOP Motherboard or other system controller) using 12VDC incoming supply. A maximum of 3A is available on +VADJ from the HILTOP Motherboard. This is shared across all card slots so for multi-card solutions where +VADJ is used the designer should ensure the maximum current allocation is not exceeded. If increased power is required above and beyond the protected backplane inputs then this may be supplied from the HILTOP or system ATX power supply module. Provisioning of additional connectors on the plug-in card design such as the example below which uses a Molex 4 pin 5.08mm
pitch right angle connector which mates with the auxiliary power connectors commonly available with ATX power supplies.
LVDS High Speed Bus #
Two pairs of LVDS 100Ω matched length signals are provisioned on the backplane from expansion module to each card slot. This allows a full duplex serial data protocol to be implemented between custom expansion device such as an FPGA and each individual plug-in card module.
LVDS Master Clock #
An LVDS 100Ω matched length clock signal is provided on the backplane from expansion module to each card slot. This is a star topology and provides a matched clock reference for the high speed LVDS data bus.
Software Architecture #
Each plug-in card/module has an AT25F512A EEPROM fitted which is connected on the SPI0 bus and selected using dedicated port select lines described in the electrical specification above. The EEPROM stores JSON text, in a flow style, containing identification and any specific card information required for the cards application such as unique calibration data. The JSON format starts with a header of:
VERSION: 1
CARD: INDRA-LOTI
PRODUCT: 1003-003
REVISION: A
SERIAL: 4
CAL_DATE: ‘YYYY-MM-DD’
HEADER_MD5: <HEX MD5>
BODY_MD5: <HEX MD5>
BODY_SIZE: <SIZE IN BYTES>
This is the version number of the JSON scheme, the card name, the Devtank production number, the hardware revision and the card’s serial number.
The CAL_DATE field is the date the EEPROM was last written. This is year, month and day.
The BODY_SIZE field is the number of bytes of body after the header.
The BODY_MD5 field is the MD5 sum of the body after the header.
The HEADER_MD5 field is MD5 of the JSON text of the other lines.
Typically, Devtank have stored calibration of the specific card in the EEPROM using the BODY
fields.
A plug-in card/module contains its own microprocessor/PLD device connected to the HILTOP’s Raspberry Pi Compute module over USB. The microprocessor implements USB serial protocol, and the Raspberry Pi Compute module provides command and response over this USB serial in plain text. This allows for easy debug and manual control of the card.
To separate firmware debug and firmware control and to aid card bring up, as well as providing GPIOs to control programming lines, each card also has a separate real USB UART connected to the main debug UART of the microprocessor. The card firmware can be programmed over this real UART or USB protocols if the microprocessor supports DFU mode such as the STM32 micro- controller family.
This dual UART feature normally requires the use of a 2 port USB hub device fitted to the card.