Hello, fellow designer. I've been observing your work lately. I want you to know that "I feel your pain," but we really need to talk. Yes, I know your schedule is very busy and your current design was supposed to tape out three weeks ago. However, while you're waiting on your simulation job to back annotate those 2 GB worth of timing data, perhaps we could chat for several minutes.

If it seems that this whole job of design is getting harder than ever before, you're right. Consider that design you completed 18 months ago, and compare its complexity with this design. The new one is 50 percent larger and runs nearly twice as fast, with only two thirds of the power consumption? Do you mind if I ask why this design is late? Perhaps you can tell me why it's already gone through layout three times? I see. I suppose in hindsight that skipping those extra verifications wasn't such a time saver after all. Who would've known those silly little corner cases would turn out to be so important to the customer?

I think we may be getting close to the crux of the problem, but first let's explore a few more details. I must assume you're taking great advantage of design reuse, including virtual components and logic blocks from earlier designs. Oh? Why not? I see. Well, perhaps the next design will have some semblance of structure to it.

Of course, these aggressive performance and power requirements will necessitate some novel architectural changes. Do you have a plan for estimating the trade-offs involved? Oh, I understand. No time for that. Right. Well, I guess we'll just have to give it our best initial shot and then see what we get at the end. Still, it would've been nice to partition this design, allocate budgets for each block, and then run some fast estimations on the impact of each architectural change. Some folks might have thought it would make sense to optimize the architecture first, particularly since your CEO has mortgaged the future of the whole company on the success of this next design.

Many engineers are working overtime, yet still not keeping up with design complexity trends. From our new 21st century viewpoint, we can characterize the 1990s as the decade of the "RTL methodology." Simply put, this means we coded up RTL for synthesis into gates, then tossed the design over the wall to layout. Although design complexity has increased by at least several orders of magnitude since this methodology was defined, the industry has (by and large) hung on to a familiar flow. Of course, the (silicon) sand has been shifting beneath our feet during this period. For ASIC designers, physical concerns used to be the exclusive domain of the foundries, which were left with the trivial but necessary details of layout. It's now self evident to all that timing goals can't be achieved without considering physical issues during synthesis. Thus, the physical domain has indeed become a design issue alongside the logical domain. ASIC suppliers are increasingly challenged to deliver more optimal results, which also satisfy reliability and signal integrity constraints (blending both domains). To make an even stronger point, continuing trends in silicon process technology will ensure that this duality pushes up into even higher levels of abstraction in the years ahead.

Now, friend, let's put this all together. Design complexity is rapidly increasing, far outstripping the notable improvements made by specific EDA point tools. Design schedules continue their relentless pace, with ever-increasing pressures on time to market. Design content has become a mix-and-match scenario, blending reused, modified, and new blocks. Designers must now simultaneously address multiple views of a design, including logical issues such as timing and power, but also physical concerns that affect performance and cost. Clearly, the industry is overdue for a methodology overhaul. Now, what's that word I'm searching for?

Hierarchy. Yes, that's the word! I know, hierarchy sounds like a simple concept, so why hasn't it caught on across the industry, you ask? There are many reasons, really. First of all, the meaning of the word hierarchy itself is a source of confusion, with multiple interpretations and connotations. Most designers think of block diagrams and RTL code structuring, while ASIC foundries tend to focus more on hierarchical layout, extraction, and design rule checking techniques.

In truth, hierarchy seems confusing and difficult because the industry has yet to converge on a general methodology that encompasses both logical and physical dimensions in a compatible flow. The secret to overcoming this challenge lies in a thorough understanding of how we map between logical and physical hierarchy-and how we apply that mapping using available technology in the flow.

For example, while designers know that synthesis algorithms perform best at less than 100,000 gates, recent synthesis products incorporating placement and floorplanning techniques assume a physical view of the entire chip. What's the optimal methodology to specify physical blocks in the floor plan relative to functional blocks targeted for synthesis? How can the boundaries of one block be specified correctly without incorporating incorrect and artificial constraints imposed by the other? These challenges have been further complicated by inconsistent support for hierarchy and multiple views of abstraction in the file interchange formats used in industry today. New industry standards should be specifically designed to enable and preserve both logical and physical views of hierarchy, as well as the implications of the engineer's mapping decisions.

