Design Flow | SoC Labs

This area focuses on the design flow steps necessary to take a System on Chip design from initial concept to final implementation. The design flow for any project spans the four high level generic stages, each describing the steps that need to be completed when developing a SoC design. The example flows section describes specific flow/tool implementations showing different ways to implement a flow unique for your project.

You can use the navigation scheme above for a tree view of the design flow steps with more detail of each step.

We are always looking to add additional resources and references to community work in the various design flow steps. We hope members will declare themselves as 'Experts' or 'Interested People' and also recommend non-members they know have expertise or interest. We are looking to appoint Moderators from within the community to help ensure the accuracy of material in each area, if this interests you please then let us know.

Example flows

The open source community, Arm and other 3rd party are all looking to provide design support environments that simplify the SoC design task, this part of the site is an area for material and discussions on example design flows. A few example design flows have been added that will be used on projects and we encourage the community to share more examples here.

Accelerator Wrapper Flow

In order for an accelerator to be integrated within an SoC, the accelerator needs to share interfaces with the system. In the case of NanoSoC, this utilises an AHB-lite bus. The natural interface exposed by an accelerator engine may be different from that accepted by the broader system. A translation layer will need to be implemented - which has been called a 'wrapper'. The NanoSoC wrapper has external AHB and APB interfaces and will instantiate the accelerator engine and packet constructors, de-constructers and buffers.

Continuous Integration and Deployment for verification

Continuous Integration and Deployment is a project development technique to merge code changes from a project team into a central repository where automated build and testing are used to find any system integration issues and provide versions of the project for continued development an fixes issues.

FPGA SoC prototyping with Xilinx(R) PYNQ(R) platform

FPGA prototyping a System-on-a-Chip design enables the hardware design to be tested at or near real-time and software development to be started while the SoC implementation, verification, fabrication and packaging proceed in parallel. The example design flow developed and described here targets the Xilinx ZCU104 development board, which has a large and capable ZYNQ UltraSCALE+ FPGA, and is fully supported out-of-the-box with Xilinx PYNQ development environment support. The PYNQ platform is recommended in this case as this supports scripted control using Python to manage the FPGA overlays, an

SoC Design Contest 2023 example flow

SoC Labs and Arm have announced a joint 'Bridging the Skills Gap' SoC Design Contest that will run during 2023. This example design flow is provided to help groups engage with the contest. It is not prescriptive but tries to provide useful information in creating a design flow environment in which to develop your SoC design. The information covers example design flow elements that can be used as a basis for your design flow for taking part in the competition. You are free to use a design flow of your own if you have already established methods.

Getting Started

In Getting Started with your SoC design you will need to pull together information on the various aspects of hardware design that support your project.

Clock Tree Synthesis

Clock Tree Synthesis starts the process of signal routing considering the most time critical signals. The aim is to distribute the clock signal to all the design elements to avoid skew and minimise latency. The work involves both clock tree building and clock tree balancing. There are various structures for clock trees, H and X shapes, fishbone, spines, etc. and can have multiple decompositions. Clock tree inverters are placed equidistant to keep the pulse widths symmetrical to ensure edge triggered events. Balancing a tree involves adding clock tree buffers (CTB) for clock skew reduction.

Project Structure

Maintaining a good structure for a Project helps bring together the various aspects of Technology IP, the Design Flow tools and all their interactions, files the generate, etc. Investing time in Project Structure can simplify design activity and ease maintenance later on, especially in a collaborative environment. This involves thinking about a few key factors: How can multiple people work collaboratively on the shared project? How can you navigate your project intuitively? How can use reduce design duplication?

Specifying an Accelerator

As part of the Architectural Design phase and Accelerator Design Flow, before writing any behavioural design it is important to try and specify the accelerator that you intend to make. This allows you to consider a number of factors that you will need to define in order to implement your accelerator in hardware.

Accelerator Design Flow

Accelerator SoC Design Flow Hardware acceleration has many advantages over dedicated software written for general-purpose processors. It can be significantly more efficient, have higher data throughput, reduce load on system resources and take up less physical space on a chip than implementing a general-purpose processor and memory - especially if the task is repetative and discrete. An accelerator can be made up of two main components: an engine and a wrapper. The engine is the functional part of the accelerator.

Algorithmic Modelling Design Flow

One of the first stages of the behavioural design stage of a project is to produce a time-independent algorithmic model which can represent the operation of the accelerator. This allows more flexibility in experimentation and structure of an accelerator and can provide a quick method for finding issues in the concepts of your accelerator. These models can be produced in a variety of languages and are not bound to hardware description languages so languages like MATLAB and Python are often chosen to build models.

Basic System Accelerator Integration Verification

A large part of the behavioural design phase of a project is actually the verification of the design at multiple levels of abstraction. This ideally involves a significant amount of verification at the accelerator internal component level (unit testing), the accelerator engine as a whole, the accelerator at the wrapper level and then system tests. Once an accelerator has been designed and unit tested, it is then a crucial step to integrate it into a system and then verify that it has been connected correctly and is able to communicate with other devices within the system.

Architectural Design

The concept of reusable design patterns is familiar to many disciplines. At SoC Labs we are interested in reusable design patterns incorporating Arm based components with parts that are unique to your specific research challenge. Arm itself uses the term Architecture for defining the processor instruction set, programmers' model and memory model, but not implementation details such as cache sizes.

Specifying a SoC

Requirements Getting Requirements One of the key inputs to Architectural Design phase, before trying to design and build a SoC is to determine and understand the Requirements. These are usually negotiated with customers, collaborators or as part of an understanding the application space in which the SoC will operate.

IP Selection

