Circuit Components
SoC application usecase capture for system architecture exploration
By Piyush Singh, SOC architect, Sondrel E
arly in the system on a chip (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 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 system 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 better accuracy and validation for the specification and architecture. In addition, it 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 to be elaborated in later phases. The architecture exploration of the candidate architecture is a significant 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
20 May 2022
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 remaining sections of this article cover the use of modelling in the architecture phase of the program.
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. 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 8 steps: 1. Market analysis, industry trends, product requirements definition carried out by the product manager for a potential SoC solution 2. Product usecase requirements are communicated to the system architect, usually by presentations, spreadsheets or documents
Figure 1: Example Autonomous Vision Usecase dataflow
8. The product manager may decide to modify requirements or collaborate with the systems architect to further refine the candidate SoC architecture
Industry trends show that vision-based applications are becoming more common to incorporate classical computer vision techniques and neural-net-based AI inferencing, with a fusion step to combine results from the two stages.
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. System architect communicates findings with product manager
Figure 1 shows a typical autonomous vision use case data flow graph, with nodes representing processing
functions and edges representing data flow.
The specific stages are: n 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 n Frame RX – The interval over which pixes of an image grouped in lines are sent to the SoC
Figure 2: Usecase parameter capture in tabular format Components in Electronics
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62
