Our cores group within the Information Appliances division at National Semiconductor is responsible for designing and developing analog and digital cores as well as enforcing a methodology for reusing these cores. Early on, National made a strong commitment to reuse designs as well as to develop ways to build reuse into our design methodology. One of the company mandates, in place for some time now, is that any design with reuse potential should be designed towards that end a practice very difficult to enforce. Additionally, National continuously develops new intellectual property (IP) and, in addition, has a great deal of legacy property available, thus our challenge is significant.

Existing practices didn't lend themselves well to the reuse of IP in a production environment. Among the difficulties we faced, was the inability to ensure compliance to the "Green Book" (our internal tome of design rules) standards and unsatisfactory methodology to track the status of existing design blocks.

Ultimately, the ability to have automated DRCs at the register transfer level (RTL) allows us to enforce the official National IP reuse design rules, which we developed from our experience building complex integrated circuits (ICs). Forcing our engineers to comply with our reuse standards requires them to think in terms of reusability, and identify area like coding style, partitioning, and architecture for future users.

IP Public Storage — the little orange garage concept

Enforcing design rule checks (DRCs) and verifying that developed IP can be deposited are two critical areas of concern while developing cores at National. The former area is significant so that any designer anywhere in our company can access a design and understand how it is to be used and incorporated into the overall design. The latter area ensures that IP developed by various groups within National can be automatically deposited into our IP repository. This requires that the IP be correct by construction, that it includes a complete design database and conforms to reusability rules.

Adding new design tools and increasing the automation of the flow seemed like the answer to the challenges of accessing and mining the mountains of legacy IP. Because we license cores both internally and externally, our ability to manage the process is key. However, our efforts to organize and access our intellectual property have proven problematic.

In an attempt to establish standards for good design practices, we have produced and disseminated a manual of laws known as the "Green Book." This document describes, in great detail, the requirements for re-usable designs — documentation, design rules and style conventions, and other information necessary for follow-on users to use the IP. In addition, we maintain a database to facilitate geographic collaboration on current projects and to preserve legacy IP for future use. In order to access this rich source of IP, we have also developed a sophisticated internal configuration management system. This provides our designers with a mechanism for retrieving information about any design contained within our systems management repository.

Finding the right tools

Today, designs are simply too complex to manually inspect and describe each new and existing piece of IP within the time required. As gate counts for full system-level chips exceed a million gates, it becomes impossible within a given market window to build a new chip without sacrificing earlier designs. Realistically, new IP should comprise only 20 percent of the overall design content of a chip. In an ideal world, where 80 percent of IP is reused from previous designs, we believe it is possible and to design a system-on-a-chip (SOC) in half the time with about half the number of people as it takes today a 75 percent development savings.

Initially, we looked to use Escalade's (Santa Clara, CA) Design Book as a graphical entry tool. We quickly realized, however, that there was a lot more in the product than front-end graphical schematic or information capture. Some of the other capabilities within the tool, such as translation and design structure recognition, were extremely useful to us. We felt that Design Book could address two critical problems: How do we initiate automated checking for adherence to style guidelines? How do we establish the proper structures for data transfer to our data base? For the first task, we wanted the ability to do custom DRCs at the register transfer level (RTL) quickly and easily. For the second, we wanted to establish an interface between our IP and our proprietary configuration management system throughout the design process.

Most engineers will forget or ignore design reuse driven by schedule pressure and the desire go on to the next project. In our experience, engineers give minimal attention to the task of archiving their designs at completion, since design for reuse requires more time and attention to the details, including such specific information as design intent and design flow. With manual reuse methods, by the time a piece of IP is reused, the original designer has likely moved on to another project. Attempting to integrate that piece of IP is very difficult or nearly impossible without the original designer's first hand knowledge. Without automated rule-checking, individual engineers turn to different styles and levels of checks for their designs which creates a difficult, if not impossible, environment to accomplish design reuse.

Figure1 - Executing DRCs within Design Book

