The Challenge of Keeping IP Usable

by Phil Rose, Cadence Design Systems
Livingston, Scotland, UK
   
Abstract:

To provide SoC developers with truly useful Semiconductor IP it is important that suppliers are proactive in keeping IP current with respect to related standards, as well as leading edge with respect to features.

IP suppliers often fill the role of application specialists for their customers, often keeping close to the use of the IP under some manner of post sales integration support. Where customers ask for changes to the core design it is critical that the supplier can provide feedback on the changes as well as support in enabling these to be carried out.

Often the requested change may be more complex than the user realized or indeed may not be achievable, however in many cases additional features suggested by customers can add to the value of the IP for existing and new customers alike.

In other cases changes are customer specific and would not add value to other customers – yet there should be mechanisms in place to support this type of request as it may be critical for the customer.

There are many and varied reasons as to why an IP core might need to be changed

• improving the feature set
• providing an upgrade path to support changes in immature standards
• adding portability between ASIC & FPGA, particularly as emulation use increases
• technology advances

There are issues with making design changes – for example an IP core that has repeatedly seen silicon is more reliable than one that is continually being updated with new features

Who should implement the changes – the vendor or the user? Technically the vendor, familiar with the design and the associated industry standard, is well placed to implement and verify the changes. Commercially it’s a double-edged sword as there is often a cost associated with the vendor making changes. However if the user makes the changes this can impact the warranty for the core.

Cadence has gained tremendous experience of IP development both as an IP supplier and an IP user. In this paper we look at the issues mentioned above and discuss how we deal with these to provide maximum benefit to our customers.

BACKGROUND

Intellectual Property as represented in semiconductor designs (IP Cores) has now developed into a considerable market. Application developers are now relying on suppliers of IP Cores to provide the components that they do not want to design themselves. Typically components fall into three categories: Star IP – high-value cores such as processors; Peripheral IP – the basic building blocks that all designs require; and Standards-based IP – cores that have been developed to implement complex bus and communications interfaces.

Star IP is high-value and requires man-decades of verification It will have a large detailed specification, but one that readily breaks down into well documented atomic functional quanta. The instruction set of a CPU core is the perfect example of this.

Peripheral IP is low-value. It will typically have a single function with limited configurability, but is normally a well specified small component. An example could be a Watchdog Timer block.

Standards-based IP is much less clear cut. Communications protocols such as Ethernet or PCI Express have a complex specification, and the functionality is not readily analysed into a number of autonomous activities. With a new standard, as it evolves and gets adopted by the application companies, then its use model matures. The application of features becomes understood and new requirements are introduced.

Application companies want to use all these categories of cores, together with their own intellectual contribution, to develop their product to meet their particular market place. When a number of different application companies are addressing the same market then this may not be sufficient enough to differentiate their product, especially when a similar platform base is used, as supplied by the IP vendors. In this case they would like to see functionality migrate from the application-specific components to the platform base to improve the feature set or the functional performance of the product.

CHANGES

Requirements to update IP have a number of sources. Firstly, there is internal pressure to improve the product: add to its feature list; improve the performance, and so on. This may be particularly true of Star IP. Inertia builds up within a design team for improvement. For example, within a processor, we have seen improvements to the pipeline architecture, size and geometry of caches, et cetera, as generations of CPU get released by vendors such as ARM.

Secondly, where a standard has yet to be ratified, the IP vendor has a dilemma. The user community expects to find Cores available to implement the standard as soon as it is ratified, yet expect the same level of quality as in provided for standards that have been available for years.

Extending from this, during the initial take-up of a standard by the user community, new requirements may arise. These are not necessarily to address deficiencies with the standard, but supply enhancements that more greatly benefit the application developers. For example, during the initial take-up of the PCI Express standard, the PIPE interface which standardized the interface between controllers and PHYs was proposed. This allows the users greater choice in suppliers for the various components to implement a PCI Express solution for the Application product.

When supplying IP to users, we are very interested in how they make use of it. There can be a healthy exchange of ideas between the supplier and the user. One outcome of this is the identification of useful features, by which the IP core can be improved. Generally these are features which would involve very little hardware to implement but would otherwise cost the software designer a lot of instruction bytes or cycles to implement.

