Notes on FPGA DRM (part 1)

For a while I have been looking very closely at how FPGA cores are distributed (the common term is “IP cores”, or just “IP”, but I try to minimize the use of this over-used catch-all catch phrase). In what I hope to be a series of posts, I will mostly discuss The problem (rather than solutions), as I think that that needs to be addressed and adequately defined first. I’ll start with my attempt at a concise definitions of the following:

FPGA: Field Programmable Gate Arrays are generic semiconductor devices comprising of interconnected functional blocks that can be programmed, and reprogrammed, to perform user-described logic functions.

Cores: ready-made functional descriptions that allow system developers to save on design cost and time by purchasing them from third parties and integrating them into their own design.

The “cores distribution problem” is easy to define, but challenging to solve: how can a digital design be distributed by its designer such that he can a) enable his customer to evaluate, simulate, and integrate it into its own, b) limit the amount of instances that can be made of it, and c) make it run only on specific devices. If this sounds like “Digital Rights Management” to you, that’s exactly what it is: DRM for FPGAs. Despite the abuse of some industries that made a bad name for DRM, in our application there may be benefits for both the design owner and the end user. We also know that enabling the three conditions above for a whole industry is challenging, and we are not even close to a solution.

The problem isn’t new, ASIC cores designers have been having trouble with this issue for years: run-on-fraud, copying, etc. The solution they arrived at is mostly based on trust and good reputation—valuable assets that are slowly gained yet easily lost—rather than cryptography. Big companies shaking hands with other big “trusted” companies relying on the potential reputation loss as an acceptable guarantee for honesty (plus a legal document). Apparently, this still works well for big companies, and while cryptographic solutions would be nice in order to alleviate the need for trust and provide for smaller companies world-wide, there is no real rush. “Panel unscrambles intellectual property encryption issues” has a very revealing discussion from the industry’s perspective and is well worth the read.

Back to FPGAs, with their unique use model, the trust-based system holds here as well; established companies can afford to purchase a blanket license for cores, are trusted, and that lets them use those as they like. You might have a problem, though, if you are a small and obscure company. As a poor start-up designer, you want to save time and money by taking advantage of “design-reuse”, but you can’t afford blanket licensing, and you may not be big enough, or in the right country, to be trusted even if you sign the NDA/licensing agreement. So, you either spend the time developing the design in-house, perhaps missing that three month opportunity window, or you give up. FPGA DRM could help you here because it will enable a pay-per-use model. You will be able to pay only for the instances of the core you use regardless of your company’s “trust status”, starting with small quantities until you hit it big. In turn, pay-per-use also benefits cores designers by giving them business that they wouldn’t have gotten otherwise. Both sides win. Sort of. More in Part 2.

5 thoughts on “Notes on FPGA DRM (part 1)

  1. Note that the core cost is NOT that high for anything reasonable, given the rest of the costs of doing a board design.

    DRM tends to mess things up alot, as it requires changing FPGA architectures, F@#)(* with the cad tools, etc…

  2. …you either spend the time developing the design in-houseor you give up or you use an open-source design?

    There’s already some precedent for open-source hardware and it’s not obvious why this shouldn’t be taken further.

  3. Given that the IP core industry is doing very well without DRM at the moment, using the normal checks and balances of business, it just doesn’t seem worth it.

    Just as with music DRM, you’re trying to make bits uncopyable. It may seem that this is practical inside specialist hardware, but those bits will end up being just bits again, once they’re inside the FPGA. It only takes one cracker with an electron microscope and a bit of time and ingenuity to crack the DRM system once, rendering your DRM’d IP back into logic equations, and the whole process is rendered futile. Expect this to be available as an illicit commercial service somewhere in China within three months of your system going into production.

    The only way to fix this would be to cripple the FPGA industry through vastly complex mandatory DRM measures designed to prevent FPGAs loading arbitrary sets of logic equations, and a huge infrastructure for somehow tracing the provenance of every subexpression of every system of FPGA equations in the world, no matter how transformed or obfuscated, back to its rightful owner. Since this is (a) practically infeasible (b) quite likely mathematically impossible, (c) defeats the whole point of FPGAs, it just isn’t going to happen.

    The results will be the same as now; honest players will license your DRM, and dishonest ones won’t. (The countermeasures will also be the same; the only players worth going after are the big ones, and they have so much to lose that it’s far, far, cheaper for them to licence your IP than to risk your reverse engineers catching them pirating it.)

    The music industry has just spent a decade learning this lesson, painfully and at great expense.

  4. Grr. The above had a typo which undermined the entire meaning of the second to last paragraph of the above.

    It should have read:

    “the results will be the same as now; honest players will license your _IP_, and dishonest ones won’t.”

  5. Nicholas and Neil,

    Thanks for your thoughts.

    We are in agreement mostly. Note that for now I am looking at/discussing the problem, not evaluating solutions. Once we (well, I) understand the problem better, and from the perspective of the cores vendors themselves, perhaps we (I?) will be able to come up with solutions that do not “F@#)(* with the cad tools” that much and are worth while?

Leave a Reply

Your email address will not be published.