In this column, I'm starting a mini-series on the development of Intellectual Property (IP) cores from FPGA suppliers. The subject of IP cores from third-party vendors will be a follow-on topic since there are significant issues that differ between IP delivered from the FPGA manufacturers and third-party IP suppliers.
I discussed some of the background on IP development, from FPGA manufacturers' perspective, with Tim Vanevenhoven, Director of Marketing, IP Design Methodology at Xilinx. Tim has many years of experience developing IP and the associated tools, methodologies, and strategies used within Xilinx. We started out talking about the key issues faced by FPGA suppliers over the last several years with respect to IP core development.
IP cores improve my productivity, right?
Tim and I started out talking about how, over the last several years, IP cores have become a key (perhaps the key) element in enabling FPGA designers to work effectively with million-plus-gate devices.
For example, IP cores made it easier to use many of the "hardened" functions within large FPGAs (like memory, arithmetic functions, and SERDES). No one (well, no one I knew) really wanted to reinvent the wheel to create a FIFO or a floating-point multiplier or an I2C interface. Designing these things didn't really add any value to the design (they didn't help fundamentally differentiate my design from a competitor -- they were just standard building blocks). It was better if these standard "components" were offered by the FPGA manufacturer so I could more quickly and easily do my design (and use more FPGA gates, since that's what the FPGA suppliers wanted to sell me).
Over time, these building blocks became somewhat standard and were expected to be supported by the supplier as part of the FPGA design tool chain (third-party vendors couldn't make any money off many of these simple blocks). From this starting point, more complex blocks were demanded by customers -- even things like MCUs, DSP functions, and complex standard interfaces like USB or Ethernet, etc. Unfortunately, the FPGA suppliers had not really invested in the infrastructure to make all these IP cores play nicely with each other. Looking back, this shouldn't really be a big surprise since the manufacturers were primarily responding to specific customer requests (or demands, depending on how you look at it) -- they weren't really following a completely planned-out roadmap and grand strategy.
Now, the result of this approach to IP core development was to place some "bumps in the road" for FPGA designers who wanted to use IP cores for more and more of their designs. One of the biggest issues was the fact the even IP cores from the same FPGA manufacturer many times didn't easily "talk" to each other. In many cases, the designer needed to add "glue logic" between various IP cores because the bus interfaces were different or the handshake logic operated slightly differently (for example, latencies could be different or signals might be of the wrong polarity).
More complex differences might be that one IP core had a streaming interface while another had a memory-mapped interface. These differences required the designer to dig into the specifications and create some the glue logic needed to connect things up correctly. Luckily, FPGAs are good at gluing things together, but this cost designers significant development time in design, test, and verification. Time that IP cores were supposed to save!
Next page >