Dealing with FPGA IP in all its forms

One of the recurring themes I see here in the pages of SemiWiki and elsewhere is this pitched, bordering on religious battle between Altera and Xilinx. Just because both are FPGA technologies, the tendency is to put them in the same bucket, drawing direct comparisons between them. Some folks say there is no comparison; Xilinx has a significant lead in process technology and capacity, and is therefore “better” according to many comments.

From my perspective, the two approaches are very different – and always have been. Both have merit. That raises issues for both the purveyor and consumer of “FPGA IP”. We use that term generically, as if an IP block can magically transform itself to fit any FPGA environment. Sometimes, it is true. In the simplest of cases, there is a hunk of plain vanilla RTL representing an IP block. Files are zipped up, sent off to a design team, added to an FPGA project, and synthesized into the top-level design.

Things in FPGAland are rarely that simple, even for those working with only one FPGA platform.

This goes beyond the philosophy saying designers should be able to work with more than one FPGA platform. At this point in the development of FPGA technology, it is a valid path to say “I’m an [Altera or Xilinx] expert”. Becoming deeply steeped in a particular architecture and its accompanying toolset is far less career limiting than it used to be. In fact, I can say from firsthand experience I have seen the world shift from encouraging generalists and adaptive skills to a culture that highly values specialists and frowns on broader experience. (Generalists are better suited to be writers and futurists, able to see and explain context and trends.)

More likely in the real world is the problem of FPGA IP in all its forms, some of which are packaged to work with your favorite FPGA platform, and some of which are not. There is always the choice to restrict IP selections to only compatible formats, but that may rule out otherwise acceptable code for an IP block that may in fact be a best-in-class solution. What if you are that best-in-class IP block provider, hoping for your creation to be used by FPGA designers anywhere?

Welcome to the starting point for a short, 20 minute webinar discussion from Parminder Gill, engineering project leader for Synopsys. Gill’s opening premise is that IP providers have shifted from the simple RTL example described earlier into more complex methods of packaging FPGA IP. He cites three drivers for why IP might be packaged differently:

• IP modes, with configurable functionality that can be trimmed to needs;
• targeted IP that leverages technology-specific primitives to achieve QoR;
• and licensing issues, which introduces variables like encrypted IP.

Not only does the IP vary as supplied, but code may vary by development state. Gill outlines the case for using a third-party synthesis tool – Synopsys Synplify – that can deal with everything from legacy code to stubs, and import FPGA IP from encryption and different packaging methods.

This is a compelling discussion for FPGA designers and IP providers, outlining the differences between packaging for Altera, Xilinx, third-party, and in-house IP, and how Synplify can integrate all of it. His best-practice recommendations provide perspective from both directions: using FPGA IP from various sources, and packaging FPGA IP for the broadest possible use.

Registration for the archived webinar:

Getting the Most out of IP-based Design with Synplify FPGA Design Tools

Even if your view of FPGAland is from deep inside one platform and vendor-supplied tools, this event is worth your time. FPGA IP reuse is an important issue, and needs broader discussion from all sides.