Standards-Based IP Cores Ease Networking IC Design
By Doug Bush, Xelic, CommsDesign.com
August 7, 2003 (6:32 a.m. EST)
URL: http://www.eetimes.com/story/OEG20030807S0009
In order to support the existing and future networking demands of customers, manufacturers are racing to provide competitive advantages and higher levels of integration to accompany their unique Intellectual Property (IP) for products that differentiate them from the rest. These products are often based on protocols such as ATM, POS, GFP, Sonet/SDH, and Digital Wrapper (G.709). To maintain profitability while providing more features at a lower price point, organizations have been forced to streamline operations and sharpen the focus of internal resources on their own specialized IP. In support of this process, many companies are forming partnerships with third-party providers to acquire IP cores that implement any number of networking protocols in use today. This approach offers considerable advantages over the old paradigm but it also forces designers to implement new evaluation processes during the design stages.
In this article, we'll descr ibe standards-based networking cores and discuss advantages, selection considerations, and integration procedures. We'll also apply these criteria in a few application examples.
Standards-Based Networking Cores: Why They Shine?
The recent downturn in sales of networking equipment does not exempt the networking industry from needing to continue to invest in reinventing itself. One way for designers to re-invent their design process lies in how they deal with technologies developed in standards bodies.
Traditionally, chip and system houses have spent tons of money implementing a standards-based technology in a chip design. However, with cost pressures rising and design teams shrinking, these same organizations are finding it hard to keep up with every new spec or tweak to a spec released to the market.
To solve this problem, designers can turn to third-party manufacturers to produce IP cores that provide the latest implementations of a standard. Leveraging these third-party cores allows organizations to dedicate internal resources on the development of their unique IP without having to spend the time and carry additional headcount necessary for the development of standards-based functionality.
As always, ASIC products must come out of fabrication working right the first time to avoid costly re-spins and lost revenue from delayed product introductions. Standards-based cores offer a low risk option for what can be a significant portion of the ASIC gate count while at the same time provide the advantage of reliability. Standards-based cores typically come validated in either a previous ASIC implementation and/or a development platform that implements an FPGA showcasing functionality (Figure 1). This ensures the operation of the core in customer applications and significantly increases the chances of first time silicon success for integrated product solutions.
Figure 1: Di agram of a standards-based networking core evaluation platform. Selection Criteria
There are many vendors who provide standards-based cores for a variety of networking applications. The process for selecting which core is right for a particular solution will depend on a number of factors. Customers have to weigh the importance of each attribute when selecting their core provider. At a minimum, the following considerations should be made in order to select the right core for the job:
1. Functionality
Perhaps the most obvious requirement for core selection is functionality. The core must contain the functionality and features required for the target application. In some cases there may not be an exact match of features required but most vendors offer the ability make enhancements or modifications to the core for an additional fee.
2. Documentation
The documentation that accompanies a core should come complete with a product brief, datasheet or design sp ecification, verification plan, and a hardware validation users guide if an FPGA based evaluation platform exists.
3. Compliance to Standards
Networking standards are constantly evolving with enhancements being made all the time. It is important to ensure that the core being investigated is compliant with the appropriate standards in force.
4. License Terms
Licensing terms vary depending on the core provider. Understand the terms of the core being considered to ensure current and future requirements are satisfied. For example, if you have only one product that you wish to integrate a core into, a single use license may be adequate. If, however, a complete product line requires the use of a particular core, a perpetual license may be required. A perpetual license is generally more expensive than a single use but allows for more flexibility down the road. A maintenance agreement will often accompany the license agreement to provide the customer with core integration support and a ccess to future upgrades.
5. Deliverables
The deliverables will vary somewhat depending on the vendor and license terms chosen. The actual core can be delivered as a netlist, hard macro, or in source code format The source code format is generally the most desirable option though it is quite often more expensive as well. A self-checking verification environment should be provided for validation of the core. This environment may or may not be readily adapted to in-system verification depending on the compatibility of core provider methodology and tool flow with that of the customer. In the case of source code format, synthesis scripts should also be provided. A complete project database should contain all of this - including documentation.
6. Testability
It is always a good idea to make sure a core to be integrated into a unique IP solution has testability features built in. This will make the eventual hardware debug process go a lot smoother and provide a quick means for determi ning the functionality of certain core components. For example, a Sonet/SDH framer core should have the capability to force a number of error conditions to ensure the appropriate detection algorithms operate as expected. This is easily verified with commercially available Sonet/SDH test equipment.
7. Vendor Methodology
A quick analysis of the quality assurances employed by the core developer is recommended. Though it may be impractical and even counter productive to perform a thorough examination of precisely how a core was designed and verified, the overall methodology used in the development process can serve as an indication of quality. Coding guidelines and internal process documents which include checklists and design process flows should be requested to ensure that the core provider meets the basic standards of quality required.
8. Cost
A critical consideration to vendor core selection is cost. It is important to watch out for hidden costs or required maintenance fees that might inflate the overall project cost. Where customization is required for a particular application, have the vendor provide a detailed statement of work.
9. Support/Customization/Configuration
This is one of the most important selection criteria to be considered in the evaluation process. Quite often a core will be offered in a fairly generic configuration and may require customization for a particular system application. For example, the data bus width or processor interface might need to be modified slightly to integrate properly with unique IP being developed. In this situation, the cost of customizing the core must be evaluated. The core vendor commonly does this customization with additional self-checking verification testing added.
However, it is sometimes possible for the customer to customize the core themselves if they work out an agreement with the vendor to do so and obtain the appropriate core source code. The customization problem can be avoided in some cases if the IP ven dor provides a configurable core. This implies that certain parameters are used to allow for variable size bus widths and internal register flexibility. For example, a core may be offered with the option to configure the data bus widths for a variety of sizes. Investigating a configurable core option could save a lot of time, money and effort.
10. Target and Gate Counts
The target device (ASIC or FPGA) and process technology for a standards-based networking core must be thought out up front. It is important to know the target process technology because some cores could be incapable of operating at the desired geometries. For example, a core designed to work with geometries of 0.25 micron might not work in an application that is designed for a 0.13-micron process. In addition, when sizing up the amount of functionality that can be integrated into a particular device, a core gate count may be an important consideration. Customers are always trying to integrate as much functionality as possible a nd the amount of integration may be limited if core gate counts are too high. A low gate count is often a sign of efficient coding practices and optimal architectural decisions.
11. Validation
Core validation is a two-step process. The first step involves the verification of the core on a simulator using a proven verification environment. A variety of tests are written using the verification environment to ensure all modes of operation and corner cases are checked. Core vendors generally provide a self-checking verification suite with each core developed. The second step is a hardware validation process whereby the core is verified in silicon as either an ASIC or FPGA using commercially available test equipment for data generation and checking.
Integration into Networking Designs
Standards-based cores have a wide range of networking applications with varying degrees on integration complexity. Product solutions may be as simple as combining one or two cores in an FPGA or as diffi cult as integrating many different cores with specialized customer proprietary IP into a multi-million gate ASIC implementation. Lets look at a couple of examples to investigate some of the issues and concerns that arise when integrating cores.
Example 1: Networking Switch Line Card Application
For the first case, consider the integration of a channelized Sonet/SDH OC-48 framer core with an SPI-3 core into an FPGA for a network switch line card application (Figure 2). In this example the FPGA line side interface is well defined by the OIF SPI-3 standard and connects directly to a serializer/deserializer (serdes) device and optics module.
Figure 2: OC-48 line-card application. The channelized Sonet/SDH frame information may be delivered as a multiplexed data bus or as individual serialized channels of information on the system side interface of the FPGA. The cu stomer will specify the data format required for each line card plugged into the system backplane. If a core provider interface is not suited for the implementation chosen, an enhancement may be required.
Integrating standards based cores always brings up the interesting question of how to handle the product processor interface. In many cases, each core will come with a standalone dedicated processor port. Since only one processor interface is required for a device with customer proprietary IP and/or multiple core instances, special attention must be given to develop an appropriate memory map for the device. If a core supplier does not supply the flexibility of various processor port configurations to satisfy this situation, some core customization may be required.
Example 2: 10-Gbit/s Traffic Manager Application
A more interesting application involves the integration of several networking technology cores with specialized customer proprietary IP to create a 10-Gitb/s traffic manager ASI C (Figure 3). The same I/O and processor interface issues discussed in the previous example will also apply here, but in addition there is a system verification issue to be investigated.
Figure 3: 10-Gbit/s traffic manager ASIC design. Unlike an FPGA, you get one shot with an ASIC to get the functionality right and avoid the high cost and long lead times incurred with a re-spin. To reduce risk and increase the chances of first time silicon success, a system-level verification effort that includes data flow through the entire design is highly encouraged.
It is a significant advantage if the core provider and customer use the same verification methodology so that various models, data generators, xactors, and checkers can be leveraged for the system verification effort. If, however, the customer uses a high level language such as C/C++ for verification and the core provider uses HDL test benches, it will be more difficult to leverage verification components. It is important not to underestimate the importance of system level verification.
Wrap Up
The implementation of standards-based IP cores that support existing and emerging technologies relieves lengthy development burdens for organizations trying to devise more efficient and effective ways of handling network traffic. This approach is very effective but requires a serious effort to select the right partner to provide the required IP cores.
Careful consideration of both core and system integration requirements play a major role in the design process. Keep in mind how helpful core vendor support can be during the integration phase. A well thought out process can result in project cost savings while at the same time provide a low-risk, reliable product solution.
About the Author
Doug Bush is the director of IP development at Xelic, Inc. and has over 15 years of development experien ce in the areas of Sonet/SDH, ASIC and firmware engineering. Doug holds a Bachelor of Science degree in Electrical Engineering from Rochester Institute of Technology and a Master of Science from the University of Maine. He can be reached at bush@xelic-inc.com.
