Open side-bar Menu
 Arteris IP Blog
Stefano Lorenzini
Stefano Lorenzini
Stefano Lorenzini, functional safety manager, has more than 25 years of safe and secure SoC design and architecture experience spanning Arteris IP, Alcatel Microelectronics, Cadence Design Systems, Ericsson, Intel, ST Microelectronics, and Yogitech. He has spent the last 18 years managing SoC … More »

Scalability – A Looming Problem in Safety Analysis

 
July 27th, 2022 by Stefano Lorenzini

The boundless possibilities of automation in cars and other vehicles have captivated designers to the point that electronic content is now a stronger driver of differentiation than any other factor. It accounts for a substantial fraction of material cost in any of these vehicles. But this revolution in automotive technology comes with a caveat. In other applications, an electronics problem may be corrected with a shutdown or a reboot. The same resolution, however, does not work well for cars. Misbehavior in the electronics can lead to accidents, even fatalities.

To address this real concern, the ISO 26262 standard was crafted to set guidelines for electronics safety in cars. This context details the characterization and measurement during automotive electronics design. One of the most important analyses in the standard is Failure Modes, Effects and Diagnostic Analysis (FMEDA) for each component. It lists potential failure modes with the corresponding impact on the system’s safety and methods to mitigate such failures. These reports communicate safety characterization through the value chain, from IPs to automotive OEMs, as shown in Figure 1.
Read the rest of Scalability – A Looming Problem in Safety Analysis

Why Automate Traceability?

 
October 13th, 2021 by Vincent Thibaut

Over the years, Arteris IP has worked with several aerospace, transportation and automotive partners on design systems for avionics, space image processing and processing for scientific payloads. More recently, complex advanced driver-assistance systems (ADAS) projects at various levels of autonomy have been added to the list. One thing common between all these projects has been the tight coupling between system-level specification and all aspects of software and hardware from multiple suppliers and integrators, along with the very tight demands on safety and reliability. All are governed by standards like DO-254, ISO 26262, ECSS-Q80 and others. A common theme in all these standards is the expectation of being able to trace requirements from the system definition to implementation and verification. If a change is made anywhere which invalidates a requirement in this complex web of suppliers and integrators, that problem should be immediately detectable.


Figure 1: Traceability requires linking artifacts and decisions forwards and backwards in time, and at two different
levels: (1) Along the “V” and (2) Across the “V.”

There Is no Escaping Traceability

Although traceability has always been expected in aircraft and spacecraft design, the scope of safety-critical applications has grown beyond the traditional bounds. ISO 26262 requires that safety requirements in the automotive industry must be traceable. Also, IEC 61508 (general electronic safety) and IEC 60601 (medical electrical equipment) require traceability for functional safety. The bottom line, it is getting much harder to avoid traceability requirements.
Read the rest of Why Automate Traceability?

IPD – Chip Design Meets Model-Based Systems Engineering Arteris IP

 
September 14th, 2021 by Vincent Thibaut

Chip designers build circuits that go into larger systems, often extensive ones such as cars, aircraft, ships, satellites and spacecraft. How are those designed, and how do those constraints interact with the implementation of sub-components, like an embedded system?

For many years, the answer was through the exchange of documents – high-level specifications, requirements and key performance indicators. In 2007, the international council on systems engineering (INCOSE) introduced an initiative called model-based systems engineering (MBSE) to formalize the application of modeling to support all phases of system design, from concept through development and later lifecycle phases. The use of this approach is now common in aerospace development. It is also taking off in automotive design and gaining recognition in large-scale infrastructure projects – public works, utilities, airports and seaports. This means it is increasingly likely that new products are aimed at platforms already using or planning to adopt MBSE.

SysML Modeling, From Systems Design to Component Design

System designers must think about the whole system project – mechanical, environmental, software, electronic components and more. These designs cannot be fully represented in C, mechanical CAD drawings or register-transfer level (RTL) language. Instead, unified modeling language (UML) might be a better choice to use, but that is very software-centric. Another popular option, though, is systems modeling language (SysML). SysML is an extension of a subset of UML for systems engineering that eliminates software-only features and adds support for more general needs, requirements, parametrics and modeling. This is now published as an ISO standard (ISO/IEC 19514:2017) and has become a central component of MBSE.
Read the rest of IPD – Chip Design Meets Model-Based Systems Engineering Arteris IP

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.

Read the rest of What Does MBSE Have to Do with SoCs?

Arteris IP Extends IP-XACT to UVM Testbenches

 
July 1st, 2021 by Vincent Thibaut

IP-XACT is a vendor-neutral intellectual property (IP) exchange, configuration and system-on-chip (SoC) assembly standard for portable generator development. The standard is associated with generating a netlist or testing SystemC. It is not widely connected to SoC verification, but this is starting to change because of the proliferation of complex verification IPs (VIPs). IP-XACT simplifies and standardizes building SoC designs around complex IPs. In principle, it could also help develop elaborate SoC testbenches for VIPs.

Read the rest of Arteris IP Extends IP-XACT to UVM Testbenches

Verific: SystemVerilog & VHDL Parsers
True Circuits DDR PHY



© 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