Compiler






Designing for Flip Chip Devices
The transition from traditional wirebonding technologies to flip chip packaging is being driven by growing IO complexity and performance. While flip chip packages enable very high IO counts, the technology presents the design team with new challenges in successfully integrating the die and package. In an interview, Bryan Peter, Director of Engineering for Product Design and Implementation at Tundra Semiconductor describes how his team adopted Synopsys’ new JupiterIO unified IO planning product, and expects to realize a 60 percent reduction in package integration time.

Compiler:
Why is Tundra using flip chip packaging?

Bryan Peter:
Flip chip packaging removes the need for wirebonding by allowing a direct connection from the die bond pads to a package substrate using conductive ‘bumps’. This approach enables high-pin count, high-speed designs that just cannot be implemented through a standard wirebond package. This technology complements our particular design styles, since the majority of our parts are for standards-based Systems Interconnect applications. The trend with System Interconnect for communications and storage applications is towards faster throughput, which means more highly-parallel, IO-intensive devices. For example, some of Tundra’s latest designs offer 72-bit (or wider) memory interfaces operating at 200-MHz or more. We have seen significant performance advantages for these devices using flip chip technology, which offers a fully populated BGA array of 1000 or more pins.

Figure 1
Figure 1: Connecting the Die to the Package

Figure 1
Figure 2: JupiterIO - Simultaneous Die and Package View

SC:
Tundra has completed a number of flip chip designs. How did the use of flip chip technology impact your design process?

BP:
When we started with flip chip we definitely placed a lot of new demands on our existing tools and techniques. We had to investigate how we could best deal with the concept of area-IO – that is, IO distributed over the chip area as opposed to around the periphery. Because of this fundamentally different IO structure, phenomenon such as electro-static discharge (ESD) and latch-up — and the associated issues — had to be handled quite differently.

We also had to address the special routing requirements of the RDL (Re-distributed Layer) route, which is affected by IO placement. The approach we took is called ‘ground up flip chip’. We didn’t just add an RDL layer onto a conventional wirebond die – we built the flip chip design from the ground up, which posed some unique challenges to our flow.

The crux of our flow challenge was this: with flip chip, there is a high degree of interdependency between die and package integration – the package requirements have a greater influence on the chip layout than with wirebond packages.

We had spent much time adapting our package-planning process and tools to handle flip chip designs. Unfortunately, the alterations we made required that some flow operations be completed manually. This led to increased iterations between IC and package integration and made convergence on a solution more difficult and time-consuming. Once an IC layout is finalized, it’s a significant undertaking to change it: for example, if a problem arises with the package route due to IO assignment, incremental changes to the IC layout can cause unacceptable schedule delays.

The fact is, with flip chip the routing of the package potentially has an impact on the die. If there are any issues that arise from problems with routing the package – the impact on the die can be substantial. With devices with multi-million gate counts, you really don’t want to have to re-visit the die floorplan late in the design process, after you’ve completed IC layout.

When we realized these challenges, it became clear that package routing had to be considered much earlier in the development lifecycle, ideally in parallel with the die layout process.

SC:
How did the IC and package teams share the information they needed?

BP:
For our first flip chip designs, we modified our design flow, primarily using spreadsheets and scripts to pass information from bump placement files between Synopsys Encore — our Physical Design product for packaging and our previous floorplanning tools. We made use of existing Synopsys IC layout tools to create routes for the bumps based on the IO cell locations.

It’s interesting because this part of the process does involve a number of individual designers and engineers, each with different skill sets and each responsible for different aspects of the IC and package integration process. We would typically need a package substrate designer to focus purely on the design of the substrate for the package. We’d also require a layout expert, as well as a number of analog and chip-level designers to look after analog integrity for the design and any board-level requirements. Without an effective way to manage incremental changes to the design, which gives everybody visibility into assumptions being made at each stage, team communication becomes difficult. As with any situation where multiple people are working on a complex problem, if there is no visibility into what is driving incremental decisions, things can break down pretty quickly. There’s no doubt that gaps in the ability to effectively share knowledge leads to increased iterations.

We discovered that, while iterations early in the design stage are expected and factored into the schedule unexpected late-stage iterations have a severe impact on a project. These are typically due to die-level issues arising from sensitive analog or high-performance functions, which are affected by the package routing.

SC:
Tundra has recently adopted JupiterIO for all its flip chip designs. How does JupiterIO address the challenges of die/package IO planning for flip chip?

