ENGG3380: Computer Organization and Design Lab4: Buses and Peripheral Devices

Transcription

1 ENGG3380: Computer Organization and Design Lab4: Buses and Peripheral Devices School of Engineering, University of Guelph Winter Objectives: The purpose of this lab is : Learn basic bus design techniques. Start Date: Week # Due Date: Week # Review registers and Register Transfer Level (RTL) Design. Experiment with a peripheral bus implementation. Understand how generic peripheral interface modules for input and output work. Connect external (to CPU core) IO peripherals using a peripheral bus and peripheral interface modules. 2 Review RTL Register Transfer Level (RTL) is a type of description for a synchronous digital circuit that specifies how data can move from one register to another while possibly traversing a set of control or processing blocks. A basic processor design typically consists of control unit and datapath. We already implemented a register file. It can be used in RTL principles as the source and sink of data during CPU operation, since it simultaneously has at least one read and one write port. The ALU can be considered as a processing block in RTL micro-operations. Data from one register can be read, passed through a combinational logic circuit, such as an ALU, and stored back into another register, thus forming one RTL micro-operation. While a review of RTL notation is beyond the scope of this lab, remember that the datapath provides the available logic and storage hardware for each micro-operation, and it is the control block that needs to provide the appropriate register/logic signals, such as enables, loads, and function selects, to implement the desired functionality at each clock. Similarly, on external buses, peripherals and masters provide the sources of data, and arbitrator circuits select the transfer operations that are to take place. 3 Introduction- Buses The simplest operations within a CPU require some sort of data transfer to occur in order to process information. Whether it is from a register file to an ALU, or from external memory to an IO port. There are two basic bus technologies to achieve these transfers physically - shared or dedicated. In a shared bus architecture, one common set of conductors are used among all communicating modules in a block. Typically, one module is the source of data (master) - it applies signals to the bus, and another 1

2 sinks data (slave), it reads the data from the bus and proceeds according to the content. There may be several modules capable of master operation, but only one master may be operating on the bus at any time. They all are connected to the bus using tri-state buffers, and all buffers except one must be disconnected at all times. Simultaneous operation of two masters on a shared bus, may result in a short circuit between signal drivers and may damage the chip. All slaves, however, may listen to the bus at the same time for signals to determine if they are being addressed. A slave which determines that the data is addressed to it will respond by saving the data inside its logic, or performing a control operation based on this data. Since there is only one set of conductors involved in a shared bus, all masters except the one performing the bus operation must wait their turn. Benefits of this design are seeming simplicity of construction and low resource utilization, especially on the wire routing side. In the FPGA world, the synthesis tools do not allow the designer to take the risk of a non-conflicting controller design as the chance of short circuit within a chip is always high, so internally all communication switching is facilitated using logic gate based multiplexers most of the time. Figure 1: Bus connect an ALU and RAM In the simplest dedicated bus architecture, all slaves still read the same common data line. However, each master has its own source connection to a common hub. This hub, in the most basic form, may be implemented using a multiplexer. A control circuit, typically called the bus arbitrator, decides which master is allowed access to the bus during a particular time slot as shown in Figure 2. Only one master thus is allowed to broadcast data to the slaves. More advanced implementations of the dedicated bus architecture may involve multiple broadcast channels, and allow many simultaneous transfers by using dedicated sink buses to each slave individually. The onus in this case is on the complexity of the routing or hub circuit to transfer the data from masters to slaves as addressed. The details of such designs are beyond the scope of this course. To make matters simpler, consider that your CPU will be the only master. However, let s begin by looking at the simple case in more detail. Remember that, by design, a system module can carry both a master and a slave bus interfaces. 4 Dedicated Bus Design For the purpose of your project, there are two places in the design hierarchy where buses should be considered. One is inside the CPU - the datapath bus. The other outside - memory and peripheral bus. The interconnect bus structure is usually facilitated at the higher if not highest levels of the design hierarchy. This is where all top modules can be instantiated, and the signals connected between them. The 2

