In Agile methodology each version should deliver a usable increment of capability to real users. This project aims to access the user needs and develop the next increment of capability for nanoSoC. This version will require some refactoring and  will look to maintain backwards compatibility where possible 

Background

nanoSoC is the entry level reference design within SoC Labs. The design provides a simple microcontroller SoC to support the development and evaluation of research components or subsystems in small academic projects that can be undertaken by PhD or other students. 

Version 1 of nanoSoC was architected to provide an initial capability to develop small custom acceleration hardware for Artificial Intelligence / Machine Learning applications. 

Version 2 of nanoSoC added improvements in Host Communications ("HOSTIO") interconnect.

A separate reference project was started to add a mixed signal subsystem.

Rationale

The various projects that have utilised NanoSoC have highlighted some shortcomings in the reference design but also in areas such as the reference flows used to take the design to silicon and the structure within the actual code repository.

Currently identified activities for this release are: 

• Architecturally, there is a need to expand the number and variety of subsystems supported by nanoSoC
• Improved ability to undertake Architectural/Behavioural Design exploration while still simplifying the transition from FPGA to full ASIC design flows. For example; an NanoSoC component that can be drag and dropped into FPGA diagram environments and quickly configured
• Refactor the code repository to ease uptake by new users and aid future expansion
• Streamline flows. To improve uptake and understanding and reduce the learning curve for people to adopt NanoSoC, some of the flow wrappers should be removed/lightened

Adoptability

The adoptability of the next generation is an important focus. New expansion subsystems will require tuning of the core SoC parameters. Having a core reference design that is easier to configure and iterate with will have great advantages for users who want to drop nanoSoC into a design space and get off the ground quickly.

A number of features are being investigated to achieve this objective such as::

• Reconceptualising nanoSoC as a system component rather than a wrapper. Exposing the bus interfaces and external connections so they can be plugged in to other components from a custom wrappered top-level using external bus interconnects. Greater flexibility of the sizing of components will be very helpful
• Being able to support tools such as Xilinx Vivado and importing the nanoSoC as  packaged IP with a selection of DMA controllers as a drop in component with an AXI wrapper around the outside for a much faster integration time for development and experimentation of SoC designs
  • Explore Vitis customization of Board Support Packages to support debug without needing to leave the Xilinx toolchain, especially when doing architectural exploration

Refactored Codebase

Like many Agile methodology activities, reaching V3 is a good time to refactor based on lessons learned to provide a better structured codebase. 

Version 3  will be placed on a fork of the existing nanoSoC repository to prevent conflicts with the users of the existing releases with the aim of eventually superseding the current constrained nanoSoC structure. The aim is to allow a deeper separation between components within the reference design, their verification, simplifying integration and parameterisation while also easing the adoption by users new to SoC design.

Initial objectives include:

• Discrete releases of codebase to allow for iterative feature improvements where users can opt in to rolling forward or remain on their current version
• Clearer separation of components and flows and a reconsidered file list strategy where filelists are recursively included rather than being hard-coded at the top-level
• Reconsidered firmware compilation flow. Firmware compilation will be in a separate location to draw a clear distinction between hardware and software sections of the IP
• Removal of tick defines from RTL and test benches will allow for a configurable SoC design using tick defines

Verification focus

This iteration of nanoSoC will have a focus around stability and structure using a component-based verification technique as well as system validation which will occur in simulation and using FPGA platforms to test designs.

• A greater emphasis will be placed on CI/CD flows that are able to test a number of different configurations of designs using design changes and modifications
• Testing using new tools to find improvements and bugs that may be introduced in newer tool versions
• Allow for testing with a range of tools

Development of Verification Strategy

To improve the usability and confidence of the platform, a verification strategy needs to be in place. This should allow: 

• intuitive ways of writing test codes that are portable across different implementations (RTL, FPGA Gate-level, ASIC Gate-level, FPGA Implementation, ASIC Implementation)
• a quick and automated approach to developing test programs that are able to deliver code coverage metrics 

Producing a Specification

This project will start by evaluating what is currently available against the criteria that have been established above. It will derive a detailed feature specification setting out a clear set of plans and tasks that need to be accomplished.

It is important to set out targets for the work and produce research into what needs to be done and the effort required.

Prerequisites for analysis

• Existing repository is in a stable state
• Evaluate existing flows to see how useful they are and see the shortcomings of the existing flows to see what isn't delivered with these.

Flow Streamlining Strategy

To improve uptake and understanding and reduce the learning curve for people to adopt NanoSoC, some of the flow wrappers should be removed/lightened. 

Prerequisites for analysis

• Existing repository is in a stable state where flows can be evaluated
• Get external feedback on uptake of flows. Group flows togethers

Repository Separation Strategy

The repository should be reviewed and documented to work out what flows and code is present within the repository. This should be represented and then an evaluation of what is benefited by moving resources around. 

Prerequisites for analysis

• Evaluation of code, flows and resources in the repositories and where they lie

Producing the specification

The specification will be produced off the back of the findings from each of the research strategies to ensure the focus is placed well on each section and to know where to focus the effort.