Back in about 2001, when I was last working for Cadence, Cadence started bringing in a lot of executives from Intel. We had merged custom IC and digital IC engineering and I was running the merged marketing groups. We had a lot of customer commitments for mixed-signal design environments, and figured the only way to deliver on them was to break the silos and make a single team, at least for a year or two. The two groups historically barely talked to each other. The biggest issue was that the two environments had different databases, and we had a third database, openAccess, that existed but was not really used in either system. We needed to get that foundation sorted out before anything good would happen, otherwise we were building a house on sand. The Differences Between SoC and EDA Development Around then, an Intel executive came in and took over the whole thing. Like most executives from semiconductor companies, he thought that semiconductor development teams were great, and that software development teams were undisciplined cowboys. He was there to bring semiconductor discipline to EDA development. I pointed out that they were very different types of development. A chip taped out. Of course we released software, but it was never "done" like a chip. He asked me some differences between IC development and chip development, not philosophical ones, but some real facts. I immediately thought of two big ones: On the leading edge, there is no test data. I forget what process node we were up to in that era, but that problem still exists today. Cadence has recently designed software for 7nm design, with via pillars, improved layer assignment due to very high resistance interconnect on lower levels, and so on. One challenge when developing software for a new node is that there are no designs for the new node that can be used to test the software. The first designs, the software, and the libraries all need to be developed concurrently. That inevitably means developing designs on buggy software. The software for non-leading-edge nodes is pretty stable, but can't be used for the leading edge because it lacks the required new capabilities. When a bug is found in a module of software, the team with responsibility for it needs to fix it. For example, if a bug is found in the Verilog parser then it needs to be fixed in the one place the golden source code for the Verilog parser is kept. Otherwise two problems ensue: different tools will end up using different parsers with differences visible to the user, and forever there will be multiple Verilog parsers to be maintained and kept current. To some extent, IP-based SoC design is more like this, but if a bug is found in, say, a USB controller, then it doesn't cause a long-term problem to fix it on a specific SoC and tape it out, and fix up the IP later. Software Development Starts with SOP I remembered all this when I was at the recent Automobil Elektronik Kongress in Ludwigsburg. Johann Jungwirth, Chief Digital Officer for Volkswagen, pointed out that software development for cars is going from the hardware development model to the software development model. He summarized it in the slide above. SOP is "start of production". The old model was that the software for the ECUs would be developed by the tier-1s rather than the car companies (OEMs) themselves. The car would go into production, and then never be updated again. Of course, if there was a major recall then the engine controller or something else significant might need to get re-flashed, but that was definitely an (expensive) exception. The old model was like SoC development; the new model is like EDA development. Tesla, in particular, does not operate like other car companies, they are already on the new model. They do over-the-air (OTA) updates and owners might get into their car one morning to find a new option has appeared on their control panel. The most dramatic of these updates was the October 9th, 2014, when Tesla turned on Autopilot. For some time, all Tesla Model S vehicles had shipped with cameras and sensors but without the software to make use of them, since it wasn't yet complete. On that day, owners who had paid the $2,500 extra for the option discovered that their cars could handle some driving, especially on freeways, on their own. They also had increased safety since they could handle some emergency situations largely autonomously. Here is a compilation video of several examples of Tesla accident avoidance. Volkswagen and other car companies realize that in the future everyone will need to be like Tesla. It is only a slight exaggeration where Johann said that software development starts with SOP. A car lasts for 15-20 years and future cars will be updated over-the-air with new capabilities, bug-fixes, security patches and more. It is almost a cliché to say that future cars are smartphones with wheels, but for sure the user experience is going to be more like our smartphone experience, with updates over the life of the vehicle. The first iPhone was launched 10 years ago (June 29th if you want the precise day). I doubt many of them are still in existence, let alone still in use. But, of course, if they had been cars. most of them would still be on the road, and still require updates to keep them safe. Major Changes in Car Companies Several speakers at the Kongress talked about the changes necessary at car companies. To switch from their old style of development to the new is not just a change in project management that can be implemented by junior engineering managers. It requires a cultural change in the company. Other changes are happening at the same time, requiring further cultural change. I called this The Triple Witching Hour for Automotive , and the above slide shows the same factors. Okay, there are four bullets but #3 and #4 are different aspects of the same thing, that at least some vehicles will be shared and some people will not own their own vehicles. The results are the three items on the above slide. Development of the hardware of the car needs to be separated from the software development. Many cars will share lot of the same software, and probably features in software will do what other features in cars have done, start at the high end of the range and gradually move to cheaper cars as cheaper implementations come with volume. Tesla's model 3 recently reached SOP and I only know what is in the mainstream press, but I assume large parts of its software are common with the Model S. They already have hardware and software development separated Software development doesn't end with SOP, start of production. For a given vehicle, the software will be updated over its lifetime. For a product range, many cars will run large portions of the same software, just as different iPhones run the same software stack. Software development never stops since it is never done Car companies historically have not done much software development, or even any electronic development. They have been system integrators, relying on a hierarchy of tiers of suppliers. Their core competence has been two-fold, building engines, and pulling entire vehicles together from parts purchased from suppliers In the same area of software development, another big change is software testing: a lot of it will be tested in virtual cars rather than loading flashing a real car and sending it out with a test driver. Apart from the issue of danger in the early days, it is just too expensive. VW has a whole cadre of test drivers but it takes them a long time to rack up a million kilometers in a particular vehicle, whereas automated driving in a simulated virtual environment can rack up several times that every day. Changes in the Automotive Ecosystem This change is not just a change for the car companies themselves. It is driving a change in the ecosystem of suppliers surrounding the car companies. The old way was the the OEMs, car companies like VW, Ford or Toyota, would acquire electronic control units (ECUs) from tier-1 suppliers like Bosch, Delphi, Denso or Visteon. Inside each ECU was, typically, a board containing a microcontroller based system acquired from a tier-2 supplier such as NXP or Infineon, who created and manufactured the microcontroller-based chip, and took care of a lot of the reliability issues. The OEMs didn't really know what was inside the ECUs, they didn't even have the source code for the software, and couldn't do a software build even if they did. The new way is that the key software will be controlled by the OEM. They may acquire some software, especially operating systems, network stacks and the like, that are not specific to their vehicle or, often, even automotive in general. Some might design their own silicon, if the history of the mobile industry is any guide where the top players all design the key chips themselves. They will continue to buy some ECUs and subsystems from the tier-1s. For example, having subcontracted ABS systems since they were invented, it is doubtful if a car company could build one themselves even if they decided strategically they wanted to. The result is that the industry structure will no longer be layered with OEM, tier-1, tier-2 and so on. Instead, it will be more of a network with the OEM at the centre and make a whole set of make/buy decisions that might change over time that involve partners from the network. Sign up for the weekly Breakfast Bytes email:![]()
![]()
↧