VPX2IP

IndustryPack® Modules are an important part of solutions for Embedded situations. Rugged, small, light .. just right for many applications. IndustryPack® Modules require a "carrier" in most cases to adapt them to the system. Dynamic Engineering has carrier solutions for a variety of formats. VPX2IP is designed to support VPX solutions. Alternate types available available for PC104p, cPCI, and PCI, PCIe and planned for cPCIexpress, PC104express.

VPX2IP is part of the IP Compatible family of modular I/O components. VPX2IP provides two IndustryPack® module sites in one 3U VPX slot. VPX2IP acts as an adapter, converter, carrier, and bridge between the PCIe bus and your IndustryPack® hardware.

VPX2IP is supported with Windows® compliant drivers as well as Linux support. Coming is VxWorks support. The drivers come with a generic IP driver to allow use with "unknown" IPs ↔ IPs that do not have a driver designed yet. For example, third party IP modules.

IndustryPacks are 16 bit devices, and the PCIe bus supports larger payloads. VPX2IP accepts up to 128 byte payloads, and converts to word accesses. Most modern CPU´s can generate 8, 16, 32 and 64 bit instructions. The IP accesses can be auto-incremented or static address accesses. With the static access option the intended word can be accessed multiple times. With auto-incremented addresses multiple addresses are accessed. The strength of the PCIe bus is in handling larger payloads. VPX2IP provides the capability of handling larger payloads to reduce the average execution time. By changing from 16 bit accesses to 32 the overhead is cut in half and by going to quad instructions the over head is cut in 4 leading to much higher bandwidth. For payloads larger than 64 bits DMA is needed to create the packets. The current VPX2IP implementation includes the larger payload capabilty using external DMA. We are working on FPGA supported DMA to make CPU independent.

With Gen1 PCIe t takes about 2.5 uS to read a 16 bit value from a target device. With reads the data from the IP must be accessed, and a return payload constructed, and transferred to the host before the host can proceed to the next instruction. The access time for the IP Module is only 94 nS at 32 MHz with 1 wait state. The response time is dominated by the over head. This is based on a loop of 1000 accesses to a 32 MHz IP with 1 wait state in the memory space. [Performed on PCIe3IP] (2.451 uS was the tight loop average). The same loop with 32 bit accesses took an average of 2.556 uS or 1.278 uS per 16 bit read. The 64 bit loop provided 2.741 uS or .685 uS per 16 bit read. Larger payloads will approach the actual read time of the IP HW.

With writes the time is much lower due to the ability to auto respond before the write is completed, and the FIFO´s allowing storage of multiple commands per IP module. With the same parameters as the above and a write loop, the average for 16 bit access is .548 uS, for 32 bit .301us/word and for 64 bit .205uS/word. With larger transfers the access time will approach the IP access time on an average per word basis.

The Dynamic Engineering implementation does not require any special features on your IP module. Larger transfer sizes are especially useful for repetitive data transfers - loading or reading from RAM or FIFOs faster will reduce the overhead on your CPU leading to more available time to process the data leading to lower cost or more capable systems.

Each position has a separate clock controller for 8 and 32 MHz operation. The frequency to be changed on the fly. The state-machine within the bridge design automatically locks to the IP Slot frequency as programmed.

Each PCIe transaction is pre-decoded and forwarded to separate IP Module handling logic. Each Module has separate memory and control interfaces to allow for overlapped IP operation. For example IP 0 can be executing a read or write in parallel with IP 1 and IP 2. Multiple commands can be stored for execution by each IP. Synchronization between the IP´s is available to provide multi IP sequenced programming should that be necessary.

VPX2IP asks for MSI interrupts during enumeration. If provided by the system, MSI interrupts will be available for operation. Legacy interrupts are provided when MSI interrupts are not programmed by the system.

Each IP position has "self healing" fused, filtered power. Each IP Module has separate bulk and bypass capacitance.

Industry standard 50 pin [ribbon cable] headers are used with the IO connectors. The connector at the bezel is a right angle condo model and is mounted through the bezel. The bezel connector is outfit with ejectors. Rear IO is an option. All of the IO is routed as differential pairs with matched length for each connector, controlled impedance and jumper resistors in place to minimize stubs. With the bezel IO option all IO are available from both positions. With rear IO there are 64 signal possibilities and 100 potential IO from the two IP modules. Additional resistor selections are provided to allow for a mix of IO from the two positions to be mapped to the rear VPX connector.

Ribbon cable or discrete wire cables can be interfaced directly with the VPX2IP. Alternatively the HDRterm50 can be used to create a terminal block interface.

The IP´s can be reset from the control register within the FPGA via the software interface. In addition at power-up the IP´s are provided the 200 mS reset as required by specification.

LED´s are provided to each of the IP slots for activity indicators. When each slot is accessed the LED is flashed. The FPGA provides a "one shot" circuit to stretch the "on" time to make it visible. Power indicator LED´s are provided using voltage monitors. An additional eight user LED´s are available for debugging or other purposes.

A surface mount "dip switch" is available for configuration control or debugging purposes. The switch values are available to be read via the PCIe bus. The switch is used for deterministic control by the driver. When multiple carriers are used in the same system the switch is used to allow the driver and application software to "know" which carrier maps to which handle. Further the slot information for a particular IP is stored to create a "vector" pointing to a specific slot on a specific carrier. Deterministic control of specific interfaces is easily achieved with this system without hardwiring system data into your software. The application software will be more portable and not break when new assets are added to the system (and your PCIe addresses change).

IP accesses are protected by a watch-dog timer. The timer is started at the beginning of each IP access. If the timer expires before the IP being accessed responds, a bus error internal to the VPX2IP is created. VPX2IP responds normally to the host, not creating an errror on the PCIe bus, and provides status and an optional interrupt to alert the host to the problem with the IP. The Bus Error timer is useful in situations where the software may want to cause a bus error to find out what is installed or where a hung system would have consequences.

Connector positioning is compatible with IP-Debug-Bus will allow the user to isolate and debug the control interface of an IP. The IP-Debug-IO can be used in conjunction with the VPX2IP and IP-Debug-Bus to provide test-points on the IO signals and loop-back capability for the IP.

VPX2IP is an extended temperature board. The extended or "Industrial Temp" version has components rated for -40C to +85C minimum. This temperature range will need to be derated based on your chassis thermal situation.

A new feature called "VPWR" has been added. VPWR is the voltage on the "5V" connection to the IP modules and terminations. The default is 5V to match the IP standard. The pin allocated to " Reserved 1" is monitored on each IP position and if any are grounded the voltage changes from 5V [open] to 3.3V [grounded]. The VPWR 5V LED is illuminated in open mode and VPWR 3.3V LED is illuminated for the RES1 = GND mode. Please note: Previous revisions VPWR = 5V independent of RES1.

The benefit of VPWR: Most current FPGAs operate with 3.3V and are not 5V tolerant. To operate on the IP bus level shifters are required on both ends. IP Modules targeting Dynamic Engineering carriers for installation can remove the level shifters and ground the RES1 pin (36 on IP Bus Connector). In addition most IO does not require 5V and can use 3.3V to eliminate a power supply on the IP Module.