Summary

Introduction

When in the course of human events it becomes necessary to mix analog and digital circuit on the same chip, some care must be taken to prevent the digital from destroying the analog. The main culprit in this saga is the following circuit, the CMOS inverter and it’s brethern, the CMOS logic gates.

Figure 1 - The Evil Doer

It is the action of this circuit and it’s effect on the power supply when it switches from one state to the other, that concerns us. When switching occurs, a large current flows either from the power supply to the output, or from the output to the ground, depending on which logic transition is occurring. The current goes from zero to a large value and then back to zero, in a short period of time.  I will illustrate the problem using a simulation.

Simulation

Discussion

Given a perfect power supply net – i.e. one with no resistance and zero inductance, this would not be a problem.We don’t have that and so it is a problem. The large, rapid current change causes a momentarily large voltage across the supply impedance, reducing the effective supply voltage for the switching cell and every other one in it’s proximity. As such, the performance of adjacent cells is affected whenever one of them switches. The extent of this disturbance depends on the power and ground impedance, that is on the layout of the supply nets, and the number of logic cells that are switching simultaneously. In a large SOC the number of logic gates that transition at the same time could be thousands, or millions.

Start-ups and other small companies have limited resources and jealously guard every penny that they spend. They don’t want to hire, train and managed any more people than they absolutely need to get the job done. Purchasing IP is cheaper and faster than developing a new circuit from scratch.

Another consideration is that an IP purchase allows the organization to focus it’s resources on it’s core competency. For example, suppose that you are building a RAID storage controller. Your product would probably need multiple serial ATA interfaces but the design of those interfaces is not how your product will be differentiated by the market. It’s a good business decision, therefore, to focus the companies engineering resources into the design of the key parts of the RAID engine, rather than into development of something that can be purchased off the shelf.

Large companies often create internal IP development centers to build circuits that are used in multiple disparate projects. These centers in effect act as IP vendors to the rest of the organization, and have to follow similar methodologies as an IP vendor would. Project managers that use IP which was developed by one of these internal development centers may not have the same legal and contractual complexities as they would if they bought the circuits from another company, but they must still protect themselves from the possibility that the IP itself is deficient, or that the integration of the IP into the rest of the design will cause a problem.

At various times during my career I’ve worked on projects where the purchase and integration of IP was part of the plan. I have acquired a wide variety of IP, from many vendors and I have had both good experiences and bad ones. Over-generalizing somewhat,  the good experiences tended to happen when my team and I were able to peak inside the “black box”, to review the schematics and layouts of the IP and to run our own simulations. Conversely, bad experiences happened when the IP is delivered without schematics and with only the vendor’s promise that the design was “silicon proven”.

Choosing only silicon-proven IP for inclusion in your design is of course a good strategy to avoid design flaws and integration hassles with a new piece of IP. Since so many customers insist on buying silicon proven IP, vendors are eager to provide that assurance, even to the point of claiming it when it isn’t really true. In one extreme case that I am familiar with, a vendor claimed a circuit was silicon proven but in fact the silicon had actually been run on an different technology node and was a different version of the design than was purchased by the customer. The differences in the versions included a significant architectural change. The customer wasn’t given a true sense of the situation until his team we busy debugging a piece of silicon that didn’t work. Unfortunately, if an IP vendor can stretch the truth about the maturity of their design, just to make a sale, some will do so.

Over the next few posts I will outline the various things that an IP user should do to avoid product silicon that doesn’t function properly. I will also discuss various changes that IP vendors could make to their delivery model to help their customers succeed.

One thing is true: when you purchase IP, the only thing you really “own” are the problems.