Open side-bar Menu
 Arteris IP Blog
Vincent Thibaut
Vincent Thibaut
Vincent, one of Magillem founders, has spent the last 13 years working with Magillem most advanced customers to build the most complete and comprehensive solution for IP Reuse around IP-XACT IEEE1685. As Chief Strategy Officer at Magillem Vincent is working on bringing the future of SoC integration … More »

What Does MBSE Have to Do with SoCs?

August 17th, 2021 by Vincent Thibaut

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

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2022 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise