Path Finding V1.0 vs. V2.0

By Bill Martin, President and VP of Engineering, E-System Design

Path Finding for homogeneous silicon has existed for decades.1 Moore’s Law V1.0 predicted homogeneous silicon scaling. Homogeneous Path Finding V1.0 was divided into two areas:  logical and physical. With Moore’s Law V1.0, implementation tools could perform BOTH Path Finding and Implementation functions.

Engineers focusing on logical design would create multiple variations of synthesis scripts to see which would provide the best results for speed, area, power while minimizing timing issues (setup/hold, race conditions, etc).

Engineers focusing on physical implementation would create multiple floor plan variations to determine which floor plan would route while minimizing area and providing the highest performance.

Often, Path Finding experiments are executed on server farms for several days of high CPU and memory activity while storing gigabytes of results. When completed, engineers would review the various logical and physical experiments’ results, learn from these experiments and choose the better alternatives for the next round of experiments. Each Path Finding iteration would “inch” them closer to a workable solution. This can work well for homogeneous silicon solutions where all constraints are contained within a single die.

As we enter the “More than Moore or Moore’s Law V2.0”, can Path Finding be used with heterogeneous 2.5/3D solutions where multiple die are interconnected with balls, pillars and/or wire bonds?

The short answer is yes, but…

With 2.5/3D solutions, additional components must now be considered before the classical logical and physical Path Finding described above. Similar to our highway and road infrastructure (including traffic lights and HOV lanes), a user needs to ensure that proposed components can support their design’s required performance. Unlike our roads where congestion happens and a commute might take longer, our products’ electrical designs are more rigid when and where signals must arrive. Signals delayed by poor infrastructure choices will arrive late causing latency in your system (best case) or failing to take action on critical data (worst case).

2.5D/3D no longer allows classical implementation tools such as synthesis and place and route tools to perform ALL Path Finding. Neither of these functional tools can work with nor analyze balls, pillars, wire bonds or even how multiple components interact with each other.  When working in multi dimension packaging, the performance of the final product rely on the interconnect options used.2,3 Balls, pillars, wire bonds, redistribution layers (RDL) and how all components are configured will dictate the performance of the structure.  Slight variations in ball/pillar profiles or wire bond diameters/lengths as well as RDL pitch can have dramatic affect on a structure’s performance. Old implementation tools need to be augmented with a new class of Path Finding tools specifically created to analyze these complex heterogeneous infrastructures.

Migrating to Path Finding V2.0:  design flow impact

Augmenting a current Path Finding V1.0 to V2.0 is fairly simple:  just include heterogeneous Path Finding PRIOR to any logical/physical Path Finding.  Structural options must be evaluated and finalized BEFORE individual die begin their own Path Finding (within the die).


1.         While at VLSI Technology (1985-1997), we often performed Path Finding experiments to minimize die size while increasing performance

2.         “Path Finding: Who performs and When?”, Bill Martin, GSA Forum June 2013 Issue.

3.         Bill Martin, various 2014 blogs located at:

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: , ,