As part of the Architectural Design phase and Accelerator Design Flow, before writing any behavioural design it is important to try and specify the accelerator that you intend to make. This allows you to consider a number of factors that you will need to define in order to implement your accelerator in hardware. You may not know all of the specified parameters at the start of your project, but it is good to keep them in mind as you develop your accelerator, and commit the implementation in hardware.

Accelerator Description

A brief description of your accelerator should be included in you project. Basically this should outline what you are trying to achieve. This should include what your accelerator does, and how it works. You could also include information about the inputs and outputs. And possibly how this accelerator improves upon other hardware accelerators.

Interfaces

Here you should consider the interface between your accelerator and the rest of the hardware that wraps it. In the NanoSoC, there is a valid ready handshake between the accelerator and the wrapper. Do you need to implement any other interfaces from the accelerator, and what bit widths to you need? Another thing to consider would be a debug interface which could be used to assert and read specific values in your accelerator.

Input/Output

You need to consider the inputs and outputs and how the data flows through your accelerator. As well as what configuration inputs you would need such as reset, start, or data ready. Similarly, do you need any output flags such as output data ready or error flags? Another thing to consider is the bit depth of your data inputs and outputs. Ideally you would want to use the minimum number of bits that can still accurately describe the data you are processing. Bare in mind the more bits you use, the more time you may have to spend moving and processing data.

    Number of input ports:                           XX

    Input bit port widths:                              XX

    Number of output ports:                         XX

    Output bit widths:                                   XX

Data throughput/Buffering

You may want to include some input and output data buffers to your design. This is particularly important if you plan on running the accelerator constantly, as this allows for any pipeline issues from CPU to accelerator to be allowed for in your accelerator. If you do decide to use buffers you may want to think about how you move data from the buffer to the accelerator, you may want to wait until your input buffer is completely full before sending it to the accelerator, or you may want to process data as soon as it's available.

    Input buffers included:                                                            Yes/No

    Input port buffers (which ports):                                              XX

    Input buffer depths (assuming same width as ports):             XX

    Output buffers included:                                                         Yes/No

    Output port buffers (which ports):                                           XX

    Output buffer depths (assuming same width as ports):          XX

Data Streams

Consider the use of serial or parallel data streams. If using parallel data streams you can specify the number of parallel streams, where they will be implemented within your accelerator, and how you can handle output of your parallel data onto a single pipeline back to the CPU.

Architectural Structure

A standard approach to getting more conceptual understanding of a proposed system is to step through a method of decomposition of the overall system into sub-functions and their interactions. The specific method can come from different views on the system. One view being how data flows through the system. It uses the researcher’s perception and knowledge to conceptually decompose the system into a multi-level hierarchy of interacting systems/components. This makes it easier to verify the operation of each sub module before implementing them in your accelerator design.

• Main - My accelerator
  • Sub Module 1
    • Sub Sub module
  • Sub Module 2
  • etc...

Flow chart/Pseudo-code

System visualisation is another approach to getting more conceptual understanding of a proposed system. Describing the system via a high level diagram helps formulate how your accelerator will work. Not only does this allow you to easily explain the function and working principle of your accelerator the technique also helps spot potential issues with a current design, and identify options and potential solutions. Different views/visualisations of aspects of the system feed the design into your system Architecture.

Feature Test Scheme

Another key activity in Architectural Design phase is determining your overall verification methodology. This verification activity mirrors the design definition activity. Using the main features of the system the work involves developing verification coverage needed to verify that a design is working correctly.

This can help identify things that need addressing such as pipeline latency, the handling of gapping (where there is no input ready) and stalling (when the output isn’t ready), reading and writing to debug and control registers within your design, configuration checking and lots of design specific feature points.

• This is only a list of the features and shouldn’t go into any detail as to how you plan to actually test these features

• A V-Plan (verification plan) is a good tool to use to actually set out the exact tests at which layers of abstraction you want to test with your accelerator.

With the system definition developing decisions can be made on verification methodology. Options include the use of standards based reusable  verification environment such as Universal Verification Methodology.