Enforcing Design Rules to Develop Reusable IP

by Kanwar Pal Singh and Ramakrishna Ayyagari
Cadence Design Systems
Noida, India

Abstract
Shrinking design development cycles and reducing "time to market" windows, have highlighted the value in design re-use. This paper discusses the modeling guidelines for design re-use with focus on qualifying HDL designs. Methodologies which aid in the development of re-usable design blocks are the need of the hour. This paper proposes a methodology for enforcing design rules during the IP design development cycle to enable the development of reusable design blocks. The methodology consists of a flow which extends the design checking step which the designers execute in the design development cycle and the new capabilities of the design checking tool. The new features that were implemented in a design checking tool to facilitate the implementation of the proposed methodology are also discussed in this paper. The experimental results demonstrate the accuracy, ease of use, flexibility and efficiency of the tool. The results also show the effectiveness of the methodology when implemented as proposed in this paper.

We conclude with a mention of future work which can be done to enhance the capabilities of the design checking tool as well as the extension in the methodology to support system level designs.

1 Introduction
Designing ICs with millions of gates are practically impossible without the reuse of already developed design blocks. The design houses across the globe have been developing big SOC designs by reusing pre-developed design blocks.

Reuse is not something new. This is practised widely in software domain where code modules are used across different programs. In hardware domain, design blocks are reused in different SOC designs. It is different in a very significant way. The real test for design is fabrication and thousands of dollars can be lost because of erroneous designs which can be due to as simple reason as one wrong line of RTL code. With such high stakes design practices need to be systematic and standardized at the very start of the design IP development cycle. This would reduce the issues while integrating the pre-developed design blocks in the complete SOC design.

1.1 Factors inhibiting design re-use

The issues mentioned here are a broad category of the issues which can result in the SOC designer wasting a lot of resources in making the design block compatible with the rest of the design and verifying the complete SOC.

•    Bad Coding styles practised in the design.
•    Design not portable.
•    Design not synthesizable.
•    Design is not testable.
•    Design does not meet timing requirements.
•    Design does not meet Power considerations and area constraints.
•    Design is not well partitioned.

1.2 Proposed Solution

To develop re-usable designs, the design IP developers across the globe, need to qualify the designs against the reusability standards, so that the user who consumes the design faces the least number of issues while integrating it in the SOC design.

To enforce these standards on all the design IP developers there is a need to have a very easy, efficient way of doing standard enforcement early in the IP development stage by using an EDA tool.

In the methodology described in this paper, we propose a flow in the IP development cycle which will enforce re-use standards very early in the IP design development cycle. We also discuss the features in the EDA tool which enable the implementation of this flow.

This results in gain of "Time to Market" for both the IP vendor and the SOC designer.

2 Modeling guidelines to promote design reuse

To considerably reduce the issues which designers face during integration of design blocks to develop a complete SOC design, the design developer needs to follow a set of guidelines during designing. The rules discussed in this section form a set of rules which can be used to qualify the designs for reuse.

2.1 Good HDL coding practices

The HDL designs are considered unfit for re-use because they are not easily understandable. The code is not structured and it is hard to modify and understand the design. The following rules can qualify the design with respect to the good coding practices.

•    Follow standard naming conventions
•    Do not use HDL reserved words
•    Use functions
•    Use Loops and arrays
•    Use meaningful labels

2.2 Standard Clocking scheme rules
A simple clocking structure in the design is easier to understand, analyze and maintain. Following are some of the rules which should be followed while designing for re-use.

•    A single master clock
•    No gated and internally generated clocks
•    All sequential elements positive edge triggered

2.3 Standard Reset scheme rules
Standard reset scheme makes analysis of the design much simpler and easier. This also aids in the verification of the design. Some rules around reset scheme which need to be followed are:

•    The reset in the design needs to come from primary input
•    Resets other than initial resets need to be synchronous resets.

