Most of us have heard the old saw “Good, fast, cheap, pick any two.” In the world of IP licensing both sides of the customer-vendor dialogue can have many more degrees of freedom, but the message can be the same. Just what are those degrees of freedom, and what do the parties involved talk about?
We’ll talk about this in the context of security/cryptography IP and “licensing” (not “buying”). Buying is more part of Design Services, and not IP licensing. The difference is you license rights to use IP, while Design Services is generally about building to order with all rights to the content being owned by the customer at the end of the transaction. Obviously these models can overlap, but here we are talking about licensing re-usable/re-targetable IP, not pure Design Services.
Back to those degrees of freedom. Good, fast, cheap is a start, and in a way cover everything; but maybe we can agree that there are broader dimensions to these, like: features, performance, size, quality, power, support, integration, and price. Each of these dimensions can be a blog topic on its own, but we will briefly cover some of them today.
First features. What is “it” that you are looking for? How do you describe it, but also how do others describe it? Is this behavior standardized at all, can something standard be tuned to your needs, or is it a one-of-a-kind, i.e. custom? If it’s pretty standard feature list e.g. AES (*), then there is a good chance there is enough demand for it that you can find it pre-built. If it’s a bit more exotic e.g. 802.1ae MACsec (**), then there are likely to be very few sources of pre-built IP, and less likelihood that the features will meet your specific needs.
If we go with AES, it is important to know what modes of AES are required for your application(s), because the IP will be quite different. AES has been very successful as the new encryption standard, and there are many modes/variants of it: ECB, CBC, CTR, CCM, OFB, CFB, GCM, XTS, f8, XCBC, etc. AES also supports three key sizes for most variants 128/192/256-bit, depending on level of security required. It gets even more interesting when caching contexts is brought into it. Do you switch contexts often enough to make it worthwhile to cache them and, if so, how much context storage is the best working set size? Are you looking for an in-line or look-aside solution? These features can be selected somewhat a-la-carte, but performance enters into it as well. What sort of performance – throughput, latency, etc. – for which features, at what clock rate, in what process/library, with what restrictions? 10Gbps MACsec at 312.5MHz with fixed, ultra-low latency is quite a different beast from 100Mbps of AES-CCM at 100MHz. Quite different challenges and quite different size/power/price. Adding AES-GCM to AES-CCM IP is not trivial (it’s not just one letter different), so throwing this in as a checkbox item can have surprising impacts on size/power/price. Typically for AES solutions there are regions of solutions because the underlying architectures need to be different. Low/Medium/High throughput for sure, but GCM and XTS, for instance, really are quite different. Needing fixed, ultra-low latency 10Gpbs MACsec solution for a PHY, is very different from a 10Gbps XTS-AES solution for a disk storage solution. It’s not just about the 10Gbps, it’s also about the application areas.
We are only at performance at this point, but we have already crossed over into size/power/price, because what has to happen, and how fast it has to happen will have a big impact on how big it will be, how much power it will draw, and what it will cost because not all features and performance have the same challenge to it. 10Gbps AES-GCM in an FPGA is not the same beast as 10Gbps AES-GCM in a standard ASIC environment. One size does not always fit all. If you are very constrained on area, power, bus bandwidth, budget, etc. you may not be able to hit your targets for features and performance. The situation is over constrained and trade-offs are needed. You may want more than you can afford, and you have to scale your order back to fit your means. A good IP provider will help you discuss options and come to a selection.
How about quality? The definition of quality is conformance to requirements so, if the requirements are clearly defined, this becomes a matter of “proving” that what you’ve built and are going to deliver meets the requirements agreed to. Of course, it is pretty much impossible to prove this in the mathematical sense due to the size of the state space and/or affordability, but good IP comes with a sense that the provider has processes that converge on requirements. Some of this is standards awareness and compliance, some of this is documented and organized test plans and records, some of this is third-party checking, and of course reputation and track-record. IP that is rushed out without due care and attention, without industry-standard processes, and little documentation or re-use behind it is unlikely to be quality. And there is the tension between rapidly evolving standards and “proven” content. Obviously IP that is developed, delivered, and even integrated before standards freeze or enough time to test the standard cannot be “bullet proof” or “proven.” LRW-AES is a great example in the storage area where IP and silicon was developed on a standard that was new and was shown to be flawed.
Integration. The IP isn’t much use if it can’t be integrated. The IP provider will have used different set of tools to design, validate, analyze size/performance/power trade offs and build environments/scripts/documentation to help with the integration process at the customer end. Cadence’s RTL Compiler and Incisive Enterprise Simulator are for example two of the tools Elliptic relies on to achieve its goals of providing superior quality IP and help with the integration process via sample scripts and environments. RTL Compiler’s PLE capability helps greatly with more accurate timing, area and power modeling of the RTL based IP portfolio.
However, IP integration can get very contentious i.e. finger-pointing. Integration suggests there is a context to bring the IP into. In the case of silicon IP delivered as RTL: will this be integrated into a Verilog or VHDL environment, what EDA tools and flows are being used, what process (libraries, memories) will this be integrated into? The process/libraries/memories used, and the integration flow and tools can make huge differences in the requirements and size/power of the IP. The combination of content and methodology can make it impossible for the IP to work – quite a few people have met situations where there is almost no timing margin left before the IP is inserted in the circuit. The IP can’t be “fixed” in most of these situations. Engineering trade-offs are needed. Integration needs to be thought about as early as possible, and if there is no bandwidth, power, or timing to use, frankly no IP will do. Generally now it is not possible or reasonable to over-constrain a lot. Some negotiation is necessary. If the content and/or integrator was cheap, or the tools are not up to par, maybe that trade-off needs re-thinking.
Support. What are your needs/expectations on support, and does this match what you are paying and what the IP provider is supplying? If you went shopping for rock bottom price, for content you really don’t understand how to use, and you are looking for a lot of hand-holding, then it may be wise to contract in some support beyond the basics. If it is all about price, and you get that, don’t expect that unlimited support comes with this or a no-extra-charge training course on how to use what you’ve ordered. No IP provider, even one with quality IP can afford to do that. If domain expertise and downstream responses are expected, expect to pay for that.
Price. Going into a restaurant you can’t afford to eat in is typically not going to end well. Higher prices in a lot of restaurants does mean a better dining experience – ambiance, service, selection, preparation, delivery – in a lot of cases. Going to a drive-through and expecting a fine night of dinner and dancing is as senseless as going to a nice restaurant and expecting drive-through prices. Similarly, looking for golden, silicon-proven IP, customized to your needs, with hand-holding for all your integration partners, at drive-though prices likely won’t end well. Part of the value of the better restaurant or IP provider is that there is continuity and a breadth and depth of expertise on how to solve issues in their spaces and, just as importantly, helping select IP that will suit your needs so that issues don’t arise later. Check references where possible and get to know the provider and its strengths.
A good IP provider will also have thought about what reasonable variants of all possible solutions are really going to be useful and in demand, and prepare those in advance much like the restaurant will set up its menu with a variety of palates in mind. At Elliptic Technologies we’ve done all that … we’ve helped people before and after licensing and we’ve done some incredible things with customers to tune solutions to their particular needs …
To conclude, selecting and integrating IP is quite often much more than what meets the eye. There are many dimensions to consider in this process, like features, performance, size, quality, power, support, integration and price. Try to make a distinction between what you want versus what you need (know what you are looking for and know what you can afford). Talk to your IP provider, hardware and software teams and discuss options.
So, when someone comes looking for an “AES solution”, and doesn’t know much more than that, understand that this just starts a dialogue…
(*) “AES” stands for Advanced Encryption Standard, the successor to the venerable DES, or Data Encryption Standard, used for symmetric encryption and other related cryptographic activities.
(**) 802.1ae “MACsec” is the standard for layer 2 port security – MAC Security Standard.
Login »
CLP-630: Multi-Packet Manager Security Engine