ISQED 2006: Keating acts as a real user ...
April 6, 2006 Michael Keating, Synopsys Fellow and co-author of the Reuse Methodology Manual, delivered a lunchtime talk on March 28, 2006 on "Simplicity and Executability: Cornerstones of Quality" at the International Symposium on Quality Electronic Design (ISQED). Keating detailed a recent first use of IP as a customer, and said it was an eye opener. Keating has two rules about IP—if it is not tested, it's broken, and if it's not simple, it will never work. These important, but often violated, principles apply to all design that is IP based, essentially all designs. The discontinuities in the design flows are demonstrating clearly that no one knows what is going on at the full chip level. Now SoCs must account for the functionality, interfaces to the operating system(s), drivers and other middleware, and all of the hardware and software interactions. To make matters worse, design constraints are not developed with the full understanding of the system requirements. For this latest project, Keating was developing test chips with ARM. His first contact with the IP was through the documentation, hundreds of pages of text for each IP block. He decided that the volume of documentation means that most of the documents are not read by the user. An alternative is to use the verification testbench as the primary vehicle to understanding the functions. The documentation is only a reference due to the many discrepancies in the text. When trying to debug the system, he found that applications engineers could help to identify the symptoms but could not find the error sources. Checking the source code for the IP is more accurate as a debug tool since the design can be explored through simulation. Even the best documentation didn't have some of the important information included. Documentation traps Because many parts of the designs are not tested, a prudent user would consider those areas broken. Any documentation should be considered as a guide only. A good set of documents would be written as a guide and should include block diagrams and other important information such as pin and register definitions, and parameters. The design requirements should be in natural language, but the specifications should be in an executable form. Only an executable specification can be tested and allows the extraction of relevant code and content. In the same vein, code reviews are fundamentally flawed. The specifications are out of date and not maintained or synchronized with the design. A code review looks for compliance with requirements, but cannot be tested. All IP needs to have functional confirmation through actual operation in systems and formal tools. Comments in the code are also not tested, but might be useful as insight into the design processes. Realistically, design needs to be viewed as a database to achieve consistency. Users need a way to prove equivalence between any and all representations. Code quality really counts. The code represents the specifications and user documentation, and code reviews represent the best channel to find bugs. The code and data in a database format can be extracted in many ways. The code is the core form of communications between the designer and the user. While the code is the golden specification, it needs to be simple. Simplicity is defined as a design that has sufficient functionality and meets all the requirements. It's hard to develop simple designs. Because the code represents the correct function and has to be understood by IP architect, IP implementers, verification team, maintenance team, and on the user side: SoC architect, implementation and verification teams, the code has to be viewed by a large audience. Simple designs have fewer bugs, and are more likely to work in untested scenarios, because the structure is explicit and has understandable patterns. Bad or overly complex designs, on the other hand, can have invisible patterns and structures. For example, a poor IP block is usually defined a pin structure and a black box of functionality. However, by regrouping the pins as buses and not as individual signals, the structure of the interfaces is kept clear. All designs should have only 7-9 components at the user level. Another example is a state machine. If the designer makes one big, flat state machine, the space explicit but the structure is not. If the state machine is made of multiple state machines, the structure is explicit but the state space is not. In either case, the transition states are not easily determined. Instead, state machines should be drawn as hierarchical state machines with single entries and exits to and from the composite states. Along with the state machines as hierarchies, block interfaces need to be described as messages and not as wires. By making all transactions as messages and not wire states, the patterns become visible. If the interfaces are wires, the various handshakes could take up to 4 pages of text to describe all of the interactions. Again, the intent must be to keep the number of elements in the user's view to a reasonable quantity with lots of regularity. The diagrams for a state machine should help to make the block visible. Items like a bus structure are hard to see in code. The tools for IP design should be geared for the eventual user. SystemVerilog adds structure to the design and increases the verification capabilities compared to Verilog. In addition, it offers about a 10 : 1 compression in code size for smaller block instantiation. It lends itself to a more visual design which allows the user to see patterns while remaining provably equivalent to the code. Designers need to use more tools that generate code from drawings. Although this type of tool has been around for a while, it has a very low adoption rate. IP designers need a way to mix content and presentation for the wide audience that will be using the IP. If the design is in a database format, the code has to be de-cluttered. This coding style takes a lot of discipline so the resulting code and views are coherent. The on-line views need to be linked. The change from theory to practice in reusing IP shows that some of the requirements and constructs have to be cleaned up. It is always difficult to debug someone else's code, because it is not simple and easy to understand. Therefore, it is imperative that IP designers approach the whole design as a set of linked databases. They need to use the latest tools and as much automation as possible to achieve the art of design: to make complexity appear simple. ******************************** EDA industry observer Tets Maniwa can be reached at maniwa_at_sbcglobal.net
|