Open side-bar Menu
 Arteris IP Blog

Managing SoC Hardware/Software Interface With CSRCompiler

October 25th, 2023 by arterisip

Author: Rich Weber

Richard Weber is a fellow at Arteris following the acquisition of Semifore, the company he founded and managed for 17 years as CEO. He has served as a committee member for the IEEE Standards Association and the Accellera Systems Initiative. Rich holds a B.S. in computer engineering and an M.S. in electrical engineering from the University of Illinois Urbana-Champaign.

Many people fail to fully appreciate the difficulties of managing the Control and Status Registers (CSRs) that permeate today’s system-on-chip (SoC) devices. Similarly, they fail to comprehend the catastrophic consequences if the CSRs are not managed correctly and completely. These consequences may result in the device needing to be respun, costing millions, and the delay may cause a more severe outcome by completely missing the market. Today’s SoC can contain hundreds of IPs, each containing millions of gates. Furthermore, these IPs may contain hundreds of thousands or even millions of CSRs featuring a sophisticated combination of software and hardware. The hardware/software interface (HSI) accounts for a large proportion of the problems that arise during SoC development. In fact, the data presented in a recent study from a leading research firm suggested that as many as 1-in-7 SoCs must be respun due to HSI errors stemming from CSR mismanagement.

Read the rest of Managing SoC Hardware/Software Interface With CSRCompiler

Automating System-on-Chip Integration for the 21st Century

July 19th, 2023 by arterisip

By Pascal Chauvet

Today’s multi-billion-transistor system-on-chip (SoC) devices are composed of hundreds of functional intellectual property (IP) blocks. The creation of SoCs is typically a combination of acquired IP blocks from trusted third-party vendors and a few internally developed IP blocks containing the secret sauce that differentiates the design from competitive offerings.

Third-party IPs may include central processing units, graphics processing units, memory subsystems, dynamic memory access controllers, external memory controllers and communications functions such as Ethernet, USB and MIPI. Internally developed IPs may include hardware accelerators and machine learning inference engines.

The different IP blocks must be carefully integrated for the device to work properly. SoC integration is the process of gathering all of these IPs together to form a complete device, but this involves much more than simply plugging them into each other like the pieces of a jigsaw puzzle. SoC integration is challenging, involves hidden complexity and is prone to errors.

Designers consistently integrate diverse content from multiple sources while collaborating with teams across various sites with limited cross-team synergy. A large variety of their tasks necessitates a significant amount of manual operations. Because of these challenges, designs are delayed and schedules slip, leading to missed time-to-market and time-to-revenue goals.

Read the rest of Automating System-on-Chip Integration for the 21st Century

Arteris and Arm Put the Pedal to the Metal

October 20th, 2022 by Frank Schirrmeister

The pace of change is picking up in the automotive industry. Three areas of innovation are converging. The first is the trend toward electric vehicles (EVs). The second is the increasing sophistication of advanced driver-assistance systems (ADAS) combined with ever greater levels of autonomy. The third is referred to as the “digital cockpit,” which—broadly speaking—refers to the digital experience within the car, including instrument clusters, multi-screen displays, heads-up displays, advanced navigation systems, infotainment systems, voice assistants and the list goes on.

All of this is leading to the concept of software-defined vehicles (SDVs), whose features and functions are primarily enabled through software with updates and new services being delivered over-the-air (OTA). SDVs offer significant safety and convenience features and enable new in-vehicle experiences and functions.

Read the rest of Arteris and Arm Put the Pedal to the Metal

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

© 2024 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