A number of tasks have to be done prior to starting design at properly speaking. These tasks are aimed at validating data to be used for design and setting up the methods for addressing the design challenge and the structure for handling the design data.
A design kit is a set of design aid tools and associated data that are used by the designers in their day to day design implementation and design validation. All the design validation relies on simulations based on the design kit.
As the design kit is a major tool for the designer, it requires validation. It is important to know exactly the design kit status, what works properly and what does not. It is possible to use successfully a less than perfect tool provided the fact limitations are known.
Then it makes sense to validate extensively the Design kit even though the designer has limited possibilities to change the tool that usually comes from the silicon supplier which is either a separate company or a separate division in the same company. However knowledge of strength and weaknesses of the tool is important for using it properly and efficiently.
As it requires a good knowledge of components behavior, Design kit validation is detailed later for each component type in part 2
Design kit status is a document summarizing the design kit validation phase. This document that must be made easily available to every designer must include:
Every designer in a team should be aware of the process options that have been chosen and of the components that are allowed for the design. Process options include items like:
The number of options impacts the production cost so it usually has to be kept to the minimum. However, if an option can simplify either the design or the layout and results in a smaller chip, a detailed cost analysis must be carried out to make a decision.
A table describing options and components should be accessible to all in a common, read only, directory and any member joining the team should be given access to this directory.Compliance to this list is an item to be checked during design reviews.
A design method that secures the data is required when more than one designer work on a circuit. Only validated cells should be placed in the circuit library, but each designer, during his design work can perform trials that result in cells that, temporarily, do not work properly and should not be used by others. A good practice is that each designer should work in his own library. A designer’s own library is not supposed to contain only reliable data. Once a cell is validated, it should be copied to the circuit library. To avoid the danger of deleting cells by accident, the circuit library should be read only for all users but the design leader and his deputy. The design leader or his deputy should copy cells from the designer’s libraries when requested to do so. Special attention should be paid to these copy operations. In particular, when hierarchical cells are copied, reference library should be changed so that the copied version is consistently located in the circuit library. Any warning during these copy operations should be analyzed carefully. Finally, a good practice is to run the characterization on the copied cell in a library that only has access to the circuit library. This ensures that the copy was correct and consistent.
Revision control is a major issue in circuit design. The question is:
In case a cell has to be changed after is has been copied to the circuit library, what about the previous version?
If the new version fixes a serious bug that really prevented the previous version to work properly, the old version could be dropped. In this case, the new version simply replaces the old one.
But if the new version achieves a new balance between performances, the old cell could have interest too. In this case, the two versions should survive.
The concern is that the library manager tool might not manage versions. In this case, a possible solution is to suffix the cell name by a version number. It is a non ideal solution since it is not true revision control, but it brings the capability to manage different versions.
Naming cells is important, especially when more than one person design a circuit, to avoid confusion and collision.Defining a naming convention at an early stage, can avoid issues and avoids renaming later on. It is a good practice to define this convention even before any cell is designed.One suggested method is that cell names start with a prefix that identifies the top block. Then the cell name can continue with a core that identifies functionality. A number can be added then for the purpose of identifying different cells with the same functionality but different performances. The cell name might continue with two or three letters that identify the designer. The cell name should then end with a revision indicator.
If the top cell is built from several blocks with one of these being a modulator, cells inside the modulator can be given names like:
A good practice is to define a naming convention for signals too. This reduces the risk of errors. Indications a signal name can handle can be:
All the documents relating to a design should be located in a special place that can be accessed by all the designers. The documentation structure should comply to a standard structure. However, special needs can exist that require additional documents.
Design traceability and design reuse require that documents are created and updated all along the design work.A good practice is to initialize a documentation structure that will be filled up with documents as they are created.
Writing documentation can be painful if done after the design is complete. Doing it in real time not only is easier but also can improve the design efficiency. Writing a document requires asking the right questions. Reviewing a document helps detecting remaining open issues or discovering inconsistencies.Some simple rules should be kept in mind when writing documents:
Things that are obvious for the writer at the time the document is written might not be obvious at all for the readers, including the writer, at the time the document is read. Writing these “obvious things” is not so time consuming for the writer but can save lots of time for the readers. So, a document should contain indications on context and addressed problem.Important items such as assumptions should be indicated clearly.
It can look strange to define such a detailed item before design at properly speaking. In fact, this could be considered as the very first step of design, but as it does not share the standard design flow structure it has been included in the design management. The power supply strategy has to be defined at a very early stage as it impacts the whole design and it is very difficult to change this strategy later on. The supply strategy defines such things like the number of different supplies, the way supplies will be propagated through the design hierarchy etc...
Again, it can look strange to include return for experience at the beginning of the project... This is done for two reasons:
It can seem strange to prepare the future before looking to the past, but logically you can only look at the past if you kept records from it at the time it was not the past yet!
Among things to be included in a “Return from experience” document:
It is a very common mistake to think that things will be completely different next time, or that one will not make the same error twice. Experience shows that we remember the good and forget the bad. In addition, return from experience is not only for the people who lived it, it is also for others.
Obviously, all the items listed above have to be considered when a new project starts. In particular, all the items that have been identified as “to be done first” or “to be done early”. The return from previous experience should be shared widely among project members: Not all the members of a new project have the same experience.
The time it takes is worth it: It saves much more time than it costs.
Most of this book contents is based on return from experience on a large number of projects.