The customized DRCs enhance the checking and enforce usage standards.

Design practice makes perfect

The reuse environment, with its mix of valuable legacy IP and our current developments, needs to meet our reuse standards to be useful. Before we implemented front-end DRCs with the interface to our configuration management system, reuse could only be done manually and was a slow and inconsistent process. As seen in RTL syntax checkers or linting category of tools such as "RMM Compliant" design rule checkers and general purpose programming interface to parsers and design elaborators, several previous attempts to verify compliance without changing the design flow forced EDA CAD engineers into becoming programmers.

National's good design practices have benefited from years of practical applications, and address the interaction between design components, and reflect a deeper understanding of design violations than a syntax checker is able to recognize. To that end, our checker needed to have a semantic understanding of the design as well as the implications of the rule, but not require time and programming ability from the designers.

The use of DRC capabilities in Design Book improved the reuse skills of the designers who worked on the pilot program using the DRC software. Because we have made our engineers more conscious of the quality of their work, they readily adopt a reuse mindset.

Automation

Our DRCs use the knowledge extraction technology from Escalade to implement checks that understand various logic and clock signals. A rule checker could provide hundreds of rules for specific checks, but without any coordination between checks, this would return redundant and even irrelevant violations. Instead, we worked with Escalade to develop a smaller number of integrated design rules. Each DRC is highly parametric, giving designers control over the depth and extent of the check. Designers are thus better able to comprehend and anticipate the results generated by RTL Design Rule Checking.

Each integrated design rule recognizes a violation within the context of the design by examining it at a higher level of abstraction. Our DRCs search the design for problems in a specific area by looking at all levels of hierarchy and considering the interplay between individual events and modules. The RTL design rules are categorized into the following areas: naming conventions, reset rules, clocking rules and domains, allowed/disallowed component types, synchronous/asynchronous logic integration, snake path detection, and partitioning rules.

Customization through Tcl

We now have a tool command language (Tcl) and C++ based platform to orchestrate the DRC and repository interface. This is a very important feature to our team. Tcl is fast becoming the industry standard because of its flexibility and widespread adoption. The tool users like this flexibility as an attractive solution to the problem of defining a custom interface.

We have exposure to the RTL by parsing the database using the Tcl and C++ extensions in an open Application Programming Interface (API). This yields three key advantages. First, we perform DRCs at the RTL through Tcl and C++. Additionally, we're exposed to the front-end DRC rules, and this gives us the ability to not only change the DRC we're performing, but also the ability to add in company-specific checks. Finally, because the database is exposed to us, we have a fuller understanding about how to link that up with our own version control system.

Figure 2 - Design Extraction and Data Mining

Automation in the design knowledge extraction technology helps to convert legacy designs into reuse compliant versions by creating alternative views of the source files.

The ability to do DRCs at the RTL facilitates our goal of building reuse into our existing infrastructure and processes. Once we read a design into the semantic database, Tcl and C++ extensions permit us to check and change the design at the RTL. The ability to achieve both ends while preserving the rest of the design is a key advantage of the tool.

The open API environment made it very easy to customize the DRC functionality to address our unique IP concerns. With help from Escalade, we wrote 23 DRCs specifically for our use. Additionally, we continue training to develop additional in-house expertise and we hope to have 50 more rules written by mid next year.

Because Tcl and C++ extensions make it easy to change existing DRCs as well as add new ones, we can implement and enforce the design standards we care about across a conglomeration of internally generated and commercially acquired IP. Coding style, logical design rules, clocking, inter-block signaling, and testability need to be coordinated with each other in order to support future reuse possibilities. The Verilog representation of the design at this point reveals that a designer has access to the entire set of rules at the RT level of the design.

The ability of users to customize the tool is especially advantageous in the areas of naming convention, identification of clocks and resets, and primitives. Individual designers can choose to check the design early and throughout the design process, or quickly assess the level of compliance of designs in the corporate-wide IP repository. This maximizes the productivity of designers, as they are able to selectively apply and modify the checks provided.

