|
2009 Story Set
| June 10, 2009 The term IP, as it applies to the engineering world, is still "intellectual property". But the acronym was coined for the beginning stages of "design reuse". While many designs are under 1 million equivalent gates per die, we are also faced with large designs of 6, 8, 12 MILLION gates per die. It would take YEARS for an engineer to design a system of that size. One engineer's work for one year being a man-year (yeah, I know it is a bit sexist but I have learned to live with it), such a design would take decades. Or many, many engineers working for one year. I won't bother to prove it as there have been numerous presentations that did all that. Efficiency in numbers you do not achieve. You add more and more layers of management the more workers you have. Tracking all the parts of the design flow is a full-time job all by itself. Along about the mid-1990s, the idea came for design reuse – wherein, if you have a good controller, why design another one? And you can substitute adder, register, multiplier, CPU, and so forth for "controller". (Or, how many versions of a 64-bit multiplier do you need to design in your career?) Memory comes along with this. Why constantly design memory blocks, RAM, ROM, EPROM, etc, when you have done it once already? Thus was born the concept of design IP. There were two types to start with: hard IP and soft IP. We have pretty much settled on soft IP going forward. Hard IP is where you have a piece of a full die holding the functional block you are going to reuse, and you punch a hole in the full design base-die to drop in this slug. It requires every layer to be stitched together (think 28 layers and up). There are rules, e.g., the IP cannot have more metal layers than the base die into which it will fit. The processes of the two are required to have certain items in common. It is really rather detailed and complicated. The concept and all its rules and regulations give most engineers fits. (I call this "the eyes roll to the back of the head" syndrome.) If the base-die process technology changes, you have a whole second go-round on getting the IP in a compatible process and then re-stitched back into the design. This is not trivial. Soft IP is simply a piece of Verilog RTL code (Verilog in the USA has dominated VHDL, which was more popular in Europe. Think VHS and Beta; DVD and Blue-Ray.) The code module drops into the design files and is compiled with the rest of the Verilog. Since it is not process-specific, it can go seamlessly from one base die process to another. It acts like a grouped function, and, if there are no input registers in the IP module, sometimes you can ungroup it and run minimization on the logic blocks feeding into it (up to the first register, latch or F/F). The Synopsys Design Compiler® and its many descendants allow this. This all sounds good, is easy to use, and there are many suppliers of "soft IP" – including Synopsys. The AMD bit-slice (Am2900) series and its followers can be purchased as soft IP. The Am2910 controller is still the most clever and multi-purpose controller around and is still being dropped into designs, 25 years after AMD stopped producing the actual parts. There are large and small functional blocks that qualify as IP. Something like 8-10 different adders alone. There are a couple of CPU units, and bus-driven archetectures that have become popular to the exclusion of trying to design a new one. IP is custom tailored and specified as meeting certain design objectives. Some IP is designed for high-speed, for use when speed is imperative, and power and area constraints are not so relevant. Others use less power (hence, are slower). Some minimize their footprint (die size). Some are intended to drive heavy loads. If a designer has options, they can instantiate a specific IP "macro" in their design, or list the ones that they don't want and let the synthesis tools like Design Compiler choose from the remaining options. It depends on the macro library that is available to the design. Individual companies, who make multi-generational designs, liked the idea. Modules that popped up over and over, became in-house IP. The result is that a very large design, which now can have as much as 80-90% IP, can be put together faster. No more reinventing the wheel. In theory. The idea more or less caught on with many companies. Unfortunately, the concept did not quite make it into these companies intact. As a result, we have a lot of "IP", which can be "reused". Of course we do. But because the concept, drop in and go, didn’t quite register, every time they drop in the IP, they change it! It needs a little bit altered here. Or, a lot there. Or, let's move a register field around. Or, whatever. This negates the IP concept! Diddling with the design can lead to failure. Delays. All the things we were trying to get away from. All the problems we were trying to solve. Worse, for every design that the IP is used for, we replicate the design specification! Sometimes the spec is just "revised" and stacked in the version heap of a database (like Microsoft's Sharepoint). Sometimes, it is "copied" to the new design area, and changes made to THAT COPY. Here's the problem: In the first case, it requires specific and careful documentation to mark when something was edited for a specific design. We all know just how good designers are at documentation – not! In many companies, the proficient technical writers went out the door with the technical trainers and all that other "non-essential" support. Documentation has deteriorated. Engineers don't want to do it. (Most can't write anyway.) Or, and this is worse, it is out-sourced to people who know little about the project and nothing about engineering, but who are cheap. Sometimes we are not certain they even really know English! The resulting specifications in all cases leave a great deal to be desired. Now make these specifications ones that apply to "reused" IP, and the problem gets very quickly out of hand. This leads to questions like: does the new version of the spec apply to all designs that use this IP going forward? If there are multiple versions (and I have encountered this), which version applies to which design? (Because there may be several going at once.) What if, several versions down the line, you return to the IP in a descendant design from an older one, but now you have changes and yet do not want the changes made for a design that occurred in-between? Keep the bourbon handy. You have just created a tar pit. Eventually, and faster than you would like to think, this system will spectacularly fail! The other problem (copying the file at some point into a new design documentation area and editing that copy), leads to multiple-source files. This is also a tar-pit. What if what was edited was then decided to be useful to others using the original IP? How do you get the changes back to the original spec? Now you have two copies of the document. And possibly, no probably, more. Eventually, and faster than you would like to think, this system will also spectacularly fail! We need something better. It's called content management. We are told that we just can't afford it. Actually, we can't NOT afford it. You need that and a good technical writer or two. |
www.Donnamaie.com my home page
Caliente Morgan (my pen name)
Main Story Index (top-level current year)
WhitePubs.com (Technical Textbook/Reference book publisher)
Jettison Saga (Jettison - Hellsfire - Kali's Song)
The Naked Housewife (Americanized Bridget Jones) (watch your typing )
Fabio International Fan Club (also see the Yahoo group)
Fabio Inc. (Fabio Inc. Business pages - new)
Copyright 2009-1984 Donnamaie
E.White.
Material may not be reproduced without written permission of the author. donnamaie@ - no spam - sbcglobal.net