Sondrel explains the vital coordinating role of Systems Architects

Reading, UK  11 January 2021. Leading edge digital ASIC design becomes more complex every year needing teams of dozens of people working on all the different aspects of it. According to Sondrel, who specialises in these advanced chip designs, there is a growing need for Systems Architects who coordinate every aspect of a design project, hence the company is actively recruiting for specialists with the skill sets that can do this. Please see

Paul Martin, Sondrel’s Head of Design Architecture, explained: “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. 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 centres around the world to meet the demand.” 

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. 

The ‘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, etc.).

While it allows aspects of the functionality to be evaluated and validated (connectivity, timing, performance, etc.) 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.

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 visualisations 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.


Sondrel has an article that covers this topic in greater detail. For an emailed copy, please click here.