Specifying your IP

As part of the Architectural Design phase and IP Design Flow, before designing your IP it is important to try and specify the IP 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 IP 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 IP, and commit the implementation in hardware.

The specification process for both digital IP and analog/mixed signal IP follow similar flows but the details of each step are different. Please expand the corresponding sections below to read further on the specification of your IP.

Digital IP/Accelerator Specification

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...

IP Description

A brief description of IP blocks should be included in the project. Basically this should outline what the system is looking to achieve. This should include what each IP block does, and how it works. Include information about the inputs and outputs. State how any custom IP improves upon other hardware reusable IP.

Interfaces

Consider the interfaces between IP blocks and the rest of the system. For example, in the NanoSoC reference SoC, there is a valid ready handshake between custom accelerator IP and the wrapper. The need to implement any other interfaces from custom IP, and what bit widths are needed? The debug interface which could be used to assert and read specific values in any custom IP.

Input/Output

Consider the inputs and outputs and how the data flows through the custom IP such as an accelerator. What configuration inputs are needed such as reset, start, or data ready. Any output flags such as output data ready or error flags? The bit depth of any data inputs and outputs. Ideally use the minimum number of bits that can still accurately describe the data being processed. Bare in mind the more bits used, the more time is spent moving and processing data.

    Number of input ports:                           XX

    Input port bit widths:                               XX

    Number of output ports:                         XX

    Output port bit widths:                            XX

Data throughput/Buffering

Include any input and output data buffers to your design. This is particularly important when planning to run the accelerator constantly, as this allows for any pipeline issues from CPU to accelerator. Use of buffers requires consideration of moving data from the buffer to the accelerator, for example waiting until the input buffer is completely full before sending it to the accelerator, or processing 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 specify the number of parallel streams, where they will be implemented within the accelerator, and how to handle output of parallel data into a single pipeline back to the CPU.

Flow chart/Pseudo-code

System visualisation is an approach to getting more conceptual understanding of a proposed system. Describing the system via a high level diagram helps formulate how the custom hardware will work. Not only does it allow clear and sunle explaination of the function and working principle of custom hardware,  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 the complete system Architecture.

Feature Test Scheme

Another key activity in Architectural Design phase is determining the 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 a 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 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 to be tested within the custom hardware.

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.

Analog/Mixed Signal IP Specification

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. For analog IP this may be breaking down the design into blocks and sub-blocks. This approach helps with the reuse of certain commonly used components (e.g. opamps)

IP Description

A brief description of system level IP blocks should be included in you project. Basically this should outline what the system is looking to achieve. This should include what each IP block does, and how it works in coordination with other blocks,  include information about the connected inputs and outputs. State clearly how any custom IP improves upon other hardware re-usable IP.

Interfaces

Here you should consider the interface between an IP block and the rest of the system that connects to it. For example is there a digital/mixed signal interface or is it fully analog. Are there any data/clocking speeds that need to be matched at these interfaces? 

Input/Output

Consider the inputs and outputs and how the signal flows through the IP of the system.  State any system configuration inputs, such as reset, start, or data ready. Similarly,  any output flags such as output data ready? Another things to consider are the specifications for the input/output, for instance voltage range, current/drive strength, bandwidth etc.

Verification Scheme

A key activity in the 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 bandwidth, gain margin, phase margin, conversion speed etc. Essentially this can be a list of specifications for your IP that can then be use to benchmark against the model of the system design. It can also be useful to do this for each sub-block to confirm each sub-block is working as expected before connecting them together