Qsys is a bus design tool integrated with Quartus Prime. It allows connections to the Intel/Altera Avalon bus and provides bridges to the HPS via AXI bus. Qsys hides details of bus width, timing, arbitration, and domain bridges to make design easier. We are going to use it as a memory-mapped, or address-mapped, system between the HPS, Altera-supplied IP, and student written Bus Masters. Qsys designs can be heirarchical. For instance, the University Program Computer bus can be opened in Qsys, and so can many of the components that make up the Computer. The VGA_subsystem is one component of the Computer that can be opened in Qsys to expose internal bus structure.
Memory-mapped transactions between masters and slaves are encapsulated in packets and transmitted on a network that carries the packets between masters and slaves. The command network transports read and write command packets from master interfaces to slave interfaces. The response network transports response packets from slave interfaces to master interfaces (1). A Qsys master can generate data, addresses and bus requests. A Qsys slave responds to bus requests aimed at its address to send or receive data. The actual bus timing is not simple, so bus acknowlegment handshaking must be done in every device connected to the bus. For prewritten modules (e.g. video subsystem or PIO port) handshaking is already done. When you write a bus-master you must do the handshaking.
Qsys signals have types and widths. This allows for error checking, explicit handling of clock signals, width conversion, and more. A single component can include any number of these interfaces and can also include multiple instances of the same interface type. Details are explained in (2).
Qsys signals are specified as:
Qsys can use a conduit to generate specification for connection directly to the FPGA fabric. When the generate command is given in Qsys, Verilog is produced, including a module which is inserted into the top-level design module. For example, the signals marked as exported in Qsys for the Video subsystem show up as connections in the generated module. A small part of the generated module shows the exported video connnections which attach to the FPGA fabric.
Each Qsys bus connection has a settable arbitration priority. Right-click anywhere on the System Contents tab, and click Show Arbitration Shares. The connection panel displays the arbitration priority of each master for each slave to which it is connected. By default, Qsys assigns arbitration priority 1 for each connected master-slave pair. The highest numeric value receives the highest priority. When multiple masters request access to a fixed priority arbitrated slave, the arbiter gives the master with the highest priority first access to the slave. See Quartus Handbook page 7-18 for more details.
There are dozens of predefined modules for Qsys. The menu in the upper-left corner shows the installed modules. Many of the modules are described in the Embedded IP Users Guide. Right-clicking on the module name in the menu will give options for inserting into the design and also for a link to documentation. Sometimes the documentation link is the datasheet, sometimes it is in the Component Folder. For instance, a parallel I/O port (PIO) which provides data from the HPS to the FPGA is an output! To get the PIO datasheet, right-click the module name and in the pop-up menu, select details>datasheet. Some other modules require that you follow the path details>open_component_folder to get the datasheet.
Some of the modules are listed here.
The Bus-master we are using is more formally known as External Bus to Avalon Bridge (EBAB). The video bus-master on the Bus-master page can be summarized with the three-part image below which is:
1. a schematic of the generic EBAB;
2. what the EBAB looks like in Qsys;
3. the interface verilog that Qsys generates for connection to your actual controller.
Your actual controller is written in Verilog and will consist of at least two states. The first state generates the bus_addr (pixel location), bus_byte_enable (one byte write), bus_write (write strobe), and bus_write_data (pixel color), then sets the state machine to the second state. The second state waits for the bus_ack, then sets the state machine back to the first state. This particular bus-master does not read data from the bus. The audio bus-master on the DSP page reads and writes data. When you put a bus-master onto the bus, you need to specify the data width and address range in a dialog box, which you get by double-clicking the module name on the Qsys interface.
The full Qsys layout for the video bus-master shows the other connections needed for operation. The clock and reset input are connected to system clock/reset outputs. The module avalon_master is connected to the memory which holds the image, because the addresses we are generating are aimed at video memory. The on-chip RAM is dual ported, with the EBAB connected to the s1 port, and the s2 port connected to video controller. The EBAB master bus is also attached to SDRAM, but I am not sure why. The display is incomplete if this is left disconnected.
(1) Qsys Interconnect
(2) Avalon Interface Specs
(3) External bus to Avalon Bridge
(4) Embedded Peripheral IP User Guide
Copyright Cornell University April 17, 2017