Today, the success or failure of an advanced IC design depends largely on how smoothly it traverses the design process. Greater cohesiveness between front- and back-end design domains is critical to the productive development of advanced ICs in this very deep-submicron era. Unfortunately, many forces, such as specialization and team dispersion, divide design disciplines at a time when unification is more important than ever.
In particular, constraints and design hierarchy must be devised with both front- and back-end design tasks in mind. Deploying these constraints and hierarchy in a jointly developed methodology that considers market and organizational factors helps ensure a friendlier handshake between design domains—and a more successful design organization.
More and more, designers are discovering the perilous time-to-market implications of underestimating the interdependency between front- and back-end design disciplines. If designers don't address this interdependency, they can waste months of precious development time reaching timing closure. This divide be-tween front- and back-end design is better understood, and better remedied, by examining the forces that create it.
In the early days of IC design, a very small group of designers, in one location, performed the entire development process. But the emergence and growth of the ASIC industry brought three new characteristics to bear: specialization got the job done faster; design team communications became more structured; and different parties were compensated differently.
The ASIC industry grew, and these characteristics took hold. Eventually, this led to the development of specialized EDA tools, stricter signoff requirements, and less willingness among participants to share resources to solve problems.
As design complexity increased and third-party design tools and foundries emerged, the "tall and thin" organization that once existed became much "shorter and wider." The emergence of synthesis technology and ASIC/COTS services, in particular, forged a clear segregation of back- and front-end design tasks. Designers were separated not only by design discipline, but also by geographic or company boundaries.
Design organizations, trained in these complex tools, often with proprietary interfaces and standards, became more entrenched in a segregated methodology. The problem with this high degree of specialization arose when mutual issues couldn't be solved by one team, such as not meeting timing closure for deep-submicron designs. Even though more-complex tools and more-specialized designers were available, no one was compensated or motivated to make sure a cohesive methodology was used to solve problems across tool domains.
Overcoming these barriers to achieve a more connected design flow is a big task. But focusing on aspects of the design methodology that have the greatest impact on the flow can somewhat simplify the job. Unified constraint setting—the guidance given to design tools to drive the desired design outcome—and design hierarchy establishment can greatly improve problem solving between front- and back-end design domains.
Considering all of these issues, an organization must develop a common constraint and hierarchy strategy prior to design start. This process begins with the examination of constraint and hierarchy needs of back-end, front-end, and any third-party organizations involved. Needs of the various parties are then jointly considered, and unified constraint requirements and a hierarchy strategy are established (Fig. 1).
At that point, the various groups can devise a flow, select tools, set constraints, and establish hierarchy. When all parties reach mutual satisfaction with these decisions, the actual design process commences.
Defining a constraint and hierarchy strategy up front can avoid many risks. The risks of poor constraint setting are familiar. Overconstraining a design typically occurs either when there are too many or unnecessary constraints, or when designers attempt to trick a tool into producing the desired results. Unfortunately, overconstraining a design can cause performance, power, or area penalties. It can also mask the true change needed, such as modifying the register-transfer level (RTL) code.
An example of this is when a path constraint is artificially made too aggressive. The synthesis tool may correctly "see" it as the critical path. But if the constraints are too tight (i.e., less than or equal to the I/O delays), the synthesis tool will see that it can't optimize more, then move to the next clock group to optimize the most critical path in that domain (Fig. 2).
Also, if the design is overconstrained in one tool to trick it into producing the desired result, those artificial constraints might not be appropriate for other tools. Poor constraint setting causes timing closure issues that protract design cycles.
Establishing constraints involves two primary considerations. First, the desired result, and the constraints that will achieve it, must be determined as early as possible. The synthesis tool should focus on the module that contains the most timing-critical portions of a design.
Poor constraint setting could drive the tool to optimize more globally across the design, possibly providing suboptimal timing in the most critical module. Further refining of the outcome can take place during the design process, but basic objectives must be clearly established very early.
The second ideal goal is for synthesis and place-and-route to use the same constraints. Otherwise, the two do-mains may produce different outcomes. In many cases, designers use a "divide-and-conquer" approach to synthesis, where the design is partitioned into many small modules. When brought into place-and-route, that same design is flattened, then optimized globally from top-level constraints (Fig. 3).
It's no wonder that the place-and-route tool finds different critical paths than the synthesis tool, drives placement and routing delay optimization based on different critical paths, and then finds that timing closure is unachievable. Assessing the tool flow and the optimization and capacity capabilities of the given tools can prevent this problem. Either use a synthesis tool with equivalent capacity to place-and-route tools, or define place-and-route as a hierarchical process, inheriting the same constraints from synthesis.
Hierarchy establishment is the other critical focus for effective front-to-back interaction. Hierarchy refers to the structure of the design on which the various disciplines operate. In the front end, functional hierarchy is the primary focus, although it's increasingly important that a general level of physical hierarchy be determined prior to, or during, synthesis. Early knowledge of physical information can help with grouping logic for synthesis, to attain better timing results and aid in developing design constraints.
Physical factors, such as precise locations, are factored into the hierarchy in the back end. Hierarchy and its relationship to the design process is analogous to a water brigade attempting to put out a fire. Designers are like the brigadiers, passing the bucket down the line. The hierarchy is the bucket, a form containing precious contents to be brought together at the end. All brigadiers depend on the seamless handoff of these buckets to accomplish the task.
Inappropriate attention to hierarchy leads to suboptimal implementation choices (Fig. 4). Designers may have to expend precious development time manipulating a design for appropriate partitioning throughout the flow. An example of this is buffers inserted to force time budgets between partitioned modules for synthesis.
Another hierarchy pitfall is improper setup for the design tools in the flow, which undermines the effectiveness of those tools. For instance, if logical hierarchy isn't set up properly for a formal verification tool, mismatches and miscompares can result, diminishing the benefit of the tool. Formal verification tools typically look at logic between register boundaries at both the RTL and gate level. But if the synthesis optimization includes merging of register boundaries to improve timing and area, a false mismatch with formal verification can occur.
As with constraint setting, there are several key considerations when establishing design hierarchy. An important consideration is the best synthesis module size, defined in terms of tool efficiency, tool capacity, and what functionally comprises the design. Additionally, the degree of hierarchy must be determined in the context of front- and back-end domains. A lot of hierarchy may make the front-end design process easier, but it greatly complicates place-and-route. Likewise, flat hierarchy is ideal for place-and-route, while it's unmanageable for synthesis.
Each design has its own "optimal" topography for hierarchy based on the functionality of the design and the design goals. Ultimate area optimization is likely to drive a flatter implementation, whereas optimization of specific timing-critical blocks in the design will drive more hierarchy in the design.
With the considerations of constraint setting and hierarchy establishment in mind, the next step is to define a cohesive design methodology that places a priority on the effective handshake between front- and back-end design domains. Such a methodology entails determining application-driven constraints, delineating roles and responsibilities of the various groups, and agreeing on tools and flow.
Determining application-driven methodology constraints requires examination of the critical parameters for market success—and the implications of those constraints throughout the design flow. For example, high-performance computing applications demand performance optimization above all else. Performance objectives can largely be achieved in front-end design processes with only a few checkpoints in physical-design stages. When devising a design flow for this application space, constraints and hierarchy might be established to optimize efficiency of synthesis and verification.
On the other hand, consumer and telecom applications, with their em-phasis on cost, verification, and compliance testing, dictate a flow that's more accommodating to back-end design efficiency. Still another example is wireless or battery-operated applications, where power optimization might prevail over other concerns. Because back-end designers have little they can do to address power issues, a flow that addresses this market might be largely dictated by the RTL design stages.
Designers must also understand any tool-driven constraints on methodology. An organization must examine the tradeoffs associated with adopting new tools that have advanced features. Also important is determining any "hard" requirements, such as sign-off simulators dictated by silicon vendors. Tools with proprietary interfaces, or those that require designers to expend effort manipulating a design purely for tool compatibility, will generally create a more difficult task for those devising a cohesive methodology.
Delineating the roles and responsibilities of the various groups to be involved, across multiple companies, is very important when devising a cohesive methodology. A silicon vendor will play an active role in moving the design forward. But the level of involvement varies across vendors. Some ASIC vendors place-and-route, perform IDDQ testing, and verify a design before preparing it for fabrication. Others, like foundries, only work with final layout to correct it for OPC and other processing-related constraints.
Also playing a role in many design flows are third-party design-service providers that assist with any aspect of the flow. The earlier in the design process that vendors become involved, the more they must be included in methodological determinations, such as constraint setting and hierarchy establishment.
Roles within the organization must also be considered in the context of the application space, tool constraints, and organizational attributes, in-cluding geographical dispersion of the various groups. For example, certain nets in the design, like resets, might need to be constrained in such a way that the synthesis tool doesn't touch them. This way, place-and-route may insert buffers or perform sizing. So, constraint and hierarchy definition must be defined across tools.
With the increasing complexity of design organizations, a growing number of groups are including a methodology specialist in their design team. Such a specialist helps mediate all issues related to interaction among different design disciplines and organizations and ensures methodology cohesion.
Online recruiting Web sites (i.e., Hotjobs.com or Monster.com) show many companies seeking such a methodologist. This person typically has several years of design experience and knowledge across several tool disciplines, is chartered to develop the methodology that a design team should follow on a project, and en-forces/assists its deployment.