2.4 Portability rules
While designing for reusability, the design should not have hard coded MACROS and it should be parameterizable. The design should not be bound to particular library and technology, but should be compatible with standard libraries and most of the technologies. The rules which can qualify the design against these requirements are:

•    Do not use hard coded numerics
•    Use only IEEE standard types in VHDL designs
•    Use technology independent libraries

2.5 Synthesizability rules
It is very useful to catch potential synthesis issues before actually synthesizing the design. This saves a lot of costly iterations during synthesis. Some of the guidelines which designer needs to follow to make the design synthesizable are:

•    Infer registers
•    Avoid combinational feedback loops
•    Specify complete sensitivity list to avoid simulation synthesis mismatches
•    In verilog designs use non-blocking assignments in "always" blocks
•    Keep FSM logic and non-FSM logic in separate modules

2.6 Testability rules
One of the biggest problems which SOC designers face when they integrate the design blocks from different sources in their design is the problem of the design blocks not being verifiable. This leads to problems in the verifiability of the complete SOC design. Following is the set of rules which the design IP developer should take care to qualify the design for testability.

•    Design circuits for ATPG
•    Avoid gated clocks
•    Combine clock systems for testing
•    All scannable flip-flops should be driven by same clock

2.7 Design partitioning rules
A design well partitioned leads to better understanding and better integration of the design. Some of the rules which aid in developing a well partitioned design are:

•    Register all outputs
•    Group combinational logic in the same module as destination register

3 Methodology to enforce re-usability standards on the Design

Design IP development cycle basically comprises of Feature planning, Design planning, Design implementation & Design productization. The proposed methodology is targeted at the design implementation stage. Here we propose a flow which is an extension of the existing design checking step which every designer anyway runs after writing the HDL design code.

The IP reuse qualification set of rules can be broadly divided into pre-synthesis checks and post synthesis checks. Instead of running the design checking step once, we propose a flow in which the design checking tool will be run twice in the design cycle. The aim is to catch the issues which can be problems in integration of the design block and verifiability of the design. It is not possible to catch these issues if only RTL level design checking is done.

As per the flow there will be two executions of design checking step:

The Phase-I pre-synthesis step will qualify the HDL code against:

•    Good HDL coding practices
•    Portability issues
•    Synthesizability issues
•    Standard clocking scheme
•    Standard reset scheme

Of these, the checks on coding practices, portability & synthesizability (limited to synthesis of certain HDL constructs) can be done by the analysis of the RTL design code. For the advanced synthesizability checks, clocking scheme & reset scheme checks the design checking tool should have the capability of pseudo-synthesis. Pseudo synthesis of the design creates a structural view of the design, because of which the advanced synthesizability issues, clocking & reset scheme issues can be caught with accuracy.

The Phase-II post synthesis step will qualify the design against:

•    Testability
•    Power consideration and area constraints
•    Potential timing issues

To catch the post synthesis issues the design checking tool will be run on the design netlist.

This step is proposed as a new step in the design development flow. Post synthesis analysis will report DFT rule violations as well as structural loops, feedthroughs and latches in the design. DFT issues can not be caught in the analysis of the RTL view of the design as the scan chain is inserted during the synthesis of the design. The issues like structural loops, feedthroughs and latches in the design will also be caught with accuracy when the design netlist is analyzed as the netlist is the structural view of the design. After synthesis the per module gate count estimation is also available which can be used to report area constraint violations.

To enable the above mentioned analysis the EDA tool should be capable of analyzing the synthesized netlist of the design and also capable to read and analyze the timing library for the design.

The issues caught here are potential problems during low level implementation of the design.

Discovering these post-synthesis issues is one of the value adds this methodology proposes.

Flow diagram showing the proposed methodology in the IP development cycle

4- New Features in the design checking tool
The challenge for the implementation of above discussed methodology is in development of a robust design checking tool to perform the complete set of checks on the design, to qualify it for reuse. We have developed a design checking tool to enable the implementation of the proposed methodology. The tool has following capabilities.

