One of the DARPA programs that is part of the Electronic Resurgence Initiative (ERI) is called CHIPS. This stands for Common Heterogeneous Integration and IP Reuse Strategies. In fact, the CHIPS program started before ERI existed, so I'm not entirely sure if it is truly part of it, but it was presented at the ERI Summit at the end of July, so I'll count that as a "yes". The US Department of Defense (DoD) has a problem. It doesn't have enough volume for most parts to justify the enormous design cost of an SoC. If one chip goes in each jet fighter, or each satellite, that is barely a blip of semiconductor volume. Semiconductor design and manufacturing is a bit like pharmaceuticals: the first one costs hundreds of millions of dollars, and then the long run manufacturing cost is very cheap. Only if you want a lot of them is the design cost (or the cost of drug-discovery and trials) amortized. DoD is the other way around: they have to reduce the design cost and, within reason, they don't care about the manufacturing cost since they only want a few hundred or a few thousand parts. A focus of ERI is thus to reduce design costs. Two approaches to this are: MAGESTIC, which is led by Cadence with NVIDIA and CMU. You can read my post about this at Cadence is MAGESTIC . OpenRoad, which is led by Andrew Kahng of UCSD, and which I plan to cover tomorrow. Both of these programs are attempts to do design with no-human-in-the-loop, substituting massive cloud computing resource and deep learning for the human designer. Instead of the designer manually iterating, the tools will iterate on their own. A different approach completely is the CHIPS program. This is a program with the goal of creating a new way of designing systems using "chiplets". A chiplet is a bare die that can be integrated onto a low-latency interposer. There are two challenges to this. The first is that for this to be workable, all the chiplets need to have a standard interface. The second challenge, which is beyond the scope of this program but is in the back of everyone's minds anyway, is to create a marketplace for chiplets. If you can't buy chiplets, you obviously cannot build systems that way. So broadly, there are some technical challenges and some business challenges. Cadence and CHIPS It's like guacamole and chips, but with no avocado. Cadence was awarded the contract as a prime contractor for CHIPS in Q2 last year. Two other key partners are BroadPak, who are experts on interposer design and fabrication, and NIST (the National Institute of Standards and Technology), who are experts on making measurements of electronic systems. The overall goals of the program are to design, build, and test chiplet-based designs. Also to electrically correlate interposer-level interconnect structures to the Sigrity EM solvers. We also plan to produce design kits for the CHIPS participants, including a signal integrity compliance kit for the AIB interface standard , provide tools and training, and, of course, document the whole program. There are two motivations for the CHIPS program. The first is that it is expected that the cost of doing a design this way, compared to a monolithic SoC built using silicon IP, would be as much as 70% less. The second motivation is that many systems have different types of blocks required, and which need different technologies for their manufacture. It is not possible to design RF using FinFET processes due to the excessive capacitance (so I'm told, I'm not an RF guy), but there are also lasers and other optoelectronic devices, MEMS components such as sensors, high bandgap devices like GaN and SiC for high power and high voltage. These cannot be manufactured in the same process, on the same wafer, so the only approaches are to package separate die in some manner. CHIPS is a program to address that challenge. The first phase of the program was to decide on the standard interface for chiplets. The expectation of the program is that chiplets will be built by taking standard IP blocks (such as DDR controllers, or microprocessors, or memories) and adding a wrapper with the microbuffers that take care of signals, ESD, level-shifting and generally taking the IP block and making it "standard". The picture below shows conceptually what a system designed this way would look like. One challenge with all multi-die approaches like this is called the known-good-die (KGD) problem. In a normal package with a single die, if it turns out at final test that the part is not good, then the cost of packaging the part is wasted, but the die was bad anyway (and so had no value). It would be better if it had been caught at wafer sort, but there is a tradeoff between increasing the cost of wafer sort versus discarding the occasional packaged part. In fact, if the yield is high enough, it can make sense to skip wafer sort completely. The economics change with multiple die, since if one die passes wafer sort when it is actually bad, then it will cause the whole system to fail and be discarded. The image above has 10 die on an interposer, so if one of them is actually bad, nine other (almost certainly) good die will be discarded. There is a much bigger premium on known-good-die in this sort of design, and a robust methodology for testing chiplets will be required. Standard Interface The first phase of the project was to agree on the standard interface. After a lot of discussion, the decision was to use Intel's AIB (Advanced Interface Bus). AIB is a low-power, high-bandwidth die-to-die PHY-level interface designed to allow direct chiplet-to-chiplet communication. A big gotcha was that AIB is an Intel proprietary bus design. But at the EIR summit on July 24th, Mike Mayberry, Intel's CTO, announced that Intel will open AIB and provide it royalty free for chiplet communication. Andreas Olofsson, DARPA's manager of the CHIPS program, described it as "Ethernet for chiplets". That reminded me of a conversation I had years ago with a guy from Digital Equipment Corporation (remember them?) back when the first MicroVAX single chip implementation had been created. At the same time, Gene Amdahl's Trilogy was coming up with an incredibly complex scheme for wafer-scale-integration, and getting all the signals in and out. This DEC guy told me that he thought that they had it all wrong. "After all," he said, "you could build a system by taking a wafer full of MicroVAXes already joined together. You only need 3 signals: power, ground, and Ethernet". Current Status The current status of the program is that Interposer Test Vehicle #1 has been build on an ABF (if you insist on knowing what it stands for, it is Ajinomoto Buildup Film—now you can go back to saying ABF like everyone else). Ten units were delivered to the NIST labs in Colorado last month, with 24 more units as the assembly house. The investigation is beginning as to whether the manufactured design matches everything in the design environment. On the right is a photograph of one of the test vehicles at NIST. Interposer Test Vehicle #2 (silicon substrate) is at the final design review stage and should have taped out by the time you read this post. Building a Real Design The next phase is to build a real design. Someone needs to take an existing SoC and re-implement it using the CHIPS methodology. One of the advantages of building an SoC, besides a low manufacturing cost in high volume, which is not relevant here, is that latency (and power) is very low. Taking a real design, and re-implementing it, should shake out issues that just building test vehicles might not. Latency due to the interposer and the wrappers is one of the challenges—if latency is too high then the approach will not work for that design. My experience when I've run engineering teams is that this is so true. No matter how much testing you do, and how much the lead customers do, nothing breaks a tool or system quite like using it for something real. Even re-implementing an SoC is one step back from reality, the first time someone tries to use the CHIPS methodology to build a design they intend to put into production, I am sure new problems will come to light. Ecosystem For this approach to work, eventually there will need to be sources that sell the chiplets. Personally, I don't see IP vendors themselves doing that. Cadence is one of those IP suppliers, but we are not really set up to estimate demand, manufacture chiplets, hold them in inventory, and ship them out against purchase orders. If this is going to happen, I think a more likely scenario is that some specialized chiplet companies take on that task. They will license appropriate IP, arrange for chiplets to be manufactured, probably on some sort of multi-project-wafer (MPW) with many chiplets manufactured at once in the same process, store them in inventory, and handle purchase orders. I know from experience when I worked at VLSI Technology that there is a real art to predicting demand for standard products. Back in the late 1980s, VLSI had a lot of standard products such as UARTs or CRT controllers, that were used to build PCs (mostly). Sales were hopeless at forecasting demand, they would basically forecast zero until they got an order, and then expect the order to be fulfilled immediately. Marketing had some skilled people who would already have predicted this, and ordered the parts so that they were sitting waiting ready to ship. If they underestimated, then parts would not be available on demand, they would need to be manufactured (in that era, I think that was about 10 weeks); if they overestimated, then parts would be sitting in inventory for a long time (best case) or have to be discarded (worst case). Chiplets will be the same. DoD needs there to be a commercial ecosystem for chiplets. As I said above, DoD does not ship in high enough volumes to justify the cost of an SoC design. But even if CHIPS is a resounding technical success, it will not solve DoDs problem if they are the only users, since they don't ship enough systems to make the economics of a chiplet ecosystem workable. They need a significant commercial marketplace to create demand and volume. Luckily, a lot of IoT devices are similar in some ways: multiple technologies such as radios and sensors, relatively low volumes, unable to justify and SoC design cost. IoT and DoD have more in common than a lower case "o" in the middle. The Future CHIPS is a 4-year program and so it is in its early phase still, kicking off exactly a year ago in August 2017. I'm sure I'll be writing about it some more in the next few years. Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