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. Requirement statements need to be actively probed to define a useful set of constraints and components for your SoC.

A good list of requirements would take into account the following:

• Performance based on average and edge-case use cases
• Power Consumption
• Technology target (ASIC/FPGA)
• Footprint
• Packaging requirements
• IP availability
• Time requirements
• External interfaces
• Memory size and speed
• Debug
• Chip Inputs and outputs

Once a list of questions is drawn up and answers have been found or negotiated to these questions, a specification can start to be drawn up around them.

Outline Requirements with Justification 

The first thing to include in a specification is the requirement statements and outlined reasons each of these requirements is justified for the target application, why have they been selected and supporting evidence for each of the requirements.

System Architecture

The next stage of developing your SoC is to considier the architecture of the SoC. This involves thinking in broad strokes about the type of components needed in the system, the interconnects and interconnect strategy for the system, the external interfaces from the system to the real world application space and more. 

System decomposition

The first part of this is to break the system down into subsystems. What subsystems are needed in the system, how many and how do they all coordinate with one-another? 

A list of example subsystems could be as follows:

• CPU Subsystem
• Memory Subsystem
• DMA Controller Subsystem
• Graphics Subsystem
• Multimedia Subsystem
• External Connectivity Subsystem
• Power and Clock Management Subsystem
• Security Subsystem
• Accelerator Subsystem
• System Control Subsystem

Some of these subsystems may not be applicable for some SoCs and frequently, some of these subsystems may be grouped together into a single subsystem. Reviewing and getting a good working overview of the Arm ecosystem described in the Technology section of this site will allow you to better appreciate subsystem options.

It is important to highlight the subsystem choices made and the relationship between different components to make the system easier to understand and can help in floor planning on an ASIC.

Interconnect Strategy

A key thing to decide from an early stage is what signals and interconnects will run at the top level of the system. To make the system easier to integrate and verify, reducing the number and type of signals is very important and makes it easier for people to understand when reading RTL or looking at system diagrams. If possible, reduce the signals to bus/interconnect (AXI/AHB/APB), interrupt connections and power management interfaces with minimal other control signals.

At this time prepare an outline of which interfaces you expect on each subsystem.

Subsystem specification

The subsystem specification phase is where design time is spent thinking about the components within each subsystem and how they connect with one-another.

At the specification phase, not everything needs to be completed in detail as some of this can be left to the implementation phase but outlining the key blocks and the interfaces and interconnects within each subsystem is the aim of this stage.

Key System IP and Component Selection

Thinking about the IP that will be in the system (and the subsystems that it will go in) and whether these are to  be created as part of the project or used from licensed and open source is a large part of the specification process. Again perform some technical and other justification analysis for the components selected and highlight their key features.

External Interfaces

Prepare a list the external interfaces on the system, the speeds at which these interfaces will run and the number and type of pads that are associated with these interfaces. This is more important in ASIC designs where the number of pads can be very limited making it  an important constraint on the system and so establish early on how many pads are needed and if some of these pads can be shared between interfaces (i.e. multiplexing). 

Power Management

One thing that can be really important is power management. Thinking about this from an early stage and specifying your strategy is a good move. This can involve thinking about the different clock and power domains in the system, which subsystems and components will be running on which domain, clock gating strategy and power interfaces. Allowing the components in your system to communicate with power controllers allows for power domains to be switched off when the components in that domain are not active and interfaces such as the AMBA Low Power Interface are able to facilitate this. 

Performance

Determining a range for clock frequencies used in the system can be a good thing to allow designers to get an idea of the throughputs of the system and subsystems. This can be refined over time with modeling. 

Supporting Documentation

The supporting documentation should include references to external datasheets, reference guides, application notes and implementation guides. It should also reference internal specifications for subsystems (if applicable), other modelling documents which may include calculations related to the specification and implementation documents which detail more of the implementation side of the system design covering things at a lower-level. 

Verification documentation should be referenced also such as System and Subsystem verification plans.

Project Plan Outline

An outline for the development of the SoC should include the different phases of the design that need to be completed, the order in which they will be completed and the dependencies.

Coming up with a set of rough Milestones can be a good way to check progress. These should cover:

• Subsystem Design Phase
• Subsystem implementation Phase
• Subsystem verification phase
• System Integration Phase
• System Verification Phase
• Milestones for back-end flow

Thinking about the integration within a testing environment and a testing schedule should run in parallel with the design activity from the start of the project in order to make sure stages are not left undetermined along the way.

Document Revision Control

Keeping a versioning system in place on documents is incredibly important, especially when multiple people are working on them and on documents which are likely to change across time (the specification being one of them). Having tools or a scheme in place to handle this is imperative as you want all people on your team to be referencing the same version of a document