A SoC design is likely a selection and configuration of Arm IP (using tools such as Socrates) to define the main architecture with specific blocks either developed uniquely or existing third party blocks modified or arranged in a novel way. The SoC Labs site aims to be a place where you can find information on both the Arm IP available freely to the academic community and also to share additional IP that the academic community has developed.

Universal Verification Methodology

The Universal Verification Methodology (UVM) is a standard to create a modular reusable generic verification environment. It aims to reduce the effort of reusing IP by making it easier to reuse verification components associated with the IP. UVM provides an architectural framework and class libraries for establishing verification environments for a Design Under Test (DUT). A Testbench is a flexible way to create a structured approach to verify IP.

Behavioural Design

Takes an Architectural Model and creates a full behavioural description of a system that can be run in simulators or transformed into a technology independent register-transfer level (RTL) description. System on Chip (SoC) designs often integrate digital and analogue circuits and these require different models and methods of simulation and verification. In the digital domain Transaction-Level Modelling (TLM) can create a behavioural description of a system with enough detail to allow verification of the design by simulation but abstracting the designer from many detailed implement

Behavioural Modelling

Creation of a "Behavioural Model" of the system consisting of behavioural blocks each described with a high level description language.

Supports activities including, analysis of system behaviour including timing, execution of tests to validate the system model and in some cases develop and debug software that will operate in the system. A register accurate and fully functional model can be used to develop and debug software. Arm Fast Models are 100% functionally accurate and provide programmer's view models of Arm IP to aid software development. Fast Models trade off higher simulation speed for a higher level of abstraction compared to complete Cycle Models. Arm Cycle Models are 100% cycle accurate mode

Generate RTL

Creation of a independent register-transfer level (RTL) description of the system consisting of registers and data flows from a hardware description language (VHDL, Verilog, etc.). The process usually involves use of an High Level Synthesis Compiler to translate the high level language description of the untimed or partially timed model of the system to an RTL description. The RTL implementation can be optimized for objectives such as power, performance, and area.

RTL Verification

Is a 'design closure' stage to ensure independent register-transfer level (RTL) description of the system is consistent. High level languages have constructs to aid the verification process, these generate the stimuli that are used to verify the RTL design descriptions in a simulation tool.

Logical Design

Technology Selection

Fabrication/deployment of a SoC requires selecting a specific technology that the independent register-transfer level (RTL) design can be transformed into a technology dependent form that can be passed to a fabrication house for manufature, deployed on a prefabricated logic such as a Field Programmable Gate Array or even just executed as a simulation. The choice of the fabrication/deployment path for the system is based on criteria such as cost, power budget, system complexity, gate count, selected IP blocks and many other parameters. Fabrication of devices differs by manufacturer and

Standard Cell Libraries

Standard Cell libraries help simplify the design task by abstracting some of the complexity of physical transistor layout and local connection while still understanding the design tradeoffs to meet the system level goals for power, area, and performance for a system-on-chip (SoC). Standard Cell libraries are a collection of well characterised basic circuits that Electronic Design Automation (EDA) tools use to instantiate the larger design based on the design constraints (optimisation choices, timing, etc.).

Memory generators

In any SoC design memory makes up a significant portion of the transistor count and area. Small memories can be synthesized using flip-flop or latch standard cells, but synthesizing large memories is inefficient in area, energy, and timing compared to using custom bits in a memory block.

Is the process step to transform the technology independent register-transfer level (RTL) description of a system into a technology dependent netlist using a specific technology cell library. Most Electronic Design Automation Synthesis tools support translation from designs written in SystemVerilog, Verilog, VHDL or a mixture of them. Synthesis can be defined to optimise the output for different criteria, for example area use, timing, allowable loads on signals, the movement or merging of registers, or to control the amount of time a synthesis takes. Synthesis attributes and direc

Design for Test

Modify the functional design of the system to add logic to allow control over the system while under test or to allow the observation of operation of the system. Additional circuit elements or probe points can be driven by external test environments including automated test equipment.

Logical verification

By a range of verification tasks test the logical representation of the system. Verification can be by formal (mathematically correct) methods, generated tests and manually created tests. Logical Equivalence Checks are performed against higher level RTL level model descriptions. Gate level verification can be used to ensure the Synthesis translation was correct and the design has not been altered or affected. It also tests low level entities such as power structures that are not represented in RTL descriptions and added during synthesis.

Physical Design

The design flow uses various tools and files during stages of processing to refine the abstract design into the final IC layout artwork of the GDSII file that is needed for foundry fabrication.

Floor Planning

Optimises the placement of all the components, connection pads, macros, standard cells, power, ground, etc, taking account of physical constraints such as minimal area, separation, interconnect lengths, power as well as timing and other considerations.

Completes all the necessary interconnections between components in 2 stages, Global routing locates interconnects aiming to minimise the area used while Detailed routing aims to minimise interconnect lengths.

Timing closure

Timing closure completes the process of adjusting all the design elements and the signal paths between them to meet the overall system timing requirements. It involved analysis of all path delays between elements and the intrinsic delays of element operation within the synchronizing clock pulses and modifying the physical design to remove the timing failures caused by propagation delays longer than the clock cycle time. Closure of a physical design is meet when all timing requirements are satisfied.

Physical Verification

Physical design activities require verification based on physical models based physical quantities. Design Rules Check ensures the foundry technology rules have not been violated and the SoC can be manufactured. Layout Versus Schematic checks the physical layout is equivilant to the abstract logical representation. In the physical domain many attributes have variation. Simulations can be run with variation of parameters such as foundry gate performance, supply voltage, temperature, etc. to ensure the physical design still operates effectively.

Tape Out is the hand over point from the SoC design flow to the physical device fabrication flow. It is usually the point where the design is past from the designers to the wafer production facility.