Getting Started

Introduction

This Getting Started should help you to determine the best way to manage your System on Chip ("SoC") design project. One of the aims of SoC Labs is to bring industry best practice to academic led projects.

One of the things that allow industry to design and fabricate the many SoC designs we depend on in our daily lives is their their use of defined design methods, project development environments, and specific tool chains that are re-used across many SoC design projects. Good re-use is not limited to the IP parts of the SoC hardware design but covers almost everything in the design environment, source repositories, design knowledge bases, verification environments, as well as all project deliverables including software assets and associated materials. In order to have good IP and design reuse there is a need to have investment in all the other areas of project development to support it. These are aspects that academic institutions tend not develop and even less manage to reuse across multiple projects. One of the aims of SoC Labs is share best practices across academia.

Project Management

This design flow area of the SoC Labs site lays out high level generic stages and steps within them that describe the necessary activities in any SoC design flow implementation.

Architectural Design
Behavioural Design
Logic Design
Physical Design
Post Silicon

SoC Labs provides a simple way to manage the activities needed to take a SoC design from initial concept to fabrication and post silicon validation.

Once you create your SoC Labs project it is easy to add each of the activities needed to complete the project, simply 'Add new project milestone' and ...

Under Project Milestone section click on 'Add new project milestone'

and then select the design flow step by starting to type and select from the drop down list.

select the design step by typing and select from the drop down list

When you complete a step you can capture the date and details of the work so you can review as and when needed. It also provides help to other SoC Labs projects who can use the information to aid their projects. Here is an example from the Sensing for Precision Agriculture project by the University of Sydney.

Each of the stages and steps in the design flow area has generic information for the activity an additional information in relation to each of the SoC Labs reusable reference designs and also how the design flow step is implemented and supported within Electronic Design Automation and other design environment systems.

Look out for detail information in sections like this:

nanoSoC reference design: Specific details on how the generic design flow step is implemented for a nanoSoC reference design

Design Methods

There are a small number of different design methodologies, our view at SoCLabs is not to be proscriptive apart from there should be an active decision to adopt one and make best use of it for the specific design activity.

Agile Design

In this design methodology, iterating in short development cycles, each to allow additional understanding of the design purpose, is a fundamental principle.

It leads to development of a project development environment that contains Continuous Integration / Continuous Deployment infrastructure.

Formal Design

In this design methodology, additional design effort is applied to define more precisely the specification of the system such that it can be verified by formal proofs. This usually involves the use of more formal specification languages.

Access to IP

Arm supports the semiconductor industry by providing highly re-usable IP for the compute needed within a SoC design that significantly simplifies the system development process. SoC Labs as a community uses projects to help us share and reuse hardware and software developments around core Arm IP to enable us to better achieve our research goals. A SoC Labs project is likely a selection and configuration of Arm IP to define the core of the system architecture with additional specific blocks developed uniquely as part of a project. Arm provide under the Arm Academic Access programme much of their IP to researchers for academic purposes for no charge. Its free to sign up, please ensure that you have joined the program here.

You will need to obtain permissions and download some of the Arm IP which is listed in the technology section of this SoC Labs site. The SoC Labs reference designs extend and enhance the core Arm IP tailoring it for easy adoption by the academic community. One of the first steps in Architectural Design is IP selection. which outlines some of the IP you may need to create your System on Chip.

Version Control

Version Control systems such as Git are incredibly useful tools and help provide structure to project work and design activities. Having a single or multiple repositories for your project enables:

Collaboration with people able to work on different features of a project independently using branches which can then be merged, making it easy to track and visualise changes as well as see who is contributing to specific parts of a project
Delivery to others by download and use your code by cloning the repositories

Structure within your Project

There are a small number of important structures to maintain in your SoC design project and they are often hierarchical organisation schemes. For example this SoC Labs site has a hierarchical organisation scheme. How the various files in a project source control repository are structured is a hierarchical organisation scheme. How the various parts of the system design are separated and laid out usually follow a hierarchical organisation scheme.

It is important to structure the files in a project source control repository for the following reasons:

Management of updates to reused IP - it is important to enable IP to be updated easily with minimal need to replay custom changes on top of reused IP. Keeping IP blocks in separate directories and even linked repositories which are effectively read-only and only referenced by the custom design files reduces the risk of introducing issues and your project can quickly import new version of IP patched by IP providers. It is also important when the system contains 3rd party IP which you are unable to distribute which is the case for the Arm IP.
Project navigation - it should be easier to locate design files the designer most often needs to interact with and for those who are new to the project to quickly understand the location of source code.
Separating significant subsystem designs from each other within the overall system design - by having subsystems (such as custom accelerators) isolated from the main system means it is easier to transfer the subsystem design into reference different systems if limitations are found in overall system performance needed to support the subsystem.
Working collaboratively - if there are multiple people working on a project, having people working in distinct repositories can reduce conflicts within files and reduce the need to merge changes which can make projects operate a lot smoother.

nanoSoC reference design

The repository hierarchy somewhat inverts the system design hierarchy. This was a SoC Labs design choice to hopefully make it easy to adopt for simple projects. The original release of nanoSoC was to support projects with custom acceleration hardware. The project structure is uses multiple repositories per project. The repository structure starts with an accelerator design repository soclabs/accelerator-project that contain entirely the projects custom IP files which interface to a system design top-level. The top-level system repository contains system wiring and verification material for the nanoSoC reusable design IP soclabs/nanosoc_tech

These can be forked to provide the top-level repository design files which can be customised for your project. It is worth reading project structure flow to get an idea of the suggested project structure.

The NanoSoC Tech IP repository contains the core SoC structural IP but not the IP provided via the Arm Academic Access Program (or from other IP licensing routes). The repository structure adopted for the nanoSoC reference design keeps all Arm IP in a linked repository.

See the latest nanoSoC reference design for details. Please read the README file for the git resources.