Tear Down The Wall Between Front-End And Back-End Teams

It’s easier today than ever before to design a chip that cannot be manufactured.


As complexity of system-on-chip devices increases, it’s becoming imperative for design teams and organizations to re-examine how they work with one another in order to improve productivity. One giant step in this direction is to bridge the divide between the front-end design process and the physical back-end design process.

We often refer to this as a figurative “wall,” but there is really no physical barrier separating front-end design teams from those working on the back end. Sometimes these teams work under the same roof, and other times they work for the same company but in different countries. Many times these teams work for different companies, but in almost every situation the people in these teams rarely talk to one another.

I recently orchestrated a customer meeting between the front-end manager for SoC design and the head of the physical design process. While both worked hard at the same company for several years, they had never met face-to-face prior to our meeting. Yet the success or failure of a design depends on both teams being able to perform their jobs harmoniously. Improved communications between the two will contribute to more efficient design processes and ultimately better chips in less time.

For example, one of the most critical challenges for SoC design teams is timing closure. As designs get more complex, achieving timing closure takes longer and jeopardizes the successful market introduction of silicon. With today’s EDA technology, it is easily possible for front-end digital logic design teams to create chips that cannot pass through the physical synthesis place and route process. These chip designs never meet timing closure.

Put simply, it’s easier now than ever to design a chip that will be impossible to manufacture. All of us in the industry can relate horror stories of projects that were canceled because the back-end teams were unable to achieve timing closure. But the back-end teams are not to blame.

Here’s how the process starts: A front-end team typically maps out a “paper” floorplan for the SoC design and sends the RTL and netlist files “over the wall” to the back-end integrators, who must turn it into real placed gates and macros. These floorplans seem logical from the perspective of the market requirements that the front-end team perceives. The physical layout team builds its own “production” floorplan but then struggles to achieve timing closure after several iterations. The reason is that while the logic team stringently verifies the logic from an RTL perspective, no one has closed timing on the design until it arrives on the doorstep of the physical team. In essence, the logic has not been verified from a physical perspective by the front-end team.

Timing requirements on today’s SoCs are extremely tight, and become more so as critical dimensions shrink and more “stuff” gets designed into a die. It is a given today that designs are so large that signals cannot move from one side of the SoC to the other in one clock cycle. This requires the intelligent insertion of timing pipelines during the back-end process to handle data as required by the system timing specifications.

While the CPU and memory controller portion of chips are relatively close together in most floorplans, timing closure problems for the back-end teams often arise with the less “sexy” elements such as image accelerators, security encryption engines, peripheral devices, and camera and display controllers among others. Because of the area constraints on the die, these functional blocks are distributed throughout the floorplan and must be connected by an interconnect that must thread serpentine routes through available die “white space.”

When it comes time to place these IP blocks, problems with the floorplan and the top-level interconnect start to pop up. For today’s complex designs, the numerous iterations it now requires to achieve timing closure can add months to the process. And the back-end team gets blamed for the schedule slip.

That’s too much time, and not fair to the physical team. If the two sides can collaborate sooner in the process, many of these problems that occur in the back-end can be avoided. Time-to-market is now more critical than ever. If there are ways of shortening time to market through better collaboration then every team should explore these options thoroughly.

What if front-end teams could provide information on their design intent to physical teams earlier in the process? What if physical design teams could provide input about floorplan information during the front-end design process? Better flow of information could be used to avert timing closure delays, moving SoC design closer to first-pass success, and possibly cutting weeks or months off the schedule. What if the front-end team verified their design from a physical point of view so that the layout team had a better starting point?

This type of collaboration could happen if the engineers in the logical design team and the physical design team were more aware of the challenges faced by one another. Awareness of back-end issues at the beginning can lead to SoC designs that are easier to place, route and close timing in the back-end. This will become increasingly important as our industry transitions to mainstream 28nm and smaller technology processes, resulting in larger, more complex SoCs with the propensity for more timing closure and back-end difficulties.


Roger Ren says:

nice sharing

Leave a Reply

(Note: This name will be displayed publicly)