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. You will need to determine the best way to manage your project, the design flow environment in which to work and the technology IP that you will use and develop to make your SoC. 

Design Flow

How information is structured is using four high level generic stages that describe the necessary steps in any design flow implementation.

• Architectural Design
• Behavioural Design
• Logic Design
• Physical Design

Information is provided to describe specific example flows of which this Getting Started is the start of the Soc Design Contest 2023 example flow. Other information items in this area will discuss how a specific flow that has been created as an example for the contest and delivers the requirement of the general design flow steps.

One of the first steps in Architectural Design is IP selection. In Getting Started we outline below some of the IP you may need to create your System on Chip.

FPGA Flow for design and verification

An example FPGA flow using Xilinx Vivado and the Pynq development framework for Xilinx Zynq FPGA boards is described. A design rationale adopted for SoC Labs reference designs is to provide a quick and simplified route from FPGA development to ASIC tape out and verification of SoC systems. The IP and the example FPGA design flow environment provide a simple python interactable interface to talk directly through the pins on the chip to the design not via parts of the Xilinx FPGA fabric that can't be synthesised for an ASIC but with IP blocks that can.

ASIC Flow and Physical Design

Information to support a basic ASIC design flow is provided to help simplify the ASIC back-end design effort for those that wish to take their design (within an SoC) through to tape-out. 

Information on the design flow and custom IP to help explain and guide researchers through the design phases of their projects. The information is not meant to be prescriptive but to provide those with limited experience in SoC design and ASIC design an easy pathway into this space.

SoC IP Selection

To support those with limited experience and example SoC is provided. 

NanoSoc:

Is a simplified System Framework based around an AHB Bus Matrix. It has three main system initiators, a Arm Cortex M0 Microprocessor, a Arm PL230 DMA Controller and an Off-chip debug interface. NanoSoC's address space is made up of two main address regions, system memory for program and data memory and an expansion address region for addressing custom Hardware Accelerators. The SoC is provided to help groups focus their effort on custom hardware accelerator logic and reuse a SoC reference design to evaluate it. The idea is that researchers are able to transfer test vector data on and off chip via the debug interface and then use the CPU and DMA to transfer data from memory to and from their custom accelerator logic within the system.

Building an accelerator can be challenging. Building an accelerator which can communicate with external hardware can be even more challenging, especially if you are trying to take your accelerator all the way to an ASIC tape out and verification. The aim of the NanoSoC reference design is simple, to provide infrastructure to enable accelerator designers a quick route to FPGA development while still allowing a simplified way to verify results via a custom ASIC. 

NanoSoc is a System-On-Chip framework based around Arm IP which accelerators can be plugged into and a reliable, agnostic methodology to get test and diagnostic data on and of chip. By providing the groundwork in these two domains, it should drastically reduce the work for researchers to get meaningful results from their designs and means they can spend more time focused on the design and verification of their accelerators.

Accelerator Wrapper logic:

Accelerator Wrapper IP is provided which will allow accelerator designs to easily connect into the AHB expansion region with minimal overhead. It will convert 32-bit AHB data reads and writes to variable-length valid/ready packets to transfer data in and out of the accelerator. An APB interface is exposed to allow APB pass-through to the accelerator engine and to also enable accesses to control and status registers within the wrapper. The wrapper provides for generation of configurable interrupts to the on-chip CPU which can be used for example to setup DMA transfers.

Arm Academic Access IP:

Arm provide a selection of their IP to researchers for academic purposes for no charge. A significant amount of the IP used in NanoSoC is dependent on the IP catalogue provided by Arm. Its free to sign up some please feel free to join the program here.

Structure your Project

The final aspect is managing your IP and your design flow within the scope of your overall project. It is worth reading project structure flow to get an idea of the suggested project structure. This is very important for multiple reasons:

• Updates to IP deliverables - it is important that IP can be updated easily with minimal need to replay custom changes on top of 3rd-party IP. By keeping deliverables in separate directories and repositories which are effectively read-only and only referenced by custom design repositories, it should reduce the risk of introducing bugs into 3rd party IP and means bugs in the source code can be patched by IP providers.
• Separating accelerator design from system design - by having your accelerator isolated from your system it means you can easily transfer your accelerator design into different systems with no need to decouple system components. This is especially important when your system may contain 3rd party IP which you are unable to distribute. 
• Project navigation - it should be easier to locate design files for the designer and for those who are new to the project to quickly understand the location of source code.
• Working collaboratively - if there are multiple people working on a project, having people working in distinct repositories can reduce conflicts within files in repositories and reduce the need to merge changes which can make projects operate a lot smoother.

The suggested project structure is for two custom design repositories per project. A top-level system repository which contains system wiring and verification material for the SoC Labs provided design IP - this will be forked from a provided top-level repository which contains basic design files which can be customised. The designers accelerator design repository(s) will interface to this top-level and will contain entirely custom IP.

More details

Additional updates on the design contest and resources will become available as we move forward together. Please provide any comments or points below.