What is a system architect in SoC design? - Embedded.com

What is a system architect in SoC design?

With advanced chip design going into billions of gates on advanced nodes, dozens if not hundreds of engineers have to work together across various disciplines. The role of the system architect is vital in enabling the design, similar to that of a conductor in an orchestra.

Advertisement

Do you know what exactly a system architect does in system on chip (SoC) design? If you already know or an experienced system architect, then there’s probably no need to read further. But if you are one of our many younger readers who are exploring opportunities in the industry, read on to see if this is you or could be you.

There is a growing need for system architects, as leading-edge digital ASIC design becomes more complex every year and needs teams of dozens of people working on all the different aspects of it.  According to advanced chip design firm Sondrel, systems architects are important for coordinating every aspect of a design project.

Orchestra conductor - Sondrel
The systems architect is like the conductor in an orchestra. (Image: Sondrel)

Paul Martin, Sondrel’s head of design architecture, likened the systems architect to the conductor of an orchestra. He said, “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. Only in this case, it is ensuring that each project meets the specifications and is on time and on budget. Our reputation for successfully doing this is bringing in more projects every quarter which is why we are recruiting for multi-skilled engineers as systems architects in all our design centers around the world to meet the demand.” 

The complexity of advanced node chip design with billions of gates requires large teams of experienced engineers. As Graham Curren, CEO of Sondrel, explained last year in its recruitment drive for engineers, “For example, we recently finished a design on 16nm that required over a hundred people working on it full time for over a year; a resource deployment that would typically only be available within a big blue-chip company.”

The 16nm chip Curren referred to was at the time the company’s largest ever chip design for a customer, a 500 square millimeter chip with over 30 billion transistors, 40 million flipflops, and 23 thousand pads for I/O, power and ground. Around a third of the floor plan of the chip is the block with the customer’s IP that handles the real-time image processing. Sondrel wrapped round that support blocks of graphical processor unit, two central processor units, on-chip cache memory, PCI and USB interfaces plus memory controllers to off-chip memory using over 7 kilometers of metal tracks on a chip the size of a postage stamp.

It would be impossible to design a chip of this complexity in one go as it has 300 million placeable logic cells and the placement tool can only handle three million at a time without the runtime becoming excessive. Hence, it was divided into manageable-sized, functional blocks over four levels of a hierarchy structured like a pyramid.

In order to get to this point, early in the SoC development cycle, product managers, systems architects and relevant technical stakeholders discuss and elaborate product requirements.  Each group tends to have a specific mental model of the product, typically with product managers focusing on the end-use and product applications. At the same time, systems architects focus on functionality and execution, and implementation of the requirements. 

This ‘requirements capture phase’ identifies, formulates and records all known functionality and metrics, including performance requirements in a clear and complete proposal. In addition, this exercise identifies functionality that is not fully understood or may be included later and seeks to determine and plan what tasks are required to complete the qualification and quantification of such functions.

On completion, or as complete as possible at the program’s start, the systems architecture team’s requirements go through an analysis phase with appropriate inputs from design and implementation teams. The outcome of this iterative process is an architecture design specification that includes an architecture design for which all functionality, estimation of the power, performance and area are determined.

The inclusion of design and implementation effort at the initial phase ensures a better level of accuracy and validation for the specification and architecture and identifies the sensitivities needed to guide design choices.

The architecture analysis includes the architecture exploration, IP selection/specification, verification of requirements, and generation of the project execution plan, with major tasks elaborated in later phases.

The architecture exploration of the candidate architecture is a major component. It refines the architecture design by modelling the proposal and evaluating known or reference use cases, dynamically allowing the system topology to be defined and provisioning of resources to be allocated (memory, bus fabric data/control paths, and so on).

While it allows aspects of the functionality to be evaluated and validated (connectivity, timing, performance) for confidence in the correctness of the design, later phases using more detailed and accurate models are used to determine and correct potential errors during the implementation of the architecture.

The initial part of SoC architecture exploration is a rigorous way of capturing one or more application use cases and dataflows which an SoC is required to perform. An accurate and complete description of use cases is necessary to communicate with stakeholders and agree on requirements early in the product definition phase. The systems architect seeks to 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.

Process from system architect - - Sondrel
The process flow from product requirements to executable architecture model. (Source: Sondrel)

This collaboration process has eight steps:

  1. The product manager carries out market analysis, industry trends, and product requirements definition for a potential SoC solution.
  2. Product use case requirements are communicated to the systems architect, usually by presentations, spreadsheets or documents. 
  3. Requirements translation to DSL format required by modelling flows.
  4. Tools generate an executable specification and visualizations of the use case.
  5. Tools also generate the cycle-accurate SystemC model required for use case architecture exploration.
  6. Systems architect inspects results of an exploration exercise and progressively converges to an optimal architecture for the SoC.
  7. Systems architect communicates findings with product manager.
  8. The product manager may decide to modify requirements or collaborate with the systems architect to further refine the candidate SoC architecture.

In order to illustrate an SoC application use case for system architecture exploration, Sondrel has published a paper cover the use of modelling in the architecture phase of the program. The diagram below shows a typical autonomous vision use case data flow graph, with nodes representing processing functions and edges representing data flow. 

Example autonomous vision use case data flow - Sondrel
Example autonomous vision use case dataflow. (Source: Sondrel)

The specific stages in the flow are:

  • Frame exposure – the interval during which a camera sensor takes a snapshot of its field of vision.  The image sensor may be configured in either global shutter or rolling shutter mode, and each mode has an exposure period associated with it.
  • Frame RX – the interval over which pixels of an image grouped in lines are sent to the SoC over a real-time interface such as MIPI CSI-3.
  • Image conditioning – any image pre-processing, filtering or summarisation steps performed on the received data before the actual compute stages.
  • Classical computer vision – well-known vision processing algorithms, for example, camera calibration, motion estimation or homography operations for stereo vision.
  • Computational imaging – vision algorithms are augmented with custom processing steps such as pixel cloud or depth map estimation
  • AI inferencing – neural net based image processing for semantic segmentation, object classification and the like.
  • Data fusion – final stage sensor fusion and tracking.  May also include formatting or packetization processing.
  • Data TX – Can be over PCIE or a real-time interface such as MIPI CSI-3 at a constant or variable data rate.

The paper goes on to define two simulation constructs, the application use case model and the hardware platform model, and then a full simulation model with use case tasks mapped onto the subsystems of the hardware platform. The full paper, “SoC Application Use Case Capture For System Architecture Exploration” is available from Sondrel.


Related Content:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.