Inside The System-Level Supply Chain

Miscommunication, complexity and disaggregation are all pointing to a need for substantive changes in how companies work with each other.


System-Level Design sat down to discuss supply chain issues with Bill Chown product marketing director for the system-level engineering division at Mentor Graphics and a longtime participant in a number of standards efforts across the semiconductor design industry. What follows are excerpts of that conversation.

SLD: What’s happening with system engineering as chip design/manufacturing moves outward? How do you manage that process?
Chown: On a macro level, you find yourself with a Boeing 787 battery challenge. The subsystem is the problem. Batteries supplied by one manufacturer into the electrical subsystem are basically supply chain to supply chain. Where will you identify the part of the supply chain responsible for the problem? The same interdependencies and risks in the supply chain that occur in the macro level also occur at the semiconductor level. Who will guarantee the silicon? The foundry? Who pays when it does not work? The same supply chain problem ripples up and down.

SLD: You’d like to think that both sides would have developed models and tests beforehand so that you could go back and find out if there was a technical fault. Does it work that way?
Chown: I don’t think that such an approach exists in any market, especially one that’s written into the contract. I’m glad to be proven wrong. In general, the contract says that you, Mr. Supplier, will supply me with something that works. Not you will supply me with the models so we each can each model it out and decide/agree to what it means to have everything work.

Nobody’s supply chain works that way, but we do encourage it in our tools. The goal is to share requirements in a tangible and executable form (which is what a model is), and thus use those as a method to validate each other’s opinions as to what the requirement actually means and whether it can be met. The model as serves as a validation at the delivery stage.

SLD: Why isn’t that being done? Is it difficult to agree to right kinds of model or how the data will be shared?
Chown: How the data will be shared is a technical issue that can be solved. It’s more a matter of policy, of principle. In the automotive industry we’ve built up over the years a strong principle of, “What’s mine is mine and what’s yours is yours.” For example, I know how I wrote my algorithm to make automatic windshield wipers respond when it is raining. But I won’t tell you how that is done because you’ll share it with another supplier who will do it cheaper. So, in the automotive market, you have a significant reluctance to share at a verifiable model level. Thus, you have a very vertically integrated supply market. So if you want a windshield wiper system, you get the entire system from one vendor, which controls the switches, motor, algorithms and all the other parts in between.

Now, the automotive industry is changing, thanks to the AUTOSAR standards. These mandate a technical separation between software and hardware. This requires more unit and integration tests.

In the silicon supply chain, some silicon companies are demanding sufficient information from the designer to enable them to test out the silicon so they can say that, ‘Yes, the silicon works.’ Other vendors in the foundry business won’t do that. Instead, they’re saying they’ll put silicon together and promise that the layers are layered the way they should be and the vias are via-ed where they ought to be, but it’s up to you to figure out whether the function you get is the one you wanted. If you are Intel, you hold the whole process in your hands. You do it all. One foundry may not offer a functional promise while other foundries will. For example, you give them the wherewithal to do it and they’ll do functional testing and show that the chip they sold you is functional. There are lots of choices.

SLD: It will have to be resolved going forward, unless things get even more vertically integrated.
Chown: The silicon supply chain has moved away from a very vertically integrated market. Hence the emergence of the fabless model. Now, where in the supply chain are the handoffs? What are you doing in writing up the spec so liability is in the right space?

SLD: As the semiconductor market embraces software, it has to look outward to the bigger system. So are these supply-chain issues are getting more challenging?
Chown: Yes. Do we even understand what system means as we are defining the problem?

SLD: As we move outward, how do we embrace a larger system such as the board? And how will that affect the larger supply chain?
Chown: We’ve made a lot of progress in design tools that handle chip/board layout and the physical mechanics of that problem. I’m not sure we’ve done a lot with the functional characterization of what we are doing, which are the problems. This gets back to the need for models. I’m a proponent of model-driven system engineering for a lot of practical reasons. How can we understand the problem when it goes beyond the scale of something we can visualize in our heads or hold in our hands? We need to characterize that in ways that are captured, actionable, reusable, prove-able. Models enable us to do that. Models allow us to transfer information across the supply chain transitions in a verifiable way. For example, ‘I know you think you heard what I said. What you don’t understand that what I said is not what I meant.’ Models will capture that for you and show you the inconsistencies.

In dealing with one of our customers, talking about all the details of all the things that you touch when building an implantable pacemaker, there are more than 400 million artifacts. I don’t mean transistors or components or things on the BOM. I mean requirements, tests, test results, steps in the design process, iterations that must be performed—400 million of them for a small device about the size of a small Nokia phone. Why so many? The point is that it has gone way beyond the scope where we can get it right the first time. It isn’t right the first time. We have to iterate and iterate. Further, there are more than 17 different suppliers that you must deal with. There are 10 tool vendors with 45 different tools handling this information, etc. It’s amazing anything ever gets done.

We work around our lack of process, or models, but such things that would allow us to handle these things. We work around with personal due diligence. We don’t stop making silicon because our supply chain is broken. But we take a little longer than we thought. We end up with more defects then we would like. We end up with 2.5 design cycles when we really aimed at 1.2 turns of silicon. We work around the problem.

SLD: One would think we’d come to a point where it gets delayed too long or have so many defects that it will force a major change in the design chain.
Chown: Yes.

Leave a Reply

(Note: This name will be displayed publicly)