Feature: Embedded design
Enabling a critical phase in SoC development
I
By Romain Petit, Product Manager for Software Prototyping solutions, Siemens EDA question of when and how the software stack is integrated with the hardware, and in what environment the integrated design is tested. And to a great extent, that difference comes down to a collection of small, simple circuit cards.
magine two system-on-chip (SoC) design projects, with both to be AI-enhanced hearts of automotive advanced driver assistance systems (ADAS). Both will include I/Os, CPUs, DSPs,
AI-accelerator processing and high memory bandwidth, to accept signals from various vehicle sensors, such as radar, cameras, actuators, displays, data logs and more. One project moves relatively smoothly
to tape-out, system integration and deployment, whereas the other struggles. Much of the hard work of hardware/ software integration waits until silicon is available. Significant issues show up during this effort, and for a while the project teeters on the verge of a disastrous silicon re-spin, before moving into limited deployment with some features disabled. The difference between these two
projects is not the skill of the design team or the resources they use. It is a
Testing: When and how Obviously, on a major SoC project, software development and test can’t wait until silicon is available. Design teams have come up with many techniques to make parallel development work, but one in particular is emerging as the preferred approach. An early, and still popular technique,
is to attempt to separate the software stack into hardware-independent and hardware-dependent portions, separated by an operating system layer and communicating through well- characterised application programming interfaces (APIs). In principle, the larger hardware-independent code can be developed in a server environment with
34 December 2025/January 2026
www.electronicsworld.co.uk
standard debugging techniques, using stubs to stand in for the APIs. Then the hardware-dependent, hopefully much smaller, portion of the code stack can be developed as the register transfer level (RTL) design takes shape, using a hardware emulation system or perhaps even simulation as an execution environment. This approach has its challenges. First,
it is not always easy, or even possible, to determine which portions of the code are really hardware independent. Dependencies may reach unnoticed deep into the application code, especially when intensive I/O and high computing loads must meet hard timing deadlines. After all, software developers must make some assumptions about execution speeds, cache sizes and memory latencies – assumptions that may later prove false. Integration of the software with the
RTL model of the chip is generally going to execute too slowly, even on an emulation system, to allow extensive
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
