When it comes to reuse, particularly analog, the one key roadblock you must consider is the apprehension from a designer who is contemplating the use someone else's work. That uneasiness is created from many sources that might include not understanding what tradeoffs were made, what detailed validation was completed and why, what the original designer was concerned about or what limitations the original designer assumed for their design. The list can continue to include many more types of similar information. Typical block (IP) level documentation does not usually cover these "touchy feely" attributes and that leaves the end user to guess and/or recreate them for his or her own comfort. This lack of background information is what usually creates the reuse "Fear Factor".

Left unchecked, this fear creates a subtle wall to reuse that will present itself in many different forms. In many cases the reasons for not reusing will be based on a technical foundation that is created by the lack of solid background information about the block. Without the ability of the "reuser" to get into the original designers head they are unable to gauge the thought processes that were used by the originator and the uneasiness sets in.

The pressure to reuse is driven by management and the penalty for design errors is bore by the design team. This sets up an environment where the design team will do whatever it takes to either feel highly confident of reusing a block or end up developing the design them selves. Without providing what's necessary to create confidence for reuse of a block, the default decision will usually be to develop it from scratch based on their previous work.

Getting a handle on the role of the IP reuse fear factor must be a top priority of any sharing initiative that is underway. Without addressing this upfront, the reuse of IP is sure to come in at a disappointing level, no matter how sophisticated the repository may be. The first priority must be what goes into the repository, not the repository itself.

What should be in your repository to quash the reuse apprehension? For starters the electrical spec is an obvious requirement. The danger is assuming that this is all that is necessary. The end user will want to know what the original design was worried about when going through their work. They will want to get into the original designers head. What about potential noise sensitivities if the block is placed too close to a digital block? How much resistance can be in the power supply path between this block and another block where signals are shared? This list can continue for a multitude of potential concerns. If you rolled this type of background information into the general electrical spec you would have a documentation package that certainly would generate much more comfort to the end user of a block.

To get your IP reuse initiative kicked off with a minimum of reuse fear I suggest working with your team of potential end IP users to create a documentation template. If this template is generated to cover the majority of the concerns the users have about reusing someone else's design, you will be well on your way to a winning IP reuse strategy. Listen to your end IP users and give them what they need. The extra effort will be well worth it!

In your schematics and layout you certainly make use of hierarchy to minimize the duplication of information throughout the design. Hierarchy brings you the capability of not having to maintain the identical cell in more than one part of the design. Why wouldn't you consider the same reasoning when it comes to your engineering documentation? Do you find yourself duplicating information from the customer spec to your engineering specs? That sure seems like a potential maintenance headache, doesn't it?

Just like you reference cells in a hierarchical design you should consider referencing of information across your various levels of specifications. The same spec details should show up in only one of your engineering documents. In a large design you could have customer specs, architectural specs, design specs and IP specs. What a nightmare that would be to keep all the data synchronized between them.

You probably see this as a huge paradigm shift and a nasty headache to implement. Build up spec templates to cover the expected type of information for each level and you are well on your way to a hierarchical approach. Consider how much pain and the design errors you may have endured maintaining it as stand alone documentation.

email: jeff@jorvigconsulting.com

phone: 480-895-0478

web: http://jorvigconsulting.com