Using co-design to optimize system interconnect paths
Developing the methodology
The co-design methodology began to evolve at Cisco when we first realized there was a potential solution to our problems. As system engineers, we faced the constant challenge of finding solutions to compensate for poor package pinout and design.
It is always frustrating to untangle signals that could have been optimized in the package the first time around, and it is very difficult to force package changes once the design is finalized.
With the new power and signal requirement on our latest ASICs, we have found that bringing the package design inside Cisco provides many benefits. Focusing on the power delivery network, optimizing package decoupling capacitors allowed us to reduce the overall capacitor count used at the board level.
This, in turn, reduced the overall product cost. In addition, designing the package and board together gave us control over the package footprint, which had the potential to save our layout engineers a lot of time routing the board.
Traditionally, the package and board use separate design tools, and so we struggled with getting an optimized overall solution. Large-scale changes, such as moving a bus from the North to the South side of the package, were fairly straight forward.
But without an integrated view, it was difficult to see that a parallel bus could be mirror image between devices and/or how it would optimally connect to the components on the PCB.
This was the basis for our requirement to have an integrated board, package, and die environment.
The netlist data and how it is communicated to the different design teams has also evolved due to necessity. Visio and PowerPoint were the main way we communicated graphical data between teams, and netlist data was managed through Excel.
However, as we were optimizing the package and PCB, it was not uncommon to have change requests coming from the IC design team. Merging their changes into the same Excel spreadsheet, which had the changes from the package and the PCB, was a manual process and error prone.
There was a constant concern that something would go wrong in this process and the only verification step available was manually pouring over the data and checking line by line. This became quite tedious.
While we knew that collaboration among chip, package, and PCB design was necessary to build a reliable and cost-effective product, we quickly came to the conclusion that automation was required. We consulted with our EDA tool providers for chip, package, and PCB design tools.
Fortunately, the EDA companies were aware of the need for each of these design groups to communicate more effectively.
As Cadence supplies each physical implementation tool, it was a natural step that they help with this overall solution. They addressed this through the development of a full co-design solution, which Cisco has partnered with them to develop.
On the physical side, Cadence has existing capability to allow the I/O pad ring of the chip to be imported to the package design tools. They also have a method to bring the package and PCB design together into a single tool for optimization. However, these were separate steps and the need arose to integrate these together into a seamless flow.
On the logical side, Cadence had developed a connectivity management tool that supported the ability to review changes (ECOs) and either accept or reject those changes. They also had a verification methodology where the netlist could be compared to the physical design (LVS) and anything out of sync could be easily identified and corrected.
These methodologies were extremely useful in getting us past some of the stumbling points we had encountered using our in-house solutions. Unfortunately, the EDA solution was fairly new and not complete, so we continued to evolve our in-house solutions while collaborating with Cadence.
As we continued to evolve our methodology, we worked with our EDA tool suppliers for both implementation and analysis. We currently use multiple EDA suppliers’ tools to extract and analyze the entire system.
A best-in-breed solution is essential for our development cycle. Fortunately, Cadence is core to our process and the other suppliers’ tools communicate with Cadence tools to help the extraction and modeling of the system from the physical database. This allows us to combine system data into a single simulation.
Each iteration of our designs was becoming smoother from a methodology perspective. We eventually found a balance of EDA tools and in-house solutions that got us to a point where we could clearly see the advantage of bringing the package design internal to Cisco. However, we certainly preferred to have a pure EDA flow as it is expensive and risky to maintain in-house tools and software solutions.
Cadence was persistent in their efforts to close the gap between what they could provide and what was needed to have a comprehensive design flow. The latest versions of the EDA tools provide netlist management in a system connectivity manager (SCM), a single-window view of chip, package, and PCB together for easy optimization (Figure 2, below).
We still see a lot of improvements that could be made to the flow, which we will discuss later in this article.
Figure 2: Using System Connectivity Manager to author hierarchical IC-Package-PCB netlist
However, without the co-design methodology that Cisco has developed with our EDA tool suppliers, we would be extremely challenged to meet the productivity and profitability goals we have been given by our management.
Target Methodology Objective
As with all design teams, Cisco’s end goal is to deliver a higher performing product in a shorter amount of time while reducing total development cost. However, given the ever increasing need to provide more features in less space, we anticipated that it would eventually become impossible to even deliver products unless we streamlined and automated our design flows.
Only with upfront planning among PCB, package, and ASIC design teams working in parallel are we able to minimize hardware cost, reduce design iterations, and meet performance requirements. This section describes the flows and tools we have found necessary to accomplish these interdependent goals.
Loading comments... Write a comment