With today's complex SoC designs, RTL designers are faced with a challenge of delivering block/sub-chip for the project within aggressive schedules. The designers are required to collaborate with architects/micro-architects, external IP providers, verification engineers, implementation engineers and place-route engineers. Accordingly, completeness and done-ness of the RTL block is determined after it has successfully gone through processing and analysis by these diverse groups. There are multiple local and global iterations which occur between RTL designers and down-stream groups of implementation, verification and place-route engineers.

These iterations are costly, interrupt-oriented and occur over extended period of time. As an example, RTL designer might get feedback about synthesizability or testability or power from implementation or integration team. Once those issues are fixed by RTL designer, there might be another iteration later in place and route stage where the RTL block might be discovered to have congestion. It might cause another global iteration through the process. In summary, the closure of RTL block occurs in incremental, unpredictable, costly iterations and multiple hand-offs. This process is typically back-end-loaded, a place where schedule pressures mount quickly.

Atrenta provides a way to achieve early closure and predictability of RTL block right at the source. Atrenta products allow the RTL designer to predict down-stream issues of implementation. Atrenta products allow the designer to remedy those issues locally--Right at the RTL authoring stage. RTL designer can thus minimize costly iterations with down-stream groups and do a solid quality hand-off. This approach allows RTL designers to focus on their next design with minimal context-switch.

As an example, here is a sample list of areas where Atrenta products can help the analysis and early diagnosis of possible down-stream issues

• Clock domain crossing issues and improper synchronization instances
• Dead code in the design
• Un-initializable and unreachable states in Finite State Machines
• Proper resetting of the block
• Conformance to all the coding and design style guidelines
• Various design rule and electrical rule violations
• Completeness and coherence of constraint files
• Block synthesizability, testability and test coverage
• Suggestions for improving testability of the block
• Logic depth cones and potential areas of timing critical paths
• Gate count and die size estimate
• Opportunities for clock-gating and power saving
• Possible sources of congestion at place and route stage
• Optimal floorplan suggestions