Rotten to the Core or Core-blimey…Silicon DNA! Page 1 of 2

Part 1: Getting Ready to Outsource an IP Core
by Dr. Barry Henderson

Introduction

Probably one of my most interesting peripheral tasks as an FPGA design engineer is to evaluate and integrate third-party cores. This area of technology has been flourishing recently, with both Xilinx (now offering a wide range of IP cores, and up to four embedded 405 PowerPCs in a Virtex II Pro FPGA) and Altera expanding their range of IP and NIOS cores. These are but two players in an ever-expanding arena. Each vendor typically has a range of cores covering such fields as communications, networking, DSP, video and image processing, RISC, uP, and filtering.

Certainly the area of IP development is an ever-increasing one, with more advanced building blocks becoming available every day. In the title above, the term DNA could well stand for Do Not Assume…anything! This is surely true when it comes to obtaining IP cores. I am not insinuating that IP-core vendors are all rotten, but I do mean to say that you must know exactly what you want, when you want it, how much you are willing to pay for it, and how to evaluate what you get. Caution, skill, patience, and knowledge are key attributes when acquiring the right core at the right price.

Inevitably, as design cycles shrink, FPGAs and ASICs expand to 10s, 100s, and 1000s of millions of gates, and IP providers breed like overactive rabbits, the choices and magnitude of what is available will surely explode. In a nutshell, you want a high-quality core, a flexible vendor, a competitive price, and on-time delivery. This two-part series of articles expounds on my experiences to date in evaluating, verifying, and embedding IP cores. I will also attempt to establish a generic checklist of do's and don'ts.

Preliminaries

Recently my IP core evaluation activities have involved me in the selection and integration of a Reed Solomon Decoder for use in an advanced wireless communications system. The first step in this process was to analyze whether I really needed to purchase an external IP core. It may be that with sufficient resources I could design one in-house. Often this is thought of as the least risky solution. But is it? The answer is that it depends on several factors, the most important of which I have listed below.

In-house skills in the area(s) of expertise required to develop a core

Availability of key in-house design staff and the tools required to develop a core

Experience with external IP core vendors

Meticulous preparation of a Requirements Specification

References from previous clients of IP core vendors

Deadlines—how tight are they?

The level of technology. Is it KEY?

If a company meets the first two criteria, then in-house development is probably the right route to take in the sense of lowest risk. Otherwise it is a very good idea to explore in some depth the capabilities and cost of a variety of IP vendors. One exception to all of this discussion occurs when the level of technology to be developed is key to a company's survival, then, even with extensive NDA coverage, it is probably still a wise decision to keep development in-house. With this route it is possible for a company to maintain firm control of critical design tasks, and also keep proprietary knowledge secret.

However, this was not the case with the Reed Solomon decoder core that I recently selected, integrated, and verified. This method of error detection and correction has been around for several years, the principles on which it is based are well understood (by some!), and a large range of cores is available off the shelf. However, the core we required had to be custom-designed and built, mainly because of some nonstandard features, and strict area and timing requirements. And therein lies a problem. As soon as you venture off the well-beaten path, additional risks definitely enter into the equation.

Requirements

To undertake any type of complex design that comprises many interacting elements, you need a well-defined specification. This must include detailed timing and interface definitions, timing diagrams, functional descriptions, hierarchical block diagrams, flowcharts, and a sound verification strategy. What language are we going to use? Are there any company conventions that must be adhered to? This is especially true if you are going to use an external IP vendor to develop a core.

Changes to specifications can get lost at the best of times, and external typically means new barriers to communication will be raised. These are not insurmountable, but clear lines of communication and protocols for change must be discussed up front and allowed for in any contract. For example, who is responsible for verifying a core? Often the verification process will be taken in stages. In this case, both the vendor and I performed extensive module-level verification. Then I performed system-level integration and verification. If a core has been carefully designed and debugged, the module test bench matches the interface exactly at the system level, and the requirements specification is both correct and implemented correctly, then all should be well. More on this in my next article!

I found that IP selection can be a lengthy process involving several interlinked stages along the way. The outcome required, of course, is a fully working core that meets or exceeds all important areas of your specification, integrated and verified into the FPGA or ASIC of your choice, in a reasonable time frame and at a reasonable cost. In general, we could summarize the entire process as shown in Figure 1. The boss comes to see us, and enlightens us as to the requirement for a new IP core. Usually that requirement has a time limit of a few weeks or months. The Matter Factors are typically cost (we want it as cheaply as possible), functionality (we want it to do as much as possible), speed (we want it as fast as possible), and size (we want it as small as possible).

Figure 1 - The Get Me an IP Core Quick Flow!

Next >>

Real-Time Processing Using DSPs, FPGAs & uCs Archive

Guides and Experts Analog Avenue EDA Tools PLD DSP EDA Embedded Systems Power Test


		Click here to get your listing up.