BP:
The integration between Encore, JupiterXT, and JupiterIO means that we have a far more efficient and cleaner way of sharing IC floorplan and package design data. This gives us the capability to take the requirements from both sides and apply them to either the die or the package substrate. This fundamentally reduces the number of iterations required, and helps accelerate the time spent on any given iteration. We can now more accurately predict the package routing requirement… and do this at a much earlier stage in the design phase.

The nature of our interface designs means that we have a high proportion of repeated patterns, and so the ability to perform pattern-based IO placement with RDL offers us a great benefit. The ability to perform differential routes is also a real plus, especially given the prevalence of high-performance serial IO within our designs.

Taking into account the learning curve associated with adopting a new tool, we’re expecting to see a cycle time reduction of 60-70 percent using JupiterIO.

We have also used JupiterIO for fast prototyping. We can very quickly mock up IO floorplans using the pattern tiles and get a early view of the die size for new product ideas especially where the IO floorplan drives the die size. We can easily take the IO floorplan from an existing product explore new products derivatives with modified or new interfaces. This approach enables us to more rapidly assess the feasibility for the new design and package options. By swapping interfaces in and out we have the potential to address platform-based design.

The direct connection between the package information in Encore and the chip information in the Milkyway database has dramatically improved the efficiency of the communication within the vari-ous team members. A side-effect of this integration is that we have also seen benefits on the Milkyway side. Accurate instantiation of physical-only cells — such as power and grounds that don’t really show up in the logical netlist — has always been a challenge. These cells must be there to make the chip work! JupiterIO gives us the capability to automatically instantiate these types of cells, without a lot of additional effort.

SC:
Tundra uses multiple tools from Synopsys. How does JupiterIO work with the other physi-cal design tools (JupiterXT, Astro) that make up the Galaxy Design Platform?

BP:
We have successfully used JupiterXT for chip floorplanning and Physical Compiler and Astro for place and route, but previously we haven’t been able to easily account for packaging within this environment. JupiterIO integrates well with these tools and provides a significant advantage for us. We no longer need custom scripts or manual intervention, which are error-prone and slow.

SC:
How do you see the relationship between IC and package design evolving? Are there other packaging technologies that will impact the silicon design process?

BP:
Our view at Tundra is that customers very much need system solutions – not just chips. We need to look at the board-level issues that customers have. For example, overall system cost is important, and achieving that is not as simple as just delivering the smallest piece of silicon. Meeting this requirement is partly affected by the IC package, and advanced packaging techniques like flip chip give us the ability to deliver much more cost-effective system solutions. Tools such as JupiterIO are critical in enabling the potential that advanced packaging solutions offer, and ultimately determine our ability to deliver cost-effective system solutions.

With ever-smaller process geometries on the horizon, the technology links between package vendors and silicon foundries will need to be much tighter. With phenomena such as stress within the physical package potentially affecting the performance of the chip, we will need to have accurate package characterization data available to the IC design flow in order to take these issues into account, and be able to add “design for packaging” to our rapidly increasing list of design challenges.

About Tundra Semiconductor
Tundra Semiconductor Corporation (TSX:TUN) delivers standards-based System Interconnect for use by the world's leading vendors of wireless infrastructure, networking, storage and pervasive computing systems. Tundra System Interconnect allows customers to link critical system components while compressing development cycles and maximizing performance. For more information, please visit www.tundra.com.

About Bryan Peter
Bryan joined Tundra Semiconductor as part of Tundra’s acquisition of Quadic Systems, Inc. in September 2000. He has over 20 years of experience in the IC industry. Bryan received his BSEE from the Universtiy of Illinois (Urbana) in 1981. He worked at Fairchild Semiconductor from 1981-1985 working on Advanced Schottky TTL circuits. He joined Quadic Systems as a Mixed-Signal design consultant in 1985. He has worked on a broad range of IC developments including, Analog PLLs, DLLs, Regulators, custom SRAMs for ASICs. He currently leads the Design and Physical Implementation teams developing Tundra products.

horizontal grey line

©2007 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.

horizontal grey line

Having read this Compiler article, will you take a moment to let us know how informative the article was to you.
Exceptionally informative (I emailed the article to a friend)
Very informative
Informative
Somewhat informative
Not at all informative



Email this article

WEB LINKS
 -Tundra Semiconductor Corporation