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.
Reprints