These are all changes in functionality aimed at improving the feature list of the IP. The underlying semiconductor technology also has an impact. It is well known that hard IP must continually track the changes in process. Soft IP is not wholly immune from this. The change to nanometric technologies has introduced problems whose effects ripple up the design chain, and may impact the RTL.

Low power design techniques must now be considered as leakage current is now significant at 90 nm. In addition power consumption itself has become an important application feature with the explosion of hand-help devices onto the consumer market-place. Another problem caused not so much by the smaller gate size directly, but because it enables faster system clock speeds, is whether the design is tolerant to these faster frequencies. For example, simple cores may rely on counting bus clock cycles to implement timing control. Will a counter that had enough bits at 30 MHz still have enough at 300 MHz?

All these conspire to destabilize the design and implementation of a component that is being developed to be reused over and over.

CUSTOMISATION

IP vendors have tended to regard an IP component as being an ideal fit for the application developer. Occasionally, IP users will take all the bricks we vendors provide, cement them together and have a wonderful view through the holes in the wall. To mitigate against this the users will request that certain modifications get done, or request the right to modify the core themselves.

There are two approaches the user and vendor can take in this situation. The user will modify the core. In certain circumstances that I will address below, the vendor may supply this modification at no additional cost. Otherwise the user will have to pay for design services to modify the core.

Alternatively, the user may want to modify the core themselves. This is not always supported by the IP supplier and also opens up a number of contractual issues concerned with warranty, liability and ownership of the changes

CASE STUDY #1: ETHERNET CONTROLLER

Cadence has a strong portfolio of Ethernet components. These are standards-based IP that are maturing into commodity cores. There is a lot of competition in the market place for Fast Ethernet and Gigabit Ethernet controllers. We have to find ways of maintaining that competitive edge and we find that being flexible and providing additional features to the user is a good way of doing this.

 
Figure 1 Fast Ethernet Controller (MACB)

One important aspect of the design is the system interface. This is the main way that data is transferred from system memory into the controller buffers for transmission and vice-versa for reception. Figure 1 shows the block diagram of the Cadence MACB (Fast Ethernet Media Access Controller or MAC). This component was originally designed for a System-on-chip device that was based around the use of the AMBA ASB System bus. At this time AHB had recently been published and it was realized quickly that this was a more suitable interface for reusable designs.

This suited a lot of our customer base at the time. However, not every design will be a microprocessor-based system. As a result of requests from customers, we exposed an internal interface and supplied a FIFO front-end so that data could be pumped in and out using hardware control mechanisms.

The other important interface is to a PHY (physical layer) device. Fast Ethernet (100 Mb/s) requires mixed signal circuits, especially to detect receive data and recover clocks from the serial bit-stream. These circuits are available from a number of different vendors and although there is a standard in IEEE 802.3, the Media Independent Interface, there are several components (external as well as IP cores) with differing interfaces. The MII is a byte-wide interface and when used with external PHYs possibly requires too many pins. For this reason, a reduced 4-bit version (RMII) and a serial version (SMII) are now de-facto standards that have been incorporated into the Cadence portfolio. This support of alternative wrappers provides developers with a wider choice of PHY – which can directly reduce the cost of their final solution.

In addition changes to support different PHY management protocols (such as IEEE 802.3 clause 45) have been added.

IP integration issues do occur. Experience as both an IP developer and user has led us to understand the importance of ease of use and IP integration issues, and to reflect this through continually improving our development methodology We are also continually improving our development methodology. Taking on board the lessons learnt, we have made changes to improve the usability of the Fast Ethernet MAC. For example, the original design was clumsy in the implementation of the clocking. Minor changes to the design of the clocking structure allowed the core to more readily integrated into ASIC designs and allow the layout engineers to implement an ASIC-level clock and reset system.

Another requirement which is critical for many customers is to be able to carry out design emulation. Early in the development of the Ethernet MAC, FPGA performance was not as good as it is now, and both internal projects and customers had problems with attempting to achieve timing closure in an FPGA implementation. Redesigning the Ethernet MAC to close timing in FPGA would have made the design uncompetitive in an ASIC implementation. Designing in configuration at certain key points in the dataflow provides a low-risk way of achieving both timing closure for an FPGA implementation as well as higher performance for an ASIC implementation.

