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.
Tuesday, May 31, 2011
Validating PCIe
LeCroy graciously loaned us their exceptional T2-16 PCIe Protocol Analyzer for a few days. This was not nearly enough time to appreciate an instrument that has such deep capabilities. While the T2-16 captures every nook and cranny of the PHY and LINK layers; we remain most-interested in watching what is going on at the Transaction Layer (TL). The T2-16 does this well; but a Ferrari can also take you to the grocery store. Functionally, the most-annoying nit was that the fans on the active interposer and in the chassis itself are screaming loud. And the LAN function didn't work; but USB worked flawlessly. Faced with an intractable, hard-to-understand PCIe issue; this is an instrument we would want by our side.
LeCroy T2-16
LeCroy T2-16
Wednesday, May 4, 2011
Sunday, May 1, 2011
FCCM 2011 Arrival
Salt Lake City is pretty. The last time I was here, we were we're hashing out the details of the FMC Standard up in Park City. This time it's FCCM. Dinner last night at Fresco was delicious.
Thursday, April 28, 2011
FPGA Design Intern Position
Job Title: FPGA Design Intern
Location: Auburn, NH
Stipend: $20/hour
Dates of Position: Flexible
Time Commitment: 3 to 6 months
Reporting To: CTO
Responsibilities: Design, simulation, and test of digital infrastructures and applications. The intern will write, test, and deploy BSV codes that will be contributed to an open-source community.
Qualifications:
- Bluespec SystemVerilog (BSV) experience (MIT 6.375 or equivalent) (mandatory)
- Experience with FPGA design and tool flows from Verilog sources (mandatory)
- Familiarity with RHEL, C, C++, Tcl, Python, Git and MATLAB
- Familiarity with OSS projects like www.opencpi.org and www.netfpga.org
- The intern may work remotely
- This position is non-ITAR; no clearance or US citizenship is required
- Atomic Rules builds heterogeneous circuits and systems centered on leading-edge FPGAs. We seek qualified, enthusiastic intern contributors.
Wednesday, March 9, 2011
Ubiquitious 10GbE
Five months after our travels to Dublin we have the NetFPGA-10G "NF10" board lit up and shuttling data across 10GbE and PCIe. There's no looking back, 10GbE is here.
NF10 in Core980 with ML605
NF10 in Core980 with ML605
Subscribe to:
Posts (Atom)
