PCIe3IP

IndustryPack® Modules are an important part of solutions for Embedded situations. Rugged, small, light ... just right for many applications. IndustryPack® Modules require a carrier to adapt them to the system. Dynamic Engineering has carrier solutions for a variety of formats. PCIe3IP is designed to support PC computer based solutions. Solutions available for PCI, PC104p, cPCI, VPX and planned for cPCIexpress, PC104e.

PCIe3IP is part of the IP Compatible family of modular I/O components. PCIe3IP provides three IndustryPack® module sites in one PCIe slot. PCIe3IP acts as an adapter, converter, carrier, and bridge between the PCIe bus and your IndustryPack® hardware. PCIe3IP is a half size, single lane PCIe card compatible with the smallest chassis and all PCIe slots.

PCIe3IP is supported with Windows® compliant drivers for Win10 etc. as well as Linux and 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 IPs.

IndustryPacks are 16 bit devices, and the PCIe bus supports larger payloads. PCIe3IP 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. PCIe3IP 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 PCIe3IP implementation includes the larger payload capabilty using external DMA. We are working on FPGA supported DMA to make CPU independent.

With Gen1 it 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. (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 FIFO´s 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.

PCIe3IP 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. Vertical connectors are provided in the rear two positions. The connector at the bezel is a right angle model and is mounted through the bezel. The bezel connector is outfit with ejectors. An ordering option for ejectors to be mounted to the rear vertical headers is available. This is not the default option due to PCIe height restrictions. A recommended upgrade if your system has the room. "-EJ"

The bezel has a cut-out to allow the ribbon cables to be brought outside of the chassis without requiring an extra slot in the chassis. The blank bezel is available by adding "-BB" to the part number.

Ribbon cable or discrete wire cables can be interfaced directly with the PCIe3IP. 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.

LEDs are provided to each of the three 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 LEDs 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 PCIe3IP is created. The PCIe3IP 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 PCIe3IP and IP-Debug-Bus to provide test-points on the IO signals and loop-back capability for the IP.

PCIe3IP is an extended temperature board. This extended or "Industrial Temp" design has components rated for --40℃ ↔ +85℃ 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.