10. SOPC Builder Component Development Walkthrough

Transcription

1 10. SOPC Builder Component Development Walkthrough QII Introduction This chapter describes the parts o a custom SOPC Builder component and guides you through the process o creating an example custom component, integrating it into a system, and testing it in hardware. This chapter is divided into the ollowing sections: Component Development Flow on page Design Example: Checksum Hardware Accelerator on page This design example shows you how to develop a component with both Avalon Memory-Mapped (Avalon-MM) master and slaves. Sharing Components on page This section shows you how to use components in other systems, or share them with other designers..sopcino Files on page SOPC Builder Components and the Component Editor An SOPC Builder component is usually composed o the ollowing our types o iles: HDL iles deine the component s unctionality as hardware. Hardware Component Description File (_hw.tcl) describes the SOPC Builder related characteristics, such as interace behaviors. This ile is created by the component editor. C-language iles deine the component register map and driver sotware to allow programs to control the component. Sotware Component Description File (_sw.tcl) ile used by the sotware build tools to use and compile the component driver code. The component editor guides you through the creation o your component. You can then instantiate the component in an SOPC Builder system and make connections in the same manner as other SOPC Builder components. You can also share your component with other designers. For inormation about creating the _sw.tcl ile, see the Developing Device Drivers or the Hardware Abstraction Layer chapter in the Nios II Sotware Developer s Handbook. Prerequisites This chapter assumes that you are amiliar with the ollowing: Building systems with SOPC Builder. For details, reer to the Introduction to SOPC Builder chapter in volume 4 o the Quartus II Handbook. SOPC Builder components. For details, reer to the SOPC Builder Components chapter in volume 4 o the Quartus II Handbook. Basic concepts o the Avalon-MM interace. March 2009 Altera Corporation Quartus II Handbook Version 9.0 Volume 4: SOPC Builder

2 10 2 Chapter 10: SOPC Builder Component Development Walkthrough Component Development Flow Hardware and Sotware Requirements To use the design example in this chapter, in addition to the current version o the Quartus II sotware and Nios II Embedded Design Suite, you must have the ollowing: Design iles or the example design A hyperlink to the design iles appears next to the chapter, SOPC Builder Component Development Walkthrough, on the SOPC Builder literature page. Nios development board and an Altera USB-Blaster TM download cable You can use either o the ollowing Nios development boards: Stratix II Edition, RoHS compliant version Cyclone II Edition I you do not have a development board, you can ollow the hardware development steps. You cannot download the complete system without a working board, but you can simulate the system. You can download the Quartus II Web Edition sotware and the Nios II EDS, Evaluation Edition or ree rom the Altera Download Center at Component Development Flow Typical Design Steps This section provides an overview o the development process or SOPC Builder components. A typical development sequence or an SOPC Builder component includes the ollowing items: 1. Speciication and deinition. a. Deine the unctionality o the component. b. Determine component interaces, such as Avalon Memory-Mapped (Avalon-MM), Avalon Streaming (Avalon-ST), interrupt, or other interaces. c. Determine the component clocking requirements; what interaces are synchronous to what clock inputs. d. I you want a microprocessor to control the component, determine the interace to sotware, such as the register map. 2. Implement the component in VHDL or Verilog HDL. Quartus II Handbook Version 9.0 Volume 4: SOPC Builder March 2009 Altera Corporation

3 Chapter 10: SOPC Builder Component Development Walkthrough 10 3 Component Development Flow 3. Import the component into SOPC Builder. a. Use the component editor to create a _hw.tcl ile that describes the component. b. Instantiate the component into an SOPC Builder system. When importing an HDL ile using the component editor, any parameter deinitions that are dependent upon other deined parameters cause an error. Example 10 1 illustrates the declaration o a DEPTH parameter which is legal Verilog HDL syntax in the Quartus II sotware, but causes an error in the component editor syntax checker. Example DEPTH Parameter parameter WIDTH = 32; parameter DEPTH = ((WIDTH == 32)? 8 : 16); To avoid this error, use a localparam or the dependent parameter instead, as shown in Example Example localparam Parameter parameter WIDTH = 32; localparam DEPTH = ((WIDTH == 32)?8:16); 4. Develop the sotware driver, which can occur in parallel with the hardware implementation. Create the component s driver, including a C header ile that deines the hardware-level register map or sotware. For urther details, see the Nios II Sotware Developer's Handbook. Hardware Design 5. Perorm in-system testing, such as the ollowing: a. Test register-level accesses to the component in hardware or simulation using a microprocessor, such as the Nios II processor. b. Perormance benchmarking. As with any logic design process, the development o SOPC Builder component hardware begins ater the speciication phase. Creating the HDL design is oten an iterative process, as you write and veriy the HDL logic against the speciication. The architecture o a typical component consists o the ollowing unctional blocks: Task logic Implements the component's undamental unction. The task logic is design dependent. Interace logic Provides a standard way o providing data to or getting data rom the components and o controlling the unctioning o the components. For urther details, reer to the Avalon Interace Speciications. Figure 10 1 shows the top-level blocks o a checksum component, which includes both Avalon-MM master and slaves. March 2009 Altera Corporation Quartus II Handbook Version 9.0 Volume 4: SOPC Builder

