Systems architect: Blueprint of a new job in semiconductor industry

Article By : Majeed Ahmad

Custom chip designers acknowledge a growing need for systems architects to coordinate every aspect of a system-on-chip (SoC) design project.

There is a new job on the semiconductor industry horizon, and its title is systems architect. Custom chip designers like Sondrel acknowledge a growing need for systems architects to coordinate every aspect of a system-on-chip (SoC) design project. That includes ensuring that an SoC project meets the specifications and is on time and budget.

According to Paul Martin, Sondrel’s head of design architecture, a systems architect is rather like the conductor of an orchestra. “He or she has to have a deep understanding of all the skills required for a project and know when they fit into the sequence of a project just like a conductor does with all the sections of an orchestra playing their parts at the right time.”

Before going deeper into the nitty and gritty of a systems architect’s job description, it’s important to note that each team in an SoC design project tends to have a specific mental model of the product. For instance, product managers focus on the end-use and product applications. Here, the systems architect’s job is to counter-focus on functionality and execution and ensure implementation of the requirements.

A system architect must draw out the product requirements and express them so that technical and non-technical stakeholders can keep up with the product intent and architectural choices without excessive technical detail.

SoC architecture exploration

A systems architect’s job starts with the requirements capture phase that identifies, formulates and records all known functionality and metrics, including performance requirements in a clear and complete proposal. It also identifies functionality that is not fully understood or may be included later. Here, a systems architect must also determine and plan what tasks are required to complete the qualification and quantification of such functions.

Next, these requirements go through an analysis phase with appropriate inputs from design and implementation teams. This iterative process leads to a specification that includes an architecture design for which all functionality, including estimation of the power, performance and area (PPA) are determined.

Figure 1 The SoC architecture exploration is a rigorous way of capturing one or more application use cases and dataflows that an SoC is required to perform. Source: Sondrel

The architecture analysis includes the architecture exploration, IP selection and specification, verification of requirements, and generation of the project execution plan with major tasks elaborated in later phases. Here, architecture exploration of the candidate architecture is a key component as it refines the architecture design by modeling the proposal and evaluating known or reference use cases.

That dynamically allows the system topology to be defined and provisioning of resources like memory, bus fabric and data/control paths to be allocated. Consequently, it enables functionality aspects such as connectivity, timing and performance to be evaluated and validated for confidence in the correctness of the design. Later phases employ more detailed and accurate models to determine and correct potential errors during the implementation of the architecture.

In a nutshell, a systems architect inspects the results of an exploration exercise and progressively converges to an optimal architecture for the SoC. Then, he or she communicates findings with the product manager, who may decide to modify requirements or collaborate with the systems architect to further refine the candidate SoC architecture.

Systems architect: Job description

The above description of the initial part of SoC design—mainly, SoC architecture exploration—provides a glimpse of a systems architect’s undertakings. Ravi Subramanian, senior VP and GM of IC verification solutions at Siemens Digital Industries Software, says that a systems architect requires a unique set of qualifications. That starts with being very adept at collaboration across multiple levels in an organization.

Another important starter is a significant experience of contributing to SoC architecture and micro-architectures specifications. According to Subramanian, a systems architect must understand the cycle of requirements, analysis, specification, elaboration, modeling, implementation, and verification/validation. “An understanding of workload analysis and computer architecture performance analysis is also critical.”

According to Isabelle Geday, VP and GM of IP deployment at Arteris IP, the job requires a system-oriented mindset, which calls for a holistic approach to ensure the success of the designed systems. “A systems architect needs to have a strong understanding of design and verification and master key aspects for the targeted application and domain.” It also encompasses safety, security and performance, which must be considered at the system level—in the definition of its architecture—to be addressed efficiently.

Figure 2 A systems architect will need to be involved either directly or in an indirect supervisory role from block to subsystem to full SoC design. Source: Sondrel

Geday was the founder and CEO of Magillem Design Services, the Paris, France-based company that Arteris IP acquired in 2020. She added that systems architects should be aware of the targeted application domains, as they will drive system requirements and derivatives management. Hence, collaboration and communication with marketing teams are mandatory to define a product management strategy that efficiently addresses SoC complexity.

