I’m not sure if I’m growing to be incredibly old, or if it’s just that everyone around me is getting to be incredibly young. The reason I’m ruminating over this is because a young engineer recently asked me why I occasionally add “where no one can hear you scream” after using the word “space.” When I replied “Alien” in a dark, foreboding, and meaningful way (where the “obviously” was obviously silent), all I received was a vacuous, uncomprehending look in return.

Now, I can understand younger members of the engineering community being unaware of truly antediluvian classics like Departed with Flatulence (I believe this was released as Gone with the Wind in America), but I find it mind-boggling that a modern masterpiece like Alien from as recent as 1979 (which seems like only a few years ago to me) can have evaporated from the collective consciousness so soon. Of course, now I come to think about it, 1979 was 45 years ago, but still… 

Directed by Ridley Scott and starring Sigourney Weaver and John Hurt, the alien in question, along with its accompanying artifacts, were designed by the Swiss artist H. R. Giger. Everything about this film was awesome. In 2021, Phil Pirrello of Syfy ranked Alien at number two in the “25 scariest sci-fi movies ever made,” while describing it as “a movie so influential that it’s hard to think of a time before Alien.”

To cut a long story short (trust me, I could have made it a lot longer), the point of all this is that Alien was promoted with the tagline, “In space. No one can hear you scream.” But we digress…

Speaking of screaming (did you see what I just did there), I’m glad I’m not in charge of all the software that goes into something like a modern automobile, because that would really make me scream. I’m a hardware design engineer by trade. I can write truly awful software in a wide variety of languages, where the ensuing code is so dire it would bring a software developer to tears were I ever foolish enough to expose myself to ridicule in this way. We will return to the topic of automobiles shortly, but first… 

I was recently chatting with Tom De Schutter, who is VP Product Management and System Solutions at Synopsys. Tom was telling me about the Synopsys System Design Group, which has been a thing for about two-and-a-half-years now. Historically, Synopsys has had a big focus on things like Electronic Design Automation (EDA), Intellectual Property (IP), and Hardware Assisted Verification (HAV). The System Design Group embodies and embraces all these aspects into a unified whole.

The raison d’etre for the System Design Group is that software workloads are increasingly defining the silicon that is required to satisfy their rapacious requirements. More and more, systems companies are demanding silicon that’s customized for their workloads. On one side of things we have semiconductor companies, on the other side we have systems companies, and the time is ripe to get everyone talking together, all of which is embodied by Synopsys’s Silicon to System strategy.

Silicon and software are becoming a key part of every system (Source: Synopsys)

This concept covers multiple markets, including hyperscalers (humongous data centers supporting elastic clouds providing mindboggling computational resources), aerospace, industrial, medical, etc. For the purposes of our discussions, however, Tom focused on automotive, so it’s lucky this was the one that was highlighted in purple in the middle of the image above (what are the odds?).

Think of modern automotive manufacturers like Tesla who are building their own processor chips in the form of System-on-Chip (SoC) devices rather than accepting off-the-shelf offerings. Or think of OEMs who are creating applications (that they want to keep secret) to run on SoCs being designed by other companies (who wish to keep their implementations secret). In many cases, the OEMs want to provide abstracted algorithmic versions of their workloads to ensure desired performance on the SoC-in-progress.

Tom says that automotive OEMs are drowning in software (I assume he means this figuratively, not literally). Traditionally, whenever automotive OEMs had something they wanted to control, they added a new microcontroller unit (MCU) and associated software. A lot of people call these engine control units (ECUs) or engine control modules (ECMs), but others reserve the ECU/ECM monikers only for things directly associated with the engine itself, like ignition and fuel injection. You want an electric window? Add an MCU. You want an airbag? Add an MCU. You want a… and, before you know it, you have a car with hundreds of heterogeneous processors, which often come from multiple manufacturers, each running different code, which invariably originates from multiple sources, and then things start to get complicated. 

What we just described may be thought of as a domain automotive architecture. There’s a current trend to zonal automotive architectures, in which a smaller number of higher-powered processors are deployed, classified by their physical location (zone of influence) within the vehicle. In this case, we have multiple applications from multiple sources running on the same processor, all wishing to access the same hardware resources. It probably goes without saying that it would be unfortunate if the application in charge of operating the powered windows somehow managed to interfere with the emergency braking system, for example. Of course, software developers write their code in such a way that things like this could never, ever happen… right?

How big is the scale of this problem? Suffice it to say that exponentials abound in the automotive realm. Consider the following image (sources: Horizon Robotics (2020), McKinsey (2022), IEEE Spectrum (2022), Roland Berger (2021).

Exponentials in the systems world: Automotive (Source: Synopsys)

Good grief! From 2 TOPS for Level 1 (L1) to 4,000 TOPS for L4, from 100 million to 1,000 million lines of code, from 450 million to 9 billion transistors, and from $600 to $5,000 growth in software research-and-development spend per vehicle. Now, that’s exponential!

And, while we’re here, let’s pause for a moment to consider another interesting graphic as shown below. As we see, the electronics in a new car accounted for 18% of the cost in 2020, which was only four years ago at the time of this writing (Source: “Semiconductors—the Next Wave,” April 2019, Deloitte Report). This is anticipated to rise to 45% by 2030, which is but six years in the future as I pen these words (eeek!).

Systems R&D processes are more complex and more costly (Source: Synopsys)

Furthermore, the sequential design flows of yesteryear have been replaced with continuous design flows in which everything is happening at once. All I can say is that I’m too young for all this excitement.

As an aside, my first car, which I purchased in the early 1980s, was a second-or-third-hand Triumph 2000. It had dual carburetors, the setting of whose timing could bring a grown man (or a grown Max, which was almost the same thing) to his knees. Pressing the accelerator to the floor was essentially equivalent to throwing a gallon of gas out of the window. I had hand-cranked windows (I told myself that the lack of electric motors provided one less potential point of failure). To the best of my knowledge, the only electronic system in my Triumph was the radio (which didn’t work). On the bright side, I’m reasonably confident the beast would have survived any electromagnetic pulses (EMPs) in the event of a nuclear war, unlike most of today’s vehicles, which would be toasted like a teacake and dead in the water (I never metaphor I didn’t like). But, once again, we digress…

And thus we return to find ourselves contemplating the mission of the Synopsys System Design Group, which is to help us go from silicon to system without killing ourselves in the process (I’m reading between the lines).

Currently, they are at the level of creating digital twins of the electronic subsystems and providing ways for SoC designers and automotive OEMs to work together in a regular cloud and/or on HAV in the cloud. The SoC designers can ensure their designs can satisfy the software workload requirements of the OEMs, while the OEMs can check that their applications will perform as expected on the SoCs.

And this is just the beginning because Synopsys supports standard application programming interfaces (APIs) that allow their solutions to be integrated with other offerings from other companies. For example, some players focus on creating digital twins of sensors, while others are expert at creating digital twins of environments.

It won’t be long before it’s possible to evaluate all aspects of the vehicle in relation to each other, which will enable automotive manufacturers and OEMs to evaluate dependencies and corner cases involving multiple pieces of hardware and software. A machine vision system may work awesomely in standalone mode, for example, but what about when a (virtual) car meets a (simulated) pothole at the same time as a (computer-generated) bird flies past the front of a vehicle and (the avatar of) a young child roller skates into the middle of the road?

We may not be quite at this level of sophistication today, but we are racing that way, and the folks in the Synopsys System Design Group are paving the path for us to race on. I have to say that I find all this to be (a) mind-boggling and (b) exciting. I cannot wait to see what comes next. How about you? Do you have any thoughts you’d care to share on any of this?