4 10 4 Chapter 10: SOPC Builder Component Development Walkthrough Design Example: Checksum Hardware Accelerator The work low or developing SOPC Builder hardware, including how to decide upon and implement the register map, is described in the Using the Nios II Sotware Build Tools chapter in the Nios II Sotware Developer s Handbook. Also, guidelines or developing device drivers is described in the Developing Device Drivers or the Hardware Abstraction Layer chapter o the Nios II Sotware Developer s Handbook. Design Example: Checksum Hardware Accelerator Altera has provided a checksum hardware accelerator design example to demonstrate the steps to create a component and instantiate it in a system. This design example is available or download rom the Altera literature website. Included in the compressed download ile is a readme.pd that describes how to create and compile the hardware design, and describes how to use the checksum hardware accelerator in your design. You can use the checksum algorithm in network applications where data integrity must be inspected by the receiving device. The checksum algorithm accumulates data with end-round-carry summation, which means that the carry bit rom the accumulator is added to the least signiicant bit o the next input. Ater the data is accumulated, you can use the result to veriy the data integrity o the data buer. Because the checksum algorithm operates over a data buer, you can implement it more eiciently with a pipelined read master. A pipelined read master continuously posts read transactions minimizing the eects o the memory read latency. The checksum accelerator can read data and calculate the checksum result every clock cycle, which you cannot do with a general purpose processor. The checksum hardware accelerator requires inormation rom a host processor such as the buer base address, buer length, and various control signals. As a result, the hardware accelerator exposes an Avalon-MM slave interace so that a host processor can control the read master operation. The host processor also accesses the checksum result rom the slave interace. Each piece o inormation sent or read by the host processor is accessed separately in the register ile implemented with the slave interace. For example, the status and control signals are implemented as separate registers because they contain inormation used or dierent purposes and have dierent access capabilities. Hardware accelerators can operate in parallel with a host processor; consequently, adding an interrupt sender interace to the hardware accelerator increases system perormance. While the accelerator is operating on a buer, the host processor can perorm other tasks such as preparing another buer or transmission. The interrupt is asserted ater the buer checksum is calculated. The host processor can be interrupted by the hardware accelerator to notiy it that a checksum result has been calculated. The host processor can then read the checksum value and clear the interrupt by writing to the status register via the accelerator slave interace. Quartus II Handbook Version 9.0 Volume 4: SOPC Builder March 2009 Altera Corporation

5 Chapter 10: SOPC Builder Component Development Walkthrough 10 5 Design Example: Checksum Hardware Accelerator Figure Checksum Component with Avalon-MM Master and Slaves clk reset Clock Input Interace clk reset master_address[31..0] master_readdata[31..0] Checksum Transorm transorm_readdata[31..0] transorm_read Avalon-MM Master Interace master_read master_byteenable[3..0] transorm_data_available master_waitrequest transorm_byte_lanes master_readdatavalid go_strobe read_address[31..0] read_length[31..0] slave_address[2..0] slave_writedata[31..0] checksum_result[15..0] checksum_invert checksum_clear Avalon-MM Slave Interace slave_write slave_readdata[31..0] slave_read slave_byteenable[3..0] control_irq Checksum Accelerator Interrupt Slave Interace irq Sotware Design I you want a microprocessor to control your component, you must provide sotware iles that deine the sotware view o the component. At a minimum, you must deine the register map or each Avalon-MM slave that is accessible to a processor. Typically, the header ile declares macros to read and write each register in the component, relative to a symbolic base address assigned to the component. Table 10 1 shows the register map o the checksum component or use by the Nios II processor. March 2009 Altera Corporation Quartus II Handbook Version 9.0 Volume 4: SOPC Builder

