A short video showing OpenCPI transport messages between Altera and Xilinx FPGA platforms.
Wednesday, August 31, 2011
Tuesday, August 16, 2011
Pure PCIe
The PCIe specification does a splendid job of describing how Transaction Level Packets (TLPs) are encoded. The specification precisely defines an interface without dictating an implementation. It’s a terrific concept.
FPGA and ASIC IP vendors, when providing said TLP interfaces to their users, make implementation choices that are specific to their own technological and marketing whims. These choices run the gamut from reasonable to ridiculous: Big-endian vs. Little-endian? Streaming or not? Header vs. Payload? Strict or Uncertain flow-control.? Packing “bubbles” and straddled packets? My goodness: All of these to alter of protocol gods that have little to do with PCIe TLPs themsleves!
Faced with the challenge of achieving interoperability with and between any of these PCIe endpoints; out of necessity, we followed a simple process. We designed a Pure PCIe intermediate “platform” that used nothing other than the “pure” PCIe specification for its definition. In this way, the work involved with adapting any PCIe device (now or future) has one overarching goal: Adapt the variable implementation to the fixed, pure PCIe interface.
The utility of this simple approach is that interconverting between different implementations is now just a matter of hooking them to the other side of the pure PCIe interface. We get multiplicative gains in interoperability for a linear effort in design cost. And we get the verification leverage of only having to compare one unknown (the new protocol) to one bulletproof interface (the PCIe TLP spec) at a time.
The lesson here is that there are indeed clever tactics one can take to embrace the reality that new protocols (some brilliant, some defective) will continue to assault us as they are invented. By recognizing stable, more cardinal interfaces (such as PCIe TLPs), we can adopt them all, without as much drama and cost.
FPGA and ASIC IP vendors, when providing said TLP interfaces to their users, make implementation choices that are specific to their own technological and marketing whims. These choices run the gamut from reasonable to ridiculous: Big-endian vs. Little-endian? Streaming or not? Header vs. Payload? Strict or Uncertain flow-control.? Packing “bubbles” and straddled packets? My goodness: All of these to alter of protocol gods that have little to do with PCIe TLPs themsleves!
Faced with the challenge of achieving interoperability with and between any of these PCIe endpoints; out of necessity, we followed a simple process. We designed a Pure PCIe intermediate “platform” that used nothing other than the “pure” PCIe specification for its definition. In this way, the work involved with adapting any PCIe device (now or future) has one overarching goal: Adapt the variable implementation to the fixed, pure PCIe interface.
The utility of this simple approach is that interconverting between different implementations is now just a matter of hooking them to the other side of the pure PCIe interface. We get multiplicative gains in interoperability for a linear effort in design cost. And we get the verification leverage of only having to compare one unknown (the new protocol) to one bulletproof interface (the PCIe TLP spec) at a time.
The lesson here is that there are indeed clever tactics one can take to embrace the reality that new protocols (some brilliant, some defective) will continue to assault us as they are invented. By recognizing stable, more cardinal interfaces (such as PCIe TLPs), we can adopt them all, without as much drama and cost.
Subscribe to:
Posts (Atom)