Advances in EDA technology have also had an impact on the design. Linting is now a fundamental part of most customers’ evaluation process. In the past, fixing lint warnings would seem to be counter-productive. Why change a design that has had significant silicon success? However, using formal logic equivalence tools such as Conformal, allows these modifications to be undertaken with greater confidence that you are not breaking the design. A cleaner lint report provides a better perception of quality of design.

The changes which have been discussed so far improve usability and in particular give developers added choice in how they connect to the Ethernet MAC. But they remain peripheral to the core functionality of the device. During the ongoing maintenance of the IP Core, we have introduced a number of functional enhancements that add functionality to the core, for example: automatic pause frames; improved buffer management in the DMA; allowing the reception of frames with CRC errors; support for magic packets and wake-on-LAN and jumbo frames.

These have been requested at some time by a customer, and after due consideration of the cost to implement against the added value that that functionality would add to the core, we have included the change in the standard IP product. In some cases, the changes are specific to the customer’s application or do not add value to the standard core. In these cases asked the customer to pay a charge. Sometimes, they do: sometimes, they don’t.

Cadence now offer a number of cores that support Fast, Gigabit and 10 Gigabit Ethernet in a number of combinations of bit-rates and with a number of interface widths – and the usefulness of these cores have been significantly improved through our willingness to address customers’ ongoing requirements.


CASE STUDY #2: PCI EXPRESS

PCI Express has been mooted for a number of years now. It appeared in the guise of 3G IO over three years ago. Here at Cadence, we made an early commitment to the technology and began development once early versions of the specification were made available through the PCI SIG. This decision brought its own risks, but these were recognized and the appropriate risk management action plans put in place.

We were involved in the PCI SIG discussions leading up to ratification of revision 1.0 of the base specification, so were able to comfortably track all the changes that were occurring and incorporate them into the design of the PCI Express core we were developing. We were well into the verification of the core when revision 1.0a appeared and nearly complete when errata to the specification were released. These errata specified several dozens of changes which had to be implemented and we faced the challenge of still meeting our overall timescales to get the Cadence PCI Express solution to market on time.

Cadence at that time were developing a complete solution involving link layer and physical coding sub-layer (PCS) as synthesizable IP and a Serdes as an analog hard IP with a standard ten-bit interface between the two. About a year ago the PIPE interface between link-layer and PCS was proposed and very quickly gained momentum within the industry. We had to rapidly instigate a development that inserted the PIPE interface between the two sections of our design so that we could offer a PIPE-compliant Serdes and maintain the complete solution.

Verification against a changing specification provides a dilemma. In order to get industry traction with PCI Express the standard’s sponsor provided a Bus Functional Model. We decided against incorporating this into our verification strategy for the core. At the time this seemed to act against us in trying to get customers interested in licensing our core. However the BFM is no longer being maintained so we would have had a difficult problem trying to maintain the verification environment against the background of the continual specification changes that were taking place.

We did realize that this internal verification was not sufficient, so started working with suppliers of verification IP, such as Denali, and have demonstrated interoperability between the Cadence design IP and the Denali verification IP at a number of industry shows.

PCI Express is still an immature specification. Revision 1.1 was expected to have been ratified in Q3 this year and has not been. Application developers are starting to design ASICs based on PCI Express and therefore, as is the case with most new technologies, are pushing the bounds of the specification. Cadence offer a wide range of link layer and PCS cores. Working closely with Rambus, the market leading Serdes IP provider we offer developers the widest range of PCI Express solutions available today. Responding to customer feedback we are making further development to improve ease of use and have a generic transaction layer currently being verified.

CONCLUSION

Keeping IP usable is as significant an investment as the initial development. As we have seen pressures to change IP come from various sources: some obvious, others not so. While a change may be implemented in a single line of RTL the true cost can be far higher – as this one-line change will probably require a significant amount of change to the test environment. Although the cost of verification changes is being reduced with advances in verification methodology such as system languages and the availability of verification IP, there is a large number of legacy IP cores that have complex test environments. The cost of maintaining these has to be taken into account.

A lot of users do not necessarily want to pick up the latest changes in an IP core. What they have works for them in their environment: it has been in silicon in a number of products, perhaps, and they are unwilling to take the risk of change.

Other users might want to keep up with specification changes. One of the benefits of licensing designs is that updates and upgrades can be provided under maintenance. In addition to the IP vendor doing the initial design work for you they will keep the core updated as changes to the specification emerge. They will keep the core updated with useful differentiators as valuable changes get added to the core functionality.