Geday noted that safety and security are particularly important as they are now more and more critical for SoCs in automotive, communication, and defense applications. The resulting pressure is relatively recent for semiconductors; for instance, Chapter 11 of ISO 26262 was published in 2018.

Therefore, on one side, systems architects should interact closely during development with experts in safety, security, and performance. On the other side, they need to collaborate with design and verification teams to ensure feasibility and then lead them toward realization.

Another important consideration, as pointed out by Martin, is requirements translation to DSL format required by modeling flows. So, acquittance with the tools generating an executable specification and visualization of the use case is crucial.

Who qualifies for the job?

According to Subramanian, a systems architect must have a strong understanding of computer systems engineering and computer architecture, including memory systems, software, and firmware. That may translate into 10-plus years of experience in defining and implementing architectures for computing units.

A systems architect must understand the cycle of requirements, analysis, specification, elaboration, modeling, implementation, and verification/validation. So, an understanding of workload analysis and computer architecture performance analysis will be critical.

Overall, that amounts to a significant experience in SoC design flows and methodologies for implementation and verification. A systems architect must also be familiar with industry-standard specifications for interfaces. The expertise in balancing power, performance and area or PPA is also a significant plus.

Figure 3 The later phases in an SoC design project employ more detailed and accurate models to determine and correct potential errors during the implementation of the architecture. Source: Sondrel

As noted by Martin, use case requirements are communicated to the systems architect, usually by presentations, spreadsheets or documents. Here, a systems architect must capitalize on previous designs through reuse, said Geday. “However, the definition of a solid reuse strategy that addresses derivatives management and considers variability at the system level is not trivial.”

It requires integrating information from existing IP and subsystems in system-level representations used for reasoning in architecture definition; failure mode and effects analysis (FMEA) is a case in point. “The reuse strategy needs to be backed by a consistent make or buy strategy,” Geday said. “Buy to save time and make to gain a competitive advantage while ensuring the final compliance of both internal and external IP as well as of the resulting SoC design.”

Systems architect: Job breakdown

While different aspects of a systems architect’s job have been explained in this article, it’s important to have a step-by-step breakdown of the job for greater clarity. According to Subramanian, the typical breakdown of the job flow of a systems architect in an SoC design project would be as follows:

  1. Requirements capture: It encompasses working with product management to get a comprehensive product requirements summary.
  2. Product analysis: It involves creating an architecture design specification that covers estimates of power, performance, and area. It needs to include a comprehensive view of how the SoC will be integrated into an end platform and a clear definition of use cases and software workloads that will drive the SoC’s successful adoption.
  3. Architecture specification: A systems architect must ensure that the output of product analysis or the definition of SoC architecture will meet the requirements and the use-case validation methodologies.
  4. Architecture exploration: It encompasses exploration, IP selection and specification, verification of requirements, and generation of the project execution plan with major tasks elaborated. The architecture design is carried out by modeling the architecture proposal and evaluating known or reference use cases. So, all aspects of functionality such as connectivity, timing and performance are evaluated and validated for confidence in the correctness of the design. The later phases employing more detailed and accurate models are used to determine and correct potential errors during the implementation of the architecture.
  5. Modeling: It entails the development of necessary models and modeling methodology improvements.
  6. Implementation and verification: This phase spans the implementation and verification of SoC from block to subsystem to SoC.
  7. Use case validation: It involves the validation of use cases and workloads defined in the requirement phase.
  8. System integration validation: It entails validating SoC and workload under specific use cases within system environments such as software running on an SoC within an advanced driver assistance system (ADAS) design.

Figure 4 Modeling allows the unknowns to be explored, and mistakes in the model are easier to correct than in the SoC. Source: Sondrel

The blueprint of a systems architect job is still evolving alongside the evolution of SoC. However, the fundamental tenets of this new job are likely to remain relevant in the future. Meanwhile, the astronomical costs—in terms of the number of people, tools and NRE—will drive the critical importance of the SoC systems architect job.

This article was originally published on EDN.

Majeed Ahmad, editor-in-chief of EDN and Planet Analog, has covered the electronics design industry for more than two decades.

 

Leave a comment