English
32G LR Multi-Protocol SerDes (MPS) PHY - GLOBALFOUNDRIES 22nm
Designing Around an Encrypted Netlist: Is The Pain Worth the Gain?
Mr. Scott Barrick Mentor Graphics Corporation
Spokane, WA USA
Oftentimes, in order to save on the cost of IP, a company will select an encrypted netlist as the deliverable instead of the RTL source code. This is especially common among companies looking to develop in FPGA devices where they can often get the necessary IP from their FPGA vendor.
But does using an encrypted netlist really save money? The answer may surprise a lot of IP integrators and their managers as the upfront savings can quickly disappear when they run into problems integrating an encrypted netlist.
This paper discusses the often overlooked issues of designing around an encrypted netlist. Critical areas of discussion include: encrypted netlist configurations versus source code configuration options, place & route issues, simulation and debug challenges, and support (or lack thereof). The position of this paper is that source code has many inherent benefits to justify the additional costs over using an encrypted netlist and will assign theoretical dollar amounts to various scenarios to illustrate this point.
DESIGNING AROUND AN ENCRYPTED NETLIST: IS THE PAIN WORTH THE GAIN?
There is a trend developing in the IP industry today regarding the use of encrypted IP deliverables, which is being driven by the surging popularity of FPGA design and the types of IP licenses offered.
Before this paper goes any further, let’s discuss exactly what is meant by Register Transfer Level (RTL) source code and an encrypted netlist or IP.
RTL source code refers to the actual source files in clear text that can be compiled directly into a hardware platform. Whether it’s Verilog, VHDL, or C. Encrypted IP is a reduced access version of the RTL source code or the netlist equivalent after going through some type of encryption algorithm that prevents a user from having the ability to see the source files, but still allows selected tools to compile the code.
On the surface, it seems an encrypted netlist provided by the FPGA vendor is the more prudent way to approach IP integration as opposed to purchasing RTL source code. But a netlist can easily turn to an unexpected liability if a minor “setback” should present itself, let alone should anything truly major happen during the IP integration process.
The first major difference an IP integrator quickly realizes between these two deliverables is if the IP core requires a GUI interface for configuring the IP. The GUI allows IP integrators to make decisions about the various options that can be implanted as they integrate the IP core into a design.
For example, with a GUI you can often choose the depth of a FIFO block, or with USB designs, the number of end-points supported. If you change your mind later, you can go back to the GUI and regenerate the code, or add a feature back into the GUI that was previously removed. With encrypted deliverables, this convenient feature becomes a hassle as the IP vendor will usually generate the files based on the IP user’s pre-determined answers to the configuration options. If you discover later that you need to make an alteration based on a design change, or that your initial selections aren’t correct, in most situations you’ll have to go back to the IP vendor and ask for a new deliverable. This not only can add days to your schedule, but it may require you to pay additional fees based on the licensing agreement. Suddenly, you’ve paid for the same IP twice and endured lost engineering time waiting for the new encrypted files.
Figure 1. Configuration GUI example for a USB controller.
This is just one critical area that needs to be addressed in the decision process of whether an encrypted deliverable is more beneficial than source code for your IP needs. So before that PO is sent, let’s take a look at some of the other critical areas that need to be considered.
PLACE AND ROUTE:
I. Predefined routing or resource usage
Besides having to worry about whether an IP core is functionally correct, it still won’t work unless the IP integrator is able to ensure that the core meets timing requirements in whatever process is targeted or FPGA device is planned.
With source code, IP integrators have more flexibility because they have complete control over the layout of the core. Meeting the required clock speeds and I/O timing are the only constraints that the integrator has to worry about. While most types of encrypted IP for ASIC implementations still give the integrator a lot of flexibility when timing the core, it’s the FPGA integrators who can be severely limited in their options. Most encrypted IP for FPGA devices is delivered in netlist format with a complete constraint file that declares the I/O signals and internal routing options. While most IP vendors will disclose the resource usage for their IP cores, it’s not always clear how many dedicated clock pins are used or how many of the high-speed routing lanes are necessary to time the IP core. Since the IP vendor has the entire FPGA device’s resources available to time the IP during development, once integrated into a customer design, those same resources need to be shared by the entire design.
However, since the IP is encrypted, the integrator might not have the ability to change the routing options, or identify the critical timing paths to adjust the routing. This might cause a relatively inexpensive IP core to suddenly require a larger FPGA device in order to have enough dedicated clock pins to time the entire design. For example, say a 10-Gigabit Ethernet subsystem was to be integrated into an FPGA device that costs $10 a piece, yet the encrypted IP consumed too many of the global clock resources. As a result, the device has to be upgraded to a $15 part in order to time the entire design. The initial $40,000 dollars saved on the IP purchase would be consumed after only 8,000 units.
Conversely, if the integrator had access to the source code for the Ethernet subsystem, he may only need to re-route a few low-speed, low fan-out clocks on regular I/O pins and still have implemented the entire design on the original $10 piece, saving thousands of dollars over the life of the product.
II. Reuse of internal logic
One of the primary reasons companies license IP is to avoid reinventing the wheel, or to fill a requirement that they do not have the expertise or resources to develop internally. However, by licensing encrypted IP they are robbing themselves of the ability to reuse portions of the IP in other parts of the design. An 8b/10b encoder/decoder for example, can be found in many of the standards based communication protocols like Ethernet, SATA, or PCI-Express. If a company licenses their PCI-Express controller as encrypted IP, they will not have access to the 8b/10b encoder as it is encrypted and embedded inside the black box that is the IP core.
So now if the design requires an 8b/10b encoder in another section of the design, IP users will need to develop this block in-house. Not only will they have to develop a common block for another part of the same design, but they will also need to verify the coding tables where the likelihood for error is greater than if they were simply able to reuse the proven 8b/10b block from the PCI-Express controller. Looking monetarily at this scenario, while an IP integrator might have saved $60,000 on the PCI-Express controller, when factoring in the design and verification time of the 8b/10b block, the savings diminish quickly and any error in the coding tables not caught prior to tape-out could end up costing millions in re-spin costs.
If we look at the same situation only this time the PCI-Express controller was licensed as RTL source code, all that is required is to instantiate the 8b/10b sub-module in the design and continue with the development of custom logic and value add.
SIMULATION:
I. Slower simulation times
Since a majority of encrypted IP cores are delivered as netlists, the simulation time required for the entire design is slowed as simulators are unable to perform optimization routines on the netlists to speed up simulation times. Unless the IP vendor includes a behavioral model for the encrypted IP core, which is pretty rare, the IP user is stuck with using the encrypted netlist in their simulation environments. While not as efficient as a behavioral model, RTL source code can still be optimized by a simulator for faster run times when compared to the netlist equivalent.
While simulation times are not often considered in determining the type of IP deliverable to purchase, the long term implications can be very costly. If you consider a complex protocol like USB, whose simulation run times can take days to verify even when using RTL code, any increase in simulation run time can add days or weeks to the schedule. If we consider Mentor’s USB OTG controller as an example, the complete verification suite takes 18 hours to run on a multi-CPU grid using the RTL source code. The same verification suite takes approximately 63 hours on the same grid when using an encrypted version of the controller. This is a 3.5x increase in simulation time, just at the controller level. Once integrated into a complete chip-level verification suite (which can take days to run) an encrypted IP core can add weeks to the verification schedule. There are not many product managers who would trade adding a week to a release schedule every time a complete regression is required just to save $50,000 on an IP core.
II. Predetermined tool flows
Due to the vast number of software tools on the market to help chip designers, only a few companies use the exact same tool flow. This is why having the ability to use an IP core on any tool is something IP vendors strive for whenever possible. However, once an encrypted IP core is being considered the available tool set becomes severely limited by the type of encryption method used. This is why FPGA vendors develop their own encryption tools so that their internal IP cores cannot be used on their competitor’s products. While no company will purchase an IP core that won’t work on their established tool flow, it is only later in the product life cycle when the tool flow changes that they discover their encrypted IP purchase no longer works and they are now stuck with an unusable design. CAD managers will not be happy with having to purchase tens of thousands of dollars worth of software tools so their $5,000 IP core can still be used. This is not a problem when licensing RTL source code, as source code is almost always tool independent.
DEBUG:
I. The black hole
The goal of every IP vendor is to offer a bug-free core. But just about every IP integrator will tell you it’s the rare occasion when a bug is not found. So why would an IP integrator license an IP core that prevents them from being able to solve their own issues? Even if the IP integrator cannot ultimately fix the IP core after finding the problem, when provided with RTL source code, they can isolate the issue to a given section of code to speed up the IP vendors debug phase. With encrypted IP they are all but helpless when putting “x” into the IP black box which outputs “z” instead of “y.”
Without question, there are reputable IP vendors who will work with the IP user to solve the problem. But will the IP vendor have the same urgency or work on the same schedule? Does the $35,000 in savings look as attractive now when the entire project is held up because the only engineers who can work on the issue don’t even work for your company? Even if the IP integrator did not design the IP core, given access to the RTL source code might allow them to figure out the issue when a tape-out is looming. By licensing encrypted IP, a company is putting handcuffs on their best assets by preventing anyone from fixing the company’s own products. A missed tape-out costs a lot more than an additional $35,000 upfront to ensure their project was not dependent on another company. It’s not a bad idea to consider the additional cost of licensing RTL source code as insurance so that if required, your engineers have the necessary tools to fix any problem they might encounter.
II. Tool issue vs. actual RTL issue
Another issue that is often not considered goes beyond worrying about whether the IP core contains bugs or not. Adding an encryption layer to the IP core introduces another variable that can affect the core. If the IP integrator encounters this variable, they do not have the ability to determine if the problem is in the IP core or if it was introduced by the encryption method. While the IP vendor can determine whether the issue is related to the core or the encryption method by determining if the bug exists in the unencrypted version of the IP, this can add additional delay to the customer’s schedule. If the issue actually resides with the encryption scheme, the IP integrator is now delayed over a tool issue and is dependent on the tool vendor for fixing the problem.
By licensing RTL source code, the additional risk associated with this type of issue is completely removed. While a single day’s delay won’t consume the cost savings associated with licensing an encrypted version of the IP core, a five day delay certainly will.
SUPPORT:
Revision control difficult
Usually one of the first items IP vendors want to know when a possible bug has been reported is the version of the core. Besides the overall version of the IP core, each file contains its own revision number. These numbers are used by the IP vendor to determine the version of the IP core the customer owns. However, when providing the customer with an encrypted version of the IP core, these revision numbers get embedded in the encrypted files and are not visible to the customer unless they are part of the file name. An IP vendor has no way of determining what version of the IP core was used to generate the encrypted files the customer is using, unless the IP vendor kept the original files used to create the encrypted version.
It’s also difficult to know if the customer received an updated version of the files due to a new release. With encrypted files, the IP integrator has only the file name to work with in trying to determine which version of the core they used in the design. While usually not an issue for an active project, this could become an issue years later when they need to update the project files, or try to determine which version of the IP was used successfully in past designs.
All of these issues are removed when using RTL source code with the IP core.
LICENSE ISSUES:
Time controlled vs. permanent
One reason encrypted IP cores are so much cheaper than their RTL source code counterparts is due to the ability of the IP vendor to limit the time frame the encrypted version will work. This occurs by tying the license file needed to decrypt the IP core to a software tool license that once expires, will no longer work. While this is a totally valid business model, what happens when the design project runs longer than expected and the IP customer needs to purchase an additional license to continue working? Or if the design needs to be updated after the license file expires? Or if additional chips are required due to unexpected demand for the product and the design can no longer be compiled?
The end result is the IP customer will have to purchase an additional license and the original cost difference becomes smaller each time, but the license limitations are still present. For example, say a company licenses an encrypted Parallel ATA controller for $9,000 instead of paying $32,000 for the RTL source code and then receives a license file good for one year. If the product is still selling three years later, the company has paid $27,000 for that same controller. The difference between the encrypted version and the RTL source code is now only $5,000! If they require another one-year license, they actually end up paying more for the core, than if they had licensed the RTL originally, which does not have time restrictions on use.
Figure 2. Chart showing the cost of Parallel ATA controller over time when using a time-limited encrypted version vs. RTL source code.
Also, when using license files for encrypted IP cores, the IP integrator might be limited to a certain number of workstations. There may also be limits to certain design locations. Most IP vendors will allow an RTL source code version of the IP core to be used on any number of workstations in multiple locations within the same company or division.
DESIGN SERVICES
In order to help accelerate the schedule of new projects, some companies will use “design services” as part of their project development. Often this involves providing the design service company with design files and IP cores. Because the design company was not part of the original IP purchasing decision, it is not uncommon for the design service company’s tool flow or their ability to integrate an encrypted IP core to be at a serious mismatch which would incur additional costs.
Whether restricted by license files or tool flows, working with a design service company is another example of where issues can be avoided by using the RTL source code of the IP core instead of the encrypted version. Since the cost of the IP is often a fraction of the cost of the services provided by the design service company, the thousands of dollars in savings on an IP core can be quickly consumed if the design service company has to purchase additional tools or license files in order to complete the work.
WHY USE ENCRYTPED IP?
With all of the drawbacks discussed in this paper, why do IP integrators continue to use encrypted IP? A few of the more popular reasons include:
I. Cost
Cost is the primary reason for using encrypted IP, assuming the integration and verification of the IP are problem free, especially in low-volume applications. In this scenario expected units are in the hundreds and unit costs need to remain low. Encrypted IP can keep the per unit cost of the IP under $100 where you generally need to have thousands of units before the RTL source code per unit cost gets that low.
II. Drop-in capabilities
Another situation is when the IP core does not need to be optimized for the design to have success. This allows for a true drop-in application since the IP core is not going to be utilized at close to the maximum throughput capabilities.
III. Pre-verified by FPGA vendor
Licensing an encrypted IP core from your intended FPGA vendor is usually the cheapest option since they use IP cores to help secure the design win and offer the best pricing for encrypted netlist versions of their IP cores. However, the big disadvantage is that you are now stuck with the products of that FPGA vendor which usually means you’re tied to a specific product family.
This also provides a single point of contact for issues related to the IP core. There cannot be any finger pointing as to whether the problem is with the encrypted IP or the software tool. However, IP vendors that support encrypted IP for FPGA devices have usually verified their IP in the FPGA vendor’s tool flow so this situation is rare even for 3rd party FPGA IP vendors.
CONCLUSION
So in the end, it’s the initial cost for RTL source code that usually drives companies toward the encrypted version as an alternative. The general consensus is that with integration and verification costs being equal, one can save significant money by purchasing the encrypted netlist. However, as shown in this paper, there are a number of hidden costs associated with encrypted IP that are not factored into the basic cost equation. One explanation for this might be focusing on the size of the PO rather than the steps required getting to the finish line. As shown in Figure 3 encrypted IP will be cheaper upfront, but once you add in the hidden costs associated with place & route, simulation, debug, support, licensing, and design services, the cheaper and ultimately the more prudent solution is RTL source code.
Figure 3. Graph showing estimated costs across the entire design cycle of the IP core while using RTL source code vs. the encrypted version – both with and without the hidden costs
Spokane, WA USA
Oftentimes, in order to save on the cost of IP, a company will select an encrypted netlist as the deliverable instead of the RTL source code. This is especially common among companies looking to develop in FPGA devices where they can often get the necessary IP from their FPGA vendor.
But does using an encrypted netlist really save money? The answer may surprise a lot of IP integrators and their managers as the upfront savings can quickly disappear when they run into problems integrating an encrypted netlist.
This paper discusses the often overlooked issues of designing around an encrypted netlist. Critical areas of discussion include: encrypted netlist configurations versus source code configuration options, place & route issues, simulation and debug challenges, and support (or lack thereof). The position of this paper is that source code has many inherent benefits to justify the additional costs over using an encrypted netlist and will assign theoretical dollar amounts to various scenarios to illustrate this point.
DESIGNING AROUND AN ENCRYPTED NETLIST: IS THE PAIN WORTH THE GAIN?
There is a trend developing in the IP industry today regarding the use of encrypted IP deliverables, which is being driven by the surging popularity of FPGA design and the types of IP licenses offered.
Before this paper goes any further, let’s discuss exactly what is meant by Register Transfer Level (RTL) source code and an encrypted netlist or IP.
RTL source code refers to the actual source files in clear text that can be compiled directly into a hardware platform. Whether it’s Verilog, VHDL, or C. Encrypted IP is a reduced access version of the RTL source code or the netlist equivalent after going through some type of encryption algorithm that prevents a user from having the ability to see the source files, but still allows selected tools to compile the code.
On the surface, it seems an encrypted netlist provided by the FPGA vendor is the more prudent way to approach IP integration as opposed to purchasing RTL source code. But a netlist can easily turn to an unexpected liability if a minor “setback” should present itself, let alone should anything truly major happen during the IP integration process.
The first major difference an IP integrator quickly realizes between these two deliverables is if the IP core requires a GUI interface for configuring the IP. The GUI allows IP integrators to make decisions about the various options that can be implanted as they integrate the IP core into a design.
For example, with a GUI you can often choose the depth of a FIFO block, or with USB designs, the number of end-points supported. If you change your mind later, you can go back to the GUI and regenerate the code, or add a feature back into the GUI that was previously removed. With encrypted deliverables, this convenient feature becomes a hassle as the IP vendor will usually generate the files based on the IP user’s pre-determined answers to the configuration options. If you discover later that you need to make an alteration based on a design change, or that your initial selections aren’t correct, in most situations you’ll have to go back to the IP vendor and ask for a new deliverable. This not only can add days to your schedule, but it may require you to pay additional fees based on the licensing agreement. Suddenly, you’ve paid for the same IP twice and endured lost engineering time waiting for the new encrypted files.
Figure 1. Configuration GUI example for a USB controller.
This is just one critical area that needs to be addressed in the decision process of whether an encrypted deliverable is more beneficial than source code for your IP needs. So before that PO is sent, let’s take a look at some of the other critical areas that need to be considered.
PLACE AND ROUTE:
I. Predefined routing or resource usage
Besides having to worry about whether an IP core is functionally correct, it still won’t work unless the IP integrator is able to ensure that the core meets timing requirements in whatever process is targeted or FPGA device is planned.
With source code, IP integrators have more flexibility because they have complete control over the layout of the core. Meeting the required clock speeds and I/O timing are the only constraints that the integrator has to worry about. While most types of encrypted IP for ASIC implementations still give the integrator a lot of flexibility when timing the core, it’s the FPGA integrators who can be severely limited in their options. Most encrypted IP for FPGA devices is delivered in netlist format with a complete constraint file that declares the I/O signals and internal routing options. While most IP vendors will disclose the resource usage for their IP cores, it’s not always clear how many dedicated clock pins are used or how many of the high-speed routing lanes are necessary to time the IP core. Since the IP vendor has the entire FPGA device’s resources available to time the IP during development, once integrated into a customer design, those same resources need to be shared by the entire design.
However, since the IP is encrypted, the integrator might not have the ability to change the routing options, or identify the critical timing paths to adjust the routing. This might cause a relatively inexpensive IP core to suddenly require a larger FPGA device in order to have enough dedicated clock pins to time the entire design. For example, say a 10-Gigabit Ethernet subsystem was to be integrated into an FPGA device that costs $10 a piece, yet the encrypted IP consumed too many of the global clock resources. As a result, the device has to be upgraded to a $15 part in order to time the entire design. The initial $40,000 dollars saved on the IP purchase would be consumed after only 8,000 units.
Conversely, if the integrator had access to the source code for the Ethernet subsystem, he may only need to re-route a few low-speed, low fan-out clocks on regular I/O pins and still have implemented the entire design on the original $10 piece, saving thousands of dollars over the life of the product.
II. Reuse of internal logic
One of the primary reasons companies license IP is to avoid reinventing the wheel, or to fill a requirement that they do not have the expertise or resources to develop internally. However, by licensing encrypted IP they are robbing themselves of the ability to reuse portions of the IP in other parts of the design. An 8b/10b encoder/decoder for example, can be found in many of the standards based communication protocols like Ethernet, SATA, or PCI-Express. If a company licenses their PCI-Express controller as encrypted IP, they will not have access to the 8b/10b encoder as it is encrypted and embedded inside the black box that is the IP core.
So now if the design requires an 8b/10b encoder in another section of the design, IP users will need to develop this block in-house. Not only will they have to develop a common block for another part of the same design, but they will also need to verify the coding tables where the likelihood for error is greater than if they were simply able to reuse the proven 8b/10b block from the PCI-Express controller. Looking monetarily at this scenario, while an IP integrator might have saved $60,000 on the PCI-Express controller, when factoring in the design and verification time of the 8b/10b block, the savings diminish quickly and any error in the coding tables not caught prior to tape-out could end up costing millions in re-spin costs.
If we look at the same situation only this time the PCI-Express controller was licensed as RTL source code, all that is required is to instantiate the 8b/10b sub-module in the design and continue with the development of custom logic and value add.
SIMULATION:
I. Slower simulation times
Since a majority of encrypted IP cores are delivered as netlists, the simulation time required for the entire design is slowed as simulators are unable to perform optimization routines on the netlists to speed up simulation times. Unless the IP vendor includes a behavioral model for the encrypted IP core, which is pretty rare, the IP user is stuck with using the encrypted netlist in their simulation environments. While not as efficient as a behavioral model, RTL source code can still be optimized by a simulator for faster run times when compared to the netlist equivalent.
While simulation times are not often considered in determining the type of IP deliverable to purchase, the long term implications can be very costly. If you consider a complex protocol like USB, whose simulation run times can take days to verify even when using RTL code, any increase in simulation run time can add days or weeks to the schedule. If we consider Mentor’s USB OTG controller as an example, the complete verification suite takes 18 hours to run on a multi-CPU grid using the RTL source code. The same verification suite takes approximately 63 hours on the same grid when using an encrypted version of the controller. This is a 3.5x increase in simulation time, just at the controller level. Once integrated into a complete chip-level verification suite (which can take days to run) an encrypted IP core can add weeks to the verification schedule. There are not many product managers who would trade adding a week to a release schedule every time a complete regression is required just to save $50,000 on an IP core.
II. Predetermined tool flows
Due to the vast number of software tools on the market to help chip designers, only a few companies use the exact same tool flow. This is why having the ability to use an IP core on any tool is something IP vendors strive for whenever possible. However, once an encrypted IP core is being considered the available tool set becomes severely limited by the type of encryption method used. This is why FPGA vendors develop their own encryption tools so that their internal IP cores cannot be used on their competitor’s products. While no company will purchase an IP core that won’t work on their established tool flow, it is only later in the product life cycle when the tool flow changes that they discover their encrypted IP purchase no longer works and they are now stuck with an unusable design. CAD managers will not be happy with having to purchase tens of thousands of dollars worth of software tools so their $5,000 IP core can still be used. This is not a problem when licensing RTL source code, as source code is almost always tool independent.
DEBUG:
I. The black hole
The goal of every IP vendor is to offer a bug-free core. But just about every IP integrator will tell you it’s the rare occasion when a bug is not found. So why would an IP integrator license an IP core that prevents them from being able to solve their own issues? Even if the IP integrator cannot ultimately fix the IP core after finding the problem, when provided with RTL source code, they can isolate the issue to a given section of code to speed up the IP vendors debug phase. With encrypted IP they are all but helpless when putting “x” into the IP black box which outputs “z” instead of “y.”
Without question, there are reputable IP vendors who will work with the IP user to solve the problem. But will the IP vendor have the same urgency or work on the same schedule? Does the $35,000 in savings look as attractive now when the entire project is held up because the only engineers who can work on the issue don’t even work for your company? Even if the IP integrator did not design the IP core, given access to the RTL source code might allow them to figure out the issue when a tape-out is looming. By licensing encrypted IP, a company is putting handcuffs on their best assets by preventing anyone from fixing the company’s own products. A missed tape-out costs a lot more than an additional $35,000 upfront to ensure their project was not dependent on another company. It’s not a bad idea to consider the additional cost of licensing RTL source code as insurance so that if required, your engineers have the necessary tools to fix any problem they might encounter.
II. Tool issue vs. actual RTL issue
Another issue that is often not considered goes beyond worrying about whether the IP core contains bugs or not. Adding an encryption layer to the IP core introduces another variable that can affect the core. If the IP integrator encounters this variable, they do not have the ability to determine if the problem is in the IP core or if it was introduced by the encryption method. While the IP vendor can determine whether the issue is related to the core or the encryption method by determining if the bug exists in the unencrypted version of the IP, this can add additional delay to the customer’s schedule. If the issue actually resides with the encryption scheme, the IP integrator is now delayed over a tool issue and is dependent on the tool vendor for fixing the problem.
By licensing RTL source code, the additional risk associated with this type of issue is completely removed. While a single day’s delay won’t consume the cost savings associated with licensing an encrypted version of the IP core, a five day delay certainly will.
SUPPORT:
Revision control difficult
Usually one of the first items IP vendors want to know when a possible bug has been reported is the version of the core. Besides the overall version of the IP core, each file contains its own revision number. These numbers are used by the IP vendor to determine the version of the IP core the customer owns. However, when providing the customer with an encrypted version of the IP core, these revision numbers get embedded in the encrypted files and are not visible to the customer unless they are part of the file name. An IP vendor has no way of determining what version of the IP core was used to generate the encrypted files the customer is using, unless the IP vendor kept the original files used to create the encrypted version.
It’s also difficult to know if the customer received an updated version of the files due to a new release. With encrypted files, the IP integrator has only the file name to work with in trying to determine which version of the core they used in the design. While usually not an issue for an active project, this could become an issue years later when they need to update the project files, or try to determine which version of the IP was used successfully in past designs.
All of these issues are removed when using RTL source code with the IP core.
LICENSE ISSUES:
Time controlled vs. permanent
One reason encrypted IP cores are so much cheaper than their RTL source code counterparts is due to the ability of the IP vendor to limit the time frame the encrypted version will work. This occurs by tying the license file needed to decrypt the IP core to a software tool license that once expires, will no longer work. While this is a totally valid business model, what happens when the design project runs longer than expected and the IP customer needs to purchase an additional license to continue working? Or if the design needs to be updated after the license file expires? Or if additional chips are required due to unexpected demand for the product and the design can no longer be compiled?
The end result is the IP customer will have to purchase an additional license and the original cost difference becomes smaller each time, but the license limitations are still present. For example, say a company licenses an encrypted Parallel ATA controller for $9,000 instead of paying $32,000 for the RTL source code and then receives a license file good for one year. If the product is still selling three years later, the company has paid $27,000 for that same controller. The difference between the encrypted version and the RTL source code is now only $5,000! If they require another one-year license, they actually end up paying more for the core, than if they had licensed the RTL originally, which does not have time restrictions on use.
Figure 2. Chart showing the cost of Parallel ATA controller over time when using a time-limited encrypted version vs. RTL source code.
Also, when using license files for encrypted IP cores, the IP integrator might be limited to a certain number of workstations. There may also be limits to certain design locations. Most IP vendors will allow an RTL source code version of the IP core to be used on any number of workstations in multiple locations within the same company or division.
DESIGN SERVICES
In order to help accelerate the schedule of new projects, some companies will use “design services” as part of their project development. Often this involves providing the design service company with design files and IP cores. Because the design company was not part of the original IP purchasing decision, it is not uncommon for the design service company’s tool flow or their ability to integrate an encrypted IP core to be at a serious mismatch which would incur additional costs.
Whether restricted by license files or tool flows, working with a design service company is another example of where issues can be avoided by using the RTL source code of the IP core instead of the encrypted version. Since the cost of the IP is often a fraction of the cost of the services provided by the design service company, the thousands of dollars in savings on an IP core can be quickly consumed if the design service company has to purchase additional tools or license files in order to complete the work.
WHY USE ENCRYTPED IP?
With all of the drawbacks discussed in this paper, why do IP integrators continue to use encrypted IP? A few of the more popular reasons include:
I. Cost
Cost is the primary reason for using encrypted IP, assuming the integration and verification of the IP are problem free, especially in low-volume applications. In this scenario expected units are in the hundreds and unit costs need to remain low. Encrypted IP can keep the per unit cost of the IP under $100 where you generally need to have thousands of units before the RTL source code per unit cost gets that low.
II. Drop-in capabilities
Another situation is when the IP core does not need to be optimized for the design to have success. This allows for a true drop-in application since the IP core is not going to be utilized at close to the maximum throughput capabilities.
III. Pre-verified by FPGA vendor
Licensing an encrypted IP core from your intended FPGA vendor is usually the cheapest option since they use IP cores to help secure the design win and offer the best pricing for encrypted netlist versions of their IP cores. However, the big disadvantage is that you are now stuck with the products of that FPGA vendor which usually means you’re tied to a specific product family.
This also provides a single point of contact for issues related to the IP core. There cannot be any finger pointing as to whether the problem is with the encrypted IP or the software tool. However, IP vendors that support encrypted IP for FPGA devices have usually verified their IP in the FPGA vendor’s tool flow so this situation is rare even for 3rd party FPGA IP vendors.
CONCLUSION
So in the end, it’s the initial cost for RTL source code that usually drives companies toward the encrypted version as an alternative. The general consensus is that with integration and verification costs being equal, one can save significant money by purchasing the encrypted netlist. However, as shown in this paper, there are a number of hidden costs associated with encrypted IP that are not factored into the basic cost equation. One explanation for this might be focusing on the size of the PO rather than the steps required getting to the finish line. As shown in Figure 3 encrypted IP will be cheaper upfront, but once you add in the hidden costs associated with place & route, simulation, debug, support, licensing, and design services, the cheaper and ultimately the more prudent solution is RTL source code.
Figure 3. Graph showing estimated costs across the entire design cycle of the IP core while using RTL source code vs. the encrypted version – both with and without the hidden costs
|
||||||
Related Articles
New Articles
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
- Timing Optimization Technique Using Useful Skew in 5nm Technology Node
- Streamlining SoC Design with IDS-Integrate™
Most Popular
|
E-mail This Article | 
|
|
Printer-Friendly Page |