3 Figure 2: Multi master/slave bus with an arbitrator following code sample illustrates this strategy: entity toplevel is port ( clk: in std_logic; sw1: in std_logic; led: out std_logic); end toplevel; architecture Str of toplevel is -- Mout is master data out, Min is master data in, addr is the address signal Bus_Mout, Bus_Min1, Bus_Min2 : std_logic_vector (X downto 0); signal Bus_Min3, Bus_addr : std_logic_vector (X downto 0); signal req : std_logic_vector(2 downto 0); signal Bus_Min : std_logic_vector (X downto 0); signal RW : std_logic; begin peripheral1: sseg port map (Bus_addr, Bus_Mout, Bus_Min1, req(0), RW, clk, led); peripheral2: switches port map (Bus_addr, Bus_Mout, Bus_Min2, req(1), RW, clk, sw1); peripheral3: memory port map (Bus_addr, Bus_Mout, Bus_Min3, req(2), RW, clk); master: cpu port map(bus_addr, Bus_Min, Bus_Mout, RW, clk); arb: Bus_Min <= Bus_Min1 when req(0)=1 else Bus_Min2 when req(1)=1 else Bus_Min3 when req(2)=1 else x00"; end Str; Here, the top level entity incorporates the necessary external IO pins, such as clock, a switch and an LED. Inside its body, the necessary bus signals are declared to facilitate the transfer of data between modules. Three peripheral entities are instantiated, where they take Bus addr, Bus Mout and clock as an input, and provide Bus Min and req lines as an output. A single master entity, CPU, is declared with Bus addr and Bus Mout as an output, and Bus Min as an input. RW is a single line that specifies if the request by the master is a read or a write, i.e. if data is to be stored in the peripheral, or sent to the master. A write enable is another name for this line. Notice that a simple arbitrator is implemented here using a dedicated bus approach directly in the body of the top level entity - depending on which peripheral responds to the master s request, the appropriate data output of that peripheral is connected to the data input of the master, the CPU. Notice that this implicit multiplexer design is prioritized - if more than one peripheral responds to the request, only one data line will be connected to the master, of the peripheral with the least significant request bit in this case. 3

4 More complicated arbitrator circuits are possible, and they would typically be implemented in their own modules. However, stating a simple arbitrator logic in the top level module in our case saves us a long entity port declaration with all data bus signals listed in a dedicated arbitrator entity module. Also, please note that the external memory to the CPU, the one that will contain the data and instructions to be executed, appears as an external bus peripheral. This is typical of memory mapped IO systems, where the memory becomes one of the peripherals mapped and accessed by a block of addresses in the global address space of the CPU. 5 Peripheral Design Thus, the connection between the master requesting and a peripheral accepting or providing data is in the address. The global address space is typically defined by the width of the registers and the datapath in your CPU architecture. For example, if a 16-bit architecture is designed, an address space with locations is available. Since it is easiest to make the CPU access the first address (x0000 ) on start up, it is most convenient to place system memory containing system software at that address. A 1KB memory placed at the start of the address space will take up the addresses x x03ff. When the CPU, or any master, accesses these address locations, it should receive the contents of main memory at those locations on the incoming data lines. This leaves the space x0400 -xffff open to map other peripherals to. A peripheral can either be for input only, output only, or both at the same time. For example, a 7-segment display controller can be an output peripheral. However, to connect any logic circuit as a peripheral on a bus requires some glue logic, in the form of slave logic circuit added on top of the 7-segment display as shown in Figure 3. Figure 3: A 7-segment display interface example. Here, a single digit 7-segment display controller is driven by a register. In this simple example, the register ports can be connected to the Din and Dout lines directly, since this is the only register contained in this peripheral. The enable register is driven by the slave logic circuit. The function of the slave logic circuit is to compare the address value presented on the bus to the base address for this peripheral. If they match, slave logic performs two tasks - it asserts an enable for the register to latch the new data value on Din onto the input of the 7-segment controller, and it asserts the request line, telling the arbitrator circuit that this peripheral is the one being accessed. While there is not likely any use in reading back the register value from this 7-segment peripheral because it s an output block, the request line is important when reading values back 4

