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.