What Does MBSE Have to Do with SoCs?

In technology, the only constant is change, sometimes at a dizzying pace. One emerging trend is how product specifications, additions and changes are passed onto system-on-chip (SoC) design teams. Traditionally, this transfer is done by exchanging documents, models (perhaps Simulink) and some form of written use-case descriptions. However, this process is very cumbersome, subjective and error-prone. It is also a very poor method for documenting and tracking revisions required by agile design teams employing best practices. It may not be a problem when building catalog products, but the world has changed. Requirements are now defined much more collaboratively in automotive, aerospace and other domains and enabled by a process called model-based systems engineering (MBSE).

What Is Model-Based Systems Engineering?

Systems engineering is about the total system – an aircraft, spacecraft, airport or seaport, or more recently, a car, truck, and high-speed trains. These systems are architected by teams using many disciplines: mechanical, electrical, software, aerodynamics, thermal, etc. Once each engineering discipline defines the various parameters, each element has a purpose.

Now let’s examine the role of the microchip designer. There are a couple of points worth noting. First, the goal is to fit each of the parts into the system, not the other way around. System designers can take the easy path and dictate sizeable feature changes, but instead, they should ensure no new requirements should impact the design. The second point is that requirements can change in-process. System architects may find holes in their models, sometimes when development is already underway. Fixes to plug those holes can then ripple through the entire supply chain. Then, all the annoying consequences of those changes must be dealt with, e.g., updating the design, re-regressing and updating tests, and modifying implementation. An even more painful effect of adjustments is tracking the processes of continued compliance of the specification against paper documentation, Matlab models and who knows what else.

Automating the System Specifications

Consider creating the standards using machine-readable specifications. There are several possibilities for this technology. One is the unified modeling language (UML), which works very well for software developers but is alien to other domains in systems design. Another is the object-process methodology (OPM), also very software-centric. The same is true for the automotive open system architecture (AUTOSAR) – well respected in automotive but not general enough for this purpose.

One standard that aims to span a wide range of disciplines is the systems modeling language (SysML). It is an extension of UML with additions for requirements, parametrics and modeling. It started as an open-source project and has now progressed to become an ISO standard. Lockheed and NASA, among others, have reported the use of the technology. Currently, it is working its way into Tier 1s and other suppliers in the automotive value chain, and Bosch is an active user.

SysML aims to be a single source of truth for systems modeling in support of MBSE. In fairness, it is not all the way there yet but is progressing enough that it now has active users. In part, this is because software and methodologies to support the standard are now available.

Consequences for SoC Design

An SoC designer could argue that “OK, systems engineers have some automation. Good for them. They can print it out and hand it to us.” But that misses the point. By starting with the software implications, the SysML model defines requisites, use-cases, etc., and the software, which may, in turn, impact the SoC structure and memory map. Those needs are probably buried somewhere in that pile of printed documents, but has the SoC designer caught all those stipulations?

Traceability is another critical factor. Suppose this chip will go into a car or a tactical fighter. In that case, the system builder wants to be sure everything specified has been implemented, and verification has checked every requirement, as defined down to the IP level of the SoC design. Can all of that be tracked through a requirements traceability spreadsheet?

How can systems engineers connect more effectively to SysML? Several companies and research institutes are already working with a link between SysML and IP-XACT. Designers use the IP-XACT model for an SoC to provide software interface mapping down to the IP level. This collaboration could equally be extended to traceability. At Arteris IP, we are working in several such partnerships. Contact us to learn more.

Category: SOC

This entry was posted on Tuesday, August 17th, 2021 at 5:02 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.