Introduction

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. Your SoC design is likely a selection and configuration of Arm IP to define the main architecture with specific blocks either developed uniquely or existing third party blocks modified or arranged in a novel way.

The first step is determining the information needed to begin architectural design. Often described as a Specification it should include a list of the proposed uses, specific algorithms or calculations that are to be implemented, what are the data requirements, time critical operations, etc.

At this high level stage of the design process their is less interested in ultimate use of area, power or performance. The interest is in relative observations for different architectural design decisions. The tools available usually rely on static information for area, power and performance that is adjusted/calculated from available configuration database as different architectural designs are evaluated. This can be high level selection such as which processor to use or more fine grained in terms of data paths, cache sizes, etc.   

Separation of Concerns

One technique for controlling the complexity of SoC design is to use the system Architecture to separate aspects of the design task to specific parts of the system by defining a unique sub-system or using a re-usable block. One separation is what should be designed in hardware and what will be implemented in software. For example when considering a specific algorithm considering the relative performance using one of the Arm processors running software versus a hardware custom accelerator. Estimates of instruction and data bandwidth will be needed in order to determine what memory is needed for intermediate storage.

Data Movement Considerations

A proposed Architecture needs to specifically consider the flow of data within the system as a whole. It needs to consider how data will be moved to/from the external environment of the system and through any processing and storage stages. As well as primary data flows for the core operations of the system, secondary data flows such as debug information for error conditions and any systems start up specific flows, etc. need to be considered. 

The overall system data flow between the various components, subsystems and the external environment are a major consideration in determining the bus systems needed to interconnect them. In more complex systems, a network-on-chip (NoC) architectural design may be justified. Arm provides the Advanced Microcontroller Bus Architecture (AMBA) an open protocol for designing SoC bus architectures and there is a basic project here on building system-optimised AMBA interconnect. Local exchanges within a subsystem via hardwired data paths are more efficient than switched structures and keeping wiring lengths short allows energy use to be minimised. 

Memory Considerations

Memory requirements place significant constraints on a proposed Architecture. Memory is usually laid out using specific technology node memory compilers. Placement of these blocks within the system can have implications on routing of interconnect between components. 

System Throughput  Considerations

It is important to consider and time critical operations of the system and cycle times for any system operations. This will allow a determination of the target clock frequency for the SoC as well as the degree of any parallelism operations that can be implemented. This approximate target clock frequency may differ from the final solution but having an initial target will help determine the likely power consumption and outline costs of an ASIC implementation. 

Architectural Design Decomposition / Partitioning

Based on the outline architecture and the Specification the next step is to select design components or IP Selection. Once all the reusable IP parts have been selected and the custom developments unique to the specific research challenge identified, the task of considering the interfaces between the system's components, subsystems, and the external environment. It may be possible to use tools to automate much of the configuration of the interfaces and interconnect for a proposed SoC, arm provide the Socrates Interconnect Tool to configure IP components using an AMBA® interconnect.

These tools may only be able to guide the initial partitioning for typical SoC projects as there is a large design space of decisions for any particular design in order to optimise various system characteristics including energy, area, execution perform, etc. The design may evolve in a process of architectural exploration where different configurations of IP blocks are considered and relative benefits evaluated.