4.1 Enhanced set of rules
The set of rules of the design checking tool is enhanced to include the synthesizability, testability and structural rules. With this enhancement the design checking tool in addition to checking for language semantics, also qualifies the HDL code as being a re-usable design. The set of rules is robust enough so that all the issues are caught at one go, rather than being identified by other verification tools.

4.2 Pseudo synthesis capability
Pseudo synthesis creates a hardware view of the design without actually synthesizing the design. A pseudo synthesis engine has been added to the tool so that it can catch the synthesizability issues with accuracy. It is possible to catch the clocking scheme & reset scheme issues after the pseudo synthesis of the HDL code by analyzing the netlist created after pseudo-synthesis.

4.3 Capability to run on the synthesized netlist
The design checking tool has capability to run on the synthesized netlist, to catch the post synthesis checks i.e the DFT checks. For this to be possible, the tool has been enhanced to read the design libraries so that the DFT checks can be done with accuracy.

4.4 Capability to customize the existing rules
Depending on the requirements of each SOC designer the existing rules can also be customized. e.g There is an existing rule which says that "All primary outputs of the top level module should be registered". In case a particular design house requires that the primary outputs at each hierarchical level be registered, the tool provides the user the capability to do such customizations.

4.5 Capability of augmenting the existing set of rules
The design checking tool has the capability of augmenting the existing set of rules with more rules. The mechanism provided for this needs to be very easy for the user to develop custom rules. There is a mechanism to write new rules using "C" through a programming interface provided by the tool. This allows the set of rules to be augmented by each design house with some of the design house specific rules.

5 Experimental results
The above mentioned features have been implemented in the design checking tool. The set of rules has been enhanced to cover the post synthesis checks mentioned. The tool was used on some of the public HDL IP cores available at www.opencores.org[1].

The IPs used were:

UART    : Communication controller UART core
GPIO    : General-purpose I/O core
Minirisc    : Mini-RISC Microcontroller/CPU
Wb_dma: DMA/Bridge IP core

Following table shows the time consumed and the number of rule violations caught in both the pre and post synthesis runs.

Design IP	Pre-synth violations	Post-synth violations	Pre-synth runtime	Post-synth runtime
UART	214	5	15sec	10sec
GPIO	84	16	20sec	45sec
Minirisc	498	7	25sec	45sec
Wb_dma	1975	249	1min	1min 26sec

In the experimental analysis of the above mentioned IPs, following violations were reported:

Some pre-synthesis violations were:

•    Signal assigned under clock but never reset
•    Reset of a flip-flop is an expression
•    Gated clock in the design
•    Naming convention violations
•    Variable defined in the process is unused
•    In a module the clock signal is used as a set/reset
•    Unequal length across comparator operator
•    Delay in nonblocking statement

Some post-synthesis violations were:

•    Combinational path across units
•    Feedthroughs
•    Top level output not registered
•    Latches in the design

5.1 Pre-synthesis analysis of the UART design
During the pre-synthesis analysis of the UART HDL code, the rule violations reported included Gated clocks. Gated clock can generate false clock or glitch, causing the flip-flop to clock in the wrong data. The gated clock also causes limited testability because the logic clocked by gated clock cannot be made part of a scan chain.

In the UART design the clock gating was detected for clock RRegL of flip-flop RxAv

RxAvProc : process(RRegL,Reset,ReadA)
  begin
     if ReadA = '1' or Reset = '1' then
        RxAv <= '0';  -- Negate RxAv when RReg
                                -- read
     elsif Rising_Edge(RRegL) then
        RxAv <= '1';  -- Assert RxAv when RReg
                                -- written
     end if;
  end process;

The clock RRegL is being driven in a case statement and hence resulted in gated clock