Custom DRCs

Examples of our custom DR checking start with a clocking problem we would like to eliminate, the "mixed clock and data" rule. This rule refers to a situation in which a designer has used a clock as data input. The tool looks for instances in our RTL code in which a clock is used as data input. If the designer wanted to modify this rule to accept any violations in the design rules, he or she would be able to do so simply by synthesizing an alternate Tcl script.

This interface has also helped to solve the fundamental problem of redundant and in-efficient checks by taking advantage of the parametric nature of the rule and applying each rule in a conditional manner. An example of conditional checking is the act of implementing cascading checks for clock requirements. For example, the clocking rule might specify the following types of checks: the designer isn't allowed to mix clocks and data; clocks cannot be internally generated; no more than one clock per module; clocks must be only posedge; clock synchronization mustn't be mixed with other logic. In practice, these rules overlap, and useful reporting must steer the designer toward making the minimum number of changes required to ensure compliance with the policy.

Another example of a potential reuse violation we can check for is "no asynchronous logic." Asynchronous logic is very process-specific and its timing is unpredictable in a reuse situation. To make the design more portable, the design should be developed so signal changes that occur between clock edges and within a given clock cycle. Synchronous logic is the preferred choice when designing for reuse.

A related check, "only one clock domain per leaf module," will warn about the usage of clocks of different origin. Some of these violations can be very subtle. For instance, one of the errors we detected when we applied this rule was in clocking between two blocks. The clock transferring data to the receiving block was actually derived elsewhere using the same clock. Clearly, this situation has the potential to create timing problems when the IP is reused in future designs and is definitely something we would like to know about.

The result from the engineer's standpoint is straightforward: The DRC searches for clocks and checks to see if each clock is used in an acceptable manner. We have written the DRC so that if the tool finds a violation, it notes the specific name of the clock, where it is used in the data, in what process, and in which particular module. At this point, the tool notifies the engineer, who can then go and rectify the situation.

Saving the work

The third advantage of the Tcl C++ extensions is that it lets us specify the operations that Design Book performs as part of its role as a bridge between the IP and our internal IP repository. Beyond ensuring that the IP is prepared for reuse, each piece requires additional information about the specific nature of the IP before it can be integrated into another design.

After we institute the automated DRC checks, we can move on to migrating the designs into the repository. To ensure that all IP within the repository is reusable, Design Book acts as a front-end filter for our IP repository. With the click of a button, a designer can DRC check the IP and automatically deposit it into the IP repository. Once the tool is configured for a development group, the all methodologies for the design team will be identical. In addition, when all teams use the same set of DRCs, then all of their designs are automatically checked to the same design rules. When this is the case, our engineers can reuse any part of one design team's work in another design team's efforts simply because they are using the same tool set, and the same methodology. In this way, reusability is automatically "built-in."

The Tcl and C++ capabilities in the tool have the potential to package IP with the required information and easily interface that package with the IP repository system. This includes a set of views of IP in Verilog or VHDL along with a synthesis, physical flow plan or a GDSII tape-ready view. Data files and timing information about the design can also be included (see Figure 2).

Flexible AND Smart

At National, reuse of our legacy IP has long been considered the "Holy Grail" of standards. Even while we understood that we needed to make substantial changes to our methodology, executing our reuse strategy was simply too time-consuming without automation. By automating DRCs and ensuring a seamless and consistent interface to our internal IP repository, we found that Design Book gave us the flexibility designers traditionally value, while avoiding the tedious tweaking required to modify existing IP for reuse. Additionally, the use of Tcl and C++ in areas where visibility is important improved the potential to adapt front-end DRCs to our existing and future requirements.

Sanjay Adkar, is the director of information appliances engineering at National Semiconductor (Santa Clara, CA). Previously, he was the director of ASIC design methodology at LSI Logic.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to mikem@isdmag.com.