ECE 695 Summer 06 28 Jun 2006

1
ECE 695 Summer 0628 Jun 2006

• Adding Custom Hardware to NIOS II SOPC Builder

2
Background

• Associated Quartus Project illustrates the
  hardware and software approach
• These Charts outline the process.
• References
• Altera Avalon Interface Specification
• http//www.altera.com/literature/manual/mnl_avalon
  _spec.pdf
• Quartus II Handbook-Vol 4
• http//www.altera.com/literature/quartus2/lit-qts-
  sopc.jsp
• NIOS II Software Developers Handbook
• http//www.altera.com/literature/hb/nios2/n2sw_nii
  5v2.pdf

3
Module Generated by SOPC Builder
4
User Defined SOPC Component Design Flow

• 1. Define the interface to the user-defined
  component.
• 2. If the component logic resides on-chip, write
  HDL files describing the component in either
  Verilog HDL or VHDL.
• 3. Use the SOPC Builder component editor wizard
  to specify the interface and optionally package
  your HDL files into an SOPC Builder component.
• 4. Instantiate your component in the same manner
  as other SOPC Builder Ready components.

5
SOPC Builder Component Requirements

• Hardware files HDL modules that describe the
  component Hardware
• Software files A C-language header file that
  defines the component register map, and driver
  software that allows programs to control the
  component
• Component description file (class.ptf) This file
  defines the structure of the component, and
  provides SOPC Builder the information it needs to
  integrate the component into a system. The
  component editor generates this file
  automatically based on the hardware software
  files you provide, and the parameters you specify
  in the component editor GUI.

6
Typical Component Design Steps

• 1. Specify the hardware functionality.
• 2. If a microprocessor will be used to control
  the component, specify
• the application program interface (API) to access
  and control the
• hardware.
• 3. Based on the hardware and software
  requirements, define an
• Avalon interface that provides
• a. Appropriate control mechanisms
• b. Adequate throughput performance
• 4. Write HDL that describes the hardware in
  either Verilog or VHDL.
• 5. Test the component hardware alone to verify
  correct operation.
• 6. Write a C header file that defines the
  hardware-level register map
• for software.
• 7. Use the component editor to package the
  initial hardware and
• software files into a component.

7
Typical Component Design Steps (CONT)

• 8. Instantiate the component into a simple SOPC
  Builder system module.
• 9. Test register-level accesses to the component
  using a microprocessor, such as the Nios II
  processor. You can perform verification in
  hardware, or on an HDL simulator such as
  ModelSim.
• 10. If a microprocessor will be used to control
  the component, write driver software.
• 11. Iteratively improve the component design,
  based on in-system behavior of the component
• a. Make hardware improvements and adjustments.
• b. Make software improvements and adjustments.
• c. Incorporate hardware and software changes into
  the component using the component editor.
• 12. Build a complete SOPC Builder system
  incorporating one or more instances of the
  component.
• 13. Perform system-level verification. Make
  further iterative improvements, if necessary.
• 14. Finalize the component and distribute it for
  design reuse.

8
Typical Component Architecture

• Task Logic - The task logic implements the
  component's fundamental function. The task logic
  is design dependent.
• Register File - The register file provides a path
  for communicating
• signals from inside the task logic to the outside
  world, and vice versa. The register file maps
  internal nodes to addressable offsets that can be
  read or written by the Avalon interface.
• Avalon Interface - The Avalon interface provides
  a standard Avalon front-end to the register file.
  The interface uses any Avalon signal types
  necessary to access the register file and support
  the transfer types required by the task logic.
  The following factors affect the Avalon
  interface
• How wide is the data to be transferred?
• What is the throughput requirement for the data
  transfers?
• Is this interface primarily for control or for
  data? That is, do transfers tend to be sporadic,
  or come in continuous bursts?
• Is the hardware relatively fast or slow compared
  to other components that will be in a system?

9
Typical Component Architecture
10
Example Design-Integer Hardware Multiply

• Add an external hardware multiplier to the small
  NIOS II Processor system (no multiply hardware)
• Multiply two 16-bit, signed integers and return a
  32-bit signed integer
• Invoke with a C function
• alt_32 mul16(alt_16 A, alt_16 B)
• Function outputs A and B to hardware and the
  product is returned
• Include a status register and a function to read
  the status

11
Hardware Multiplier Architecture
12
Design and Test

• Write Verilog code for each module see example
  code in the zip file
• Compile and simulate in Quartus
• When test are complete, import as a component
• Use the component editor (see QII V4 pg 5-1 and
  following)
• Component editor outputs the following
• class.ptf identifies component, defines
  interconnections and parameters
• cb_generator.pl script used by SOPC builder to
  generate instances of the component hardware
• hdl directory contains the hdl files defining
  the component logic
• Software files e.g. drivers or header files
• File structure should be a directory
• Mul16
• class.ptf
• cb_generator.ptf
• hdl directory
• Software directory
• Copy to appropriated component directory under
  SOPC builder to use for any system.

13
Software Driver Flow

• Drivers
• 1. Create the device header file that describes
  the registers. This header file may be the only
  interface required.
• 2. Implement the driver functionality.
• 3. Test from main().
• 4. Proceed to the final integration of the driver
  into the HAL environment.
• 5. Integrate the device driver into the HAL
  framework.

14
How to get started

• Create a test system using SOPC builder
• Limit other peripherals to simplify (I used only
  SRAM and the JTAG UART)
• Generate the processor and compile the hardware
• Print the system.h file for reference while
  building the driver
• Create the reg.h file for your peripheral
• Name is arbitrary mine is altera_avalon_mul16_re
  gs.h
• Create header file for the routines needed to
  access your hardware mine is altera_avalon_mul16
  _routines.h
• Create file containing routines to access your
  hardware mine is altera_avalon_mul16_routines.c

15
Testing

• Firsttest your test processor by building the
  vanilla Hello World program
• Second Modify hello world to exercise your new
  hardware. Be sure to include the software driver
  files in the project.