6 10 6 Chapter 10: SOPC Builder Component Development Walkthrough Design Example: Checksum Hardware Accelerator Table Avalon-MM Slave Port Register Map (Control) Oset Name Rd/Wr/clr Bits Status Rd/Wclr Busy Done 4 Read Rd/Wr Read Address (32-bit word aligned) Address (1) 8 N/A Reserved () 12 Length Rd/Wr Length in Bytes (must be a multiple o 4 or word aligned) (Bytes) 16 N/A Reserved () 20 N/A Reserved () 24 Control Rd/Wr RC ON I_E N GO Inv Clr 28 Checksum Results Rd 16-Bit Checksum Result (upper 16 bits are zeros) Note to Table 10 1: (1) Wr=Writable; Rd=Readable; Wclr=Write 1 to clear 1 In the example checksum project, you can view an example o a sotware driver in the directory <projectdir>/ip/checksum_accelerator, which is the top level older o the hardware and sotware or the custom checksum block. Sotware drivers abstract hardware details o the component so that sotware can access the component at a high level. The driver unctions provide the sotware an API to access the hardware. The sotware requirements vary according to the needs o the component. The most common types o routines initialize the hardware, read data, and write data. When developing sotware drivers, you should review the sotware iles provided or other ready-made components. The IP installer provides many components you can use as reerence. You can also view the <Nios II EDS install path>/components/ directory or examples. For details about writing drivers or the Nios II hardware abstraction layer (HAL), reer to the Developing Device Drivers or the Hardware Abstraction Layer chapter o the Nios II Sotware Developer s Handbook. Veriying the Component You can veriy the component in incremental stages, as you complete more o the design. You should irst veriy the hardware logic as a unit (which might consist o multiple smaller stages o veriication) and later veriy the component in a system. System Console The system console is an interactive Tcl console available rom within SOPC Builder that provides you with read and write access to the debugging capabilities that are available in your FPGA logic. You can use the system console to control and query the state o the Nios II processor, issue Avalon transactions, board bring-up, and access either JTAG UARTs or system level debug (SLD) nodes. Quartus II Handbook Version 9.0 Volume 4: SOPC Builder March 2009 Altera Corporation

7 Chapter 10: SOPC Builder Component Development Walkthrough 10 7 Sharing Components For urther details, reer to the System Console User Guide. System-Level Veriication Ater you package a _hw.tcl ile with the component editor, you can instantiate the component in a system and veriy the unctionality o the overall SOPC Builder system. SOPC Builder provides support or system-level veriication or HDL simulators such as ModelSim. SOPC Builder automatically produces a test bench or system-level veriication. 1 You can include a Nios II processor in your system to enhance simulation capabilities during the veriication phase. Even i your component has no relationship to the Nios II processor, the auto-generated ModelSim simulation environment provides an easy-to-use starting point. Sharing Components.sopcino Files When you create a component, component editor saves the _hw.tcl ile in the same directory as the top-level HDL ile. Where appropriate, iles reerenced by the _hw.tcl ile are speciied relative to the _hw.tcl ile itsel, so the iles can easily be moved and copied. To share a component, include it in your IP library. For more inormation about including components in an IP library reer to Finding Components in SOPC Builder in Chapter 4: SOPC Builder Components in volume 4 o the Quartus II Handbook. Every time SOPC Builder generates a system, a <mysystem>.sopcino ile is also generated, which contains the ollowing inormation: SOPC Builder project, including: Name and tool version HDL language Each module instantiated in the system, including: Name and version Where interace inormation was ound on the disk, such as signal names and types, interace properties, and clock domain mapping Parameter names and values Each connection, including: Component and interace connections Base address, Avalon-MM interaces, IRQ number interaces Memory map as seen by each master in the system 1 The.sopcino ile is a report ile only, and cannot be edited with SOPC Builder. March 2009 Altera Corporation Quartus II Handbook Version 9.0 Volume 4: SOPC Builder

8 10 8 Chapter 10: SOPC Builder Component Development Walkthrough Reerenced Documents Reerenced Documents This chapter reerences the ollowing documents: Developing Device Drivers or the Hardware Abstraction Layer chapter o the Nios II Sotware Developer s Handbook Introduction to SOPC Builder chapter in volume 4 o the Quartus II Handbook SOPC Builder Components chapter in volume 4 o the Quartus II Handbook System Console User Guide Using the Nios II Sotware Build Tools chapter in the Nios II Sotware Developer s Handbook Quartus II Handbook Version 9.0 Volume 4: SOPC Builder March 2009 Altera Corporation

9 Chapter 10: SOPC Builder Component Development Walkthrough 10 9 Document Revision History Document Revision History Table Document Revision History Table 10 2 shows the revision history or this chapter. Date and Document Version Changes Made Summary o Changes March 2009, v9.0.0 Corrected direction o transorm_data_available and transorm_byte_lanes signals in Figure 10 1 on page November 2008, v8.1.0 Added reerence to new search path or IP chapter 4 o this volume. Correction direction o signals in Figure Changed page size to 8.5 x 11 inches. May 2008, v8.0.0 Chapter renumbered rom 9 to 10. Removed discussion o the Checksum Design example, which will now be in a readme.pd ile and zipped with the rest o the design iles. Deleted reerences to Avalon Memory-Mapped and Streaming Interace Speciications and changed to Avalon Interace Speciications. New Figure 9-1 and Table 9-1. New section on.sopcino ile. One correction. One correction and one change to relect changes in underlying sotware. Deleted example procedure. For previous versions o the Quartus II Handbook, reer to the Quartus II Handbook Archive. March 2009 Altera Corporation Quartus II Handbook Version 9.0 Volume 4: SOPC Builder

10 10 10 Chapter 10: SOPC Builder Component Development Walkthrough Document Revision History Quartus II Handbook Version 9.0 Volume 4: SOPC Builder March 2009 Altera Corporation