5 from input blocks, such as from a peripheral obtaining values from a bank of switches as will be discussed in next section. The RW line is not used in the above diagram for clarity, but can otherwise be also used to control the write enable of the register depending on the design requirements. Normally, peripheral registers are overwritten only in the case when RW is asserted meaning a write cycle. Otherwise, it can be assumed that every access will be a write access. There are peripherals that also change state on a read cycle. Be very clear when designing and documenting peripheral modules of their exact functionality. 5.1 Output Peripheral - 7 segment We will be working on the external bus architecture in this lab. Since the CPU will not be present at this time, we will make due with a dummy master, which will serve in place of the CPU to make arbitration logic simpler. Let us begin an implementation with the simple single digit 7-segment control peripheral. The top level entity for this peripheral should look like this: entity per7seg is generic ( Dwidth : integer := 8; Awidth : integer := 8; BaseAddr : std_logic_vector(7 downto 0) := x10"; Digits : integer := 1); port ( Din : in std_logic_vector (Dwidth-1 downto 0); Dout : out std_logic_vector (Dwidth-1 downto 0); Addr : in std_logic_vector (Awidht-1 downto 0); RW : in std_logic; req : out std_logic Clk : in std_logic; ssegleds : out std_logic_vector(7 downto 0); SsegEN : out std_logic_vector(digits-1 downto 0)); end per7seg architecture Str of per7seg is -- register enable for the single digit display input signal en: std_logic; begin sl: sl7seg generic map (BaseAddr) port map(addr, req, en); ss: sseg register logic to connect Din with sseg inputs using en end Str; Notice that we parameterized this peripheral so that it can be connected to a bus structure of any width. 1. Complete the design of this peripheral Use a single digit 7-segment decoder to complete this design. Place an address comparator that compares the value on the Addr lines with the generic BaseAddr parameter. The idea behind this generic is to help with address space mapping. Since you will instantiate this and other peripherals at the top level of the hierarchy, it is there in one place where you will be able to select the address spaces for each of these components. You can ignore the RW input in this peripheral at this point, as we discussed. Its reference exists here to keep the entity declarations of all peripherals homogeneous. 2. Simulate this peripheral Assign a few addresses on the input, some that match the BaseAddress, and some that do not. Up to now there was no need to control Din and Dout lines, as they could be directly connected to the internal register. For a more robust design, assume we are dealing with the full 4-digit 7-segment decoder. In our 8-bit bus architecture, we would need two separate word transfers to change the display, 2 nibbles at a time. Therefore we need two registers to store the full input value for the 7-segment, and two enable lines. Since there now are two distinct values to remember, two of the consecutive addresses starting with BaseAddr need to be used to select which register to write. Additionally, the Dout line needs to be multiplexed from the two register outputs depending on which address is selected. 5

6 3. Expand this design to a 4 digit (2 address) 7-segment peripheral module and simulate Remember, you would need to use the clock to multiplex through the 4-digits in the 7-segment controller in this design. You may reduce the divider frequency in simulation to 1 clock cycle per digit to improve your work flow. Don t forget to change this value to the actual desired one when using the board with the 50MHz clock. Also, please insert RW logic in this peripheral at this stage. The registers should only update with a new value during a write cycle. 5.2 Input Peripheral - Switch Bank The same approach can be used to create an input peripheral by connecting a set of 8 switches on the board, to the Dout bus of the peripheral module. The entity declaration should look like this: entity per8sw is generic ( Dwidth : integer := 8; Awidth : integer := 16; BaseAddr : std_logic_vector(7 downto 0) := x1000"); port ( Din : in std_logic_vector (Dwidth-1 downto 0); Dout : out std_logic_vector (Dwidth-1 downto 0); Addr : in std_logic_vector (Awidht-1 downto 0); RW : in std_logic; req : out std_logic Clk : in std_logic; LED : in std_logic_vector (7 downto 0)); end per8sw architecture... Str of per8sw is begin sl:... sl8sw generic map (BaseAddr) port map(addr, req); end Str; As we are only connecting the 8 switches, this peripheral is input only. There is no need to generate an enable signal, however the request line should be generated accordingly on a BaseAddr match. A register can still be used to debounce the state of the switches at each clock without an enable, so that the data value on the bus never changes during a transfer cycle. Design and simulate the peripheral. To verify your design works, you just need to make sure the switches values are transferred onto the Dout bus, and req line lights up whenever there is an address match. For the slave logic in this peripheral, make it assert the request line whenever the addresses fall within a block range by ignoring the 4 least significant bits, i.e. it should match to all addresses within x1x where x is don t care - this covers the block of addresses x10 - x1f. A further improvement on this peripheral is to make it bidirectional by connecting the 8 switches and 8 LEDs above them in one module. The switches are read on a bus read request, and the LEDs are updated on a write cycle. This is optional. 5.3 Putting it all together Figure 4 is a high level view of what a possible bus system and design hierarchy might look like when all slaves and masters are connected together: In simple peripherals, only the BaseAddr value matters, as simple peripherals contain only one or a few words of data, and direct register enable lines are generated by slave logic. In more complex, or higher capacity peripherals, such as memory controllers, the BaseAddr value is used to match a block of addresses within a given range, and the lower bits of the address line on the bus is used to actually address into the data structure, such as a memory, directly. Note, in the diagram of Figure 4, the arbitrator circuit is omitted for clarity. 1. Connect the peripherals at top level and then simulate everything Instead of a CPU being a master, for this lab simply connect the data output of the arbitrator circuit to the Mout bus that is connected to 6

7 Figure 4: High level complete view of a proposed bus system both slaves. Select the same BaseAddr for both peripherals. This will ensure both are active at the same cycle facilitating data transfer directly between the two. In the arbitrator logic, make sure switch peripheral takes precedence over the 7-segment controller on requests from both. Make sure you simulate the design and each component in it before attempting to program the FPGA board. You will be required to demonstrate the simulations, as simulating all components of your design, bottom up, is a standard design practice. It is important that you parameterize as many hierarchy levels of your design as is useful with VHDL generics. You will be asked to justify your design decisions. 2. Demonstrate the circuit on the FPGA board Connect BTN1 to bit 4, and BTN2 to bit 0 of the bus address line, and BTN3 to RW select. Use the 50MHz single clock to drive the design. Change the switches to the first 8-bit value. Select the first 7-segment register address on the bus using BTN1 & 2. Press BTN3 to transfer the value from the switch to the 7-segment peripheral using the bus. Repeat for another 8-bit value. 6 Report When completed, you will hand in the following deliverables: 1. Title Page 2. A Block diagram of each design. 3. Simulation of each design. 4. VHDL code for each circuit designed (with comments). 5. VHDL code for simulation test-bench (with comments). 6. Report the resources used (LUTS, Flip Flops, e.t.c) for each implementation. 7