case BitPos is
              when 0 => -- idle
                 RRegL <= '0';
                 if RxD = '0' then -- Start Bit
                    SampleCnt := 0;
                    BitPos := 1;
                 end if;
              when 10 => -- Stop Bit
                 BitPos := 0;    -- next is idle
                 RRegL <= '1';   -- Indicate byte
                                            -- received
                 DataO <= RReg;  -- Store received
                                               -- byte
              when others =>
                 if SampleCnt = 1 then  -- Sample RxD
                                                      --on 1
                    RReg(BitPos-2) <= RxD;
                                                -- Deserialisation
                 end if;
                 if SampleCnt = 3 then -- Increment
                                                     -- BitPos on 3
                    BitPos := BitPos + 1;
                 end if;
           end case;

5.2 Post-synthesis analysis of the UART design
Doing the post-synthesis analysis of the synthesized netlist of the UART design block reported structural loops in the design. These were not caught during the analysis of the RTL code.

Catching these issues is a real value add for the IP designer as removing these issues upfront from the design will enable better integration of the design block into the complete SOC design and also make the design block testable.

Several design groups (both internal and external) have used this tool and implemented the proposed methodology in their design cycles. The feedback from these groups show the acceptance of this methodology. The capabilities of the design checking tool have been much appreciated and have been used to customize the existing set of rules and create new rules much to the advantage of the SOC designers.

6 Related work
Today there are many standards and guidelines which aim at design re-use. Reuse Methodology Manual (RMM) [2], Design styles from STARC[3] are some which are widely accepted. There is VSIA[4] - Virtual Socket Interface Alliance which was established with a goal of establishing a unifying vision for the system-chip industry and the technical standards required to enable the most critical component of the vision: The mix and match of Virtual components (IP) from multiple sources. There also exists OpenMORE[5] which is a reference scoring program for assessing the reusability of Hard and Soft IPs for SOC designs. In addition to these we have design house specific rules. All these are fairly disjoint efforts but with a common aim. The IP development community as well as the SOC design community need to arise to the fact that individual standards is not the way to go. Due to different standards, some designs will be re-usable in some SOCs but not in most. If we want to tap the real power of re-usability there should be one unified re-use standards.

7 Conclusion and future work

In this paper, a methodology to qualify design IPs for reusability, is proposed. The enhancements in the existing design checking tool to support this methodology were also discussed. This methodology when implemented qualifies the design for re-use and reduces the issues faced in the integration of the design block in the SOC. This also reduces the "Time to market" considerably.

As this is an extension of the existing technology, this fits in very well in the design IP development cycle and is not a big overhead. The need for a globally accepted standard set of rules for design re-use was also brought forward. The design community need to accept this reality that to tap the real power of re-use this standardization needs to be done. The features in the tool are ready to accommodate any such standardization.

As of now, this methodology is proposed for the qualification of the HDL designs. Some of the features which are planned extensions in the design checking tool include adding the scoring capability and additional language support for writing custom rules. This scoring will be weighed according to the importance of the rule. i.e whether the certain design practice is prohibited, mandatory or recommended. This gives the designer percentage compliance of the design to the prescribed set of rules. The capability to create custom rules will also be enhanced, to allow the user to write new rules using other languages e.g Perl,tcl. Designers are more conversant with these languages.

With the advent of system level designing, this methodology can be extended to the qualification of system level design IPs. The industry standards around the re-usability of the system level designs written in SystemC or SystemVerilog need to be developed. The same technology could also be enhanced to have the additional capabilities to qualify a System level design for reusability.

8 References
[1]: www.opencores.org
[2]: M. Keating and P. Bricaud, "Reuse Methodology Manual: For System-on-a-chip Designs", Kluwer Academic Publishers 2001
[3]: "Design Style Guide 2001" STARC - Semiconductor Technology Academic Research Center
[4]: www.vsi.org
[5]: www.openmore.com
[6]: Lionel Bening and Harry Foster, "Principles of verifiable RTL Design", Kluwer Academic Publishers