The concept of hierarchy can take on many forms in the design flow. In addition to functional RTL blocks and physical floorplanning blocks, hierarchy needs to be considered as an integral part of netlists, clock trees, modeling, verification, global and detailed routing, design rule checks, parasitic extraction, reliability, signal integrity, and testability. Of course, the concept of hierarchy is merely a means to enable solutions, not a solution in itself. The idea above is only valuable when the various design representations and the algorithms cooperate and leverage it. Since the nature and impact of hierarchy on EDA algorithms can vary widely, defining a winning methodology requires expert EDA knowledge across the full design flow. Additionally, many other business constraints and practicalities can further complicate details of the methodology.

Still, there comes a point in the design flow at which the world really does become "flat." In the end, an actual silicon die must be packaged, tested, and delivered as a single entity. The silicon manufacturing process relies on many files that continue to grow with design size, seemingly without bound. For example, some files used to create mask data for manufacturing are approaching the 32-bit O.S. file size limit-for each mask layer!

A rough sketch of a generalized hierarchical design methodology might resemble the following steps: First, define the functional blocks for the design, identifying key virtual components and reused logic. Next, import all known logical and physical constraints imposed by the selected virtual components, and perform exploratory simulation and estimation runs. Create an initial (RTL) floorplan that adds known constraints for the design itself-relative placement, I/O, power, ground, clocks, and especially global interconnect between blocks. The physical hierarchy just defined can now be used to generate derived constraints for the logical hierarchy (timing, for example). The detailed partitioning of the logical hierarchy for synthesis occurs next. The logical blocks are iteratively synthesized, beginning with the least timing sensitive blocks first. Timing, power, and area budgets are adjusted and refined during this process. Physical synthesis tools can greatly add to designer productivity at this stage. Static timing analysis on critical paths is performed following all synthesis and floorplanning stages. Later stages of the flow proceed in a similar fashion. Parasitic extraction and design rule checks use their own on-the-fly definition of hierarchical objects, in addition to designer-specified physical hierarchy. This definition greatly reduces memory and computational effort.

The scenario above only works if the designer actively participates in the physical (not just logical) view of hierarchy. That doesn't mean that every ASIC designer is responsible for performing detailed routing on his own design. It simply means that physical constraints are recognized as an important engineering tradeoff with direct impact on the logical constraints. While this may sound sensible on paper, it is much harder to execute in practice.

What's that, you say? You don't want to floorplan a design? Floorplanning tools are too difficult to use and take too long to learn? Yes, in fact, I have heard that before. Perhaps you have an alternative suggestion to support hierarchical design. You do? Okay, I'll rush this napkin over to the design center right away, I'm sure it's all they'll need. The real truth, however, is that there's no substitute for an engineer's judgment applied to the floorplanning task. This is true for both gate and RTL level floorplanning tasks. There may be, however, a less intrusive method to capture the high-level physical constraints and trade-offs than full-blown floorplanning, one that requires less of the system designer. More on that in a future column.

So, my designer friend, it's not your fault. You haven't had the tool support you've needed to embrace hierarchy and make your job easier. And, for EDA companies, it's not your fault, either. Designers have failed to converge on the pre-requisite methodology.

I suspect that our industry-wide problem in adopting physical hierarchy is rooted in the value proposition. As a system designer, I used to think I added little value dealing with physical concerns. With the need to learn system level issues-such as protocols, transmission standards, modulation techniques. How could I justify time spent on placing individual blocks and pins in my design?

Yet here we have entered into a new millennium, and a new era for electronics designers as well. The coupling of the logical and physical world has become an inextricable part of advanced semiconductor design. But more than that, today's system complexity mandates that we fundamentally embraced better methodologies to help our solutions scale with the problem. The broad industry adoption of hierarchical techniques may be difficult, but we will all reap great rewards from this investment.