Digital Systems Laboratory 4/MSc
ELEE10023/PGEE11117
Course Description
Aim: The course aims to produce students who are capable of developing hardware-software digital systems from high level functional specifications and prototyping them on to FPGA hardware using a standard hardware description language and software programming language.
Pre-requisites: Digital Systems Laboratory 3 (ELEE09018) or Digital Systems Laboratory A (PGEE10017) or equivalent in other schools and outside institutions (see below). Engineering Software 3 or equivalent is advisable but not necessary.
Co-requisites: Undergraduate students must take Digital System Design 4 (ELEE10007)
Prohibited Combinations: None
Visiting Students Pre-requisites: Digital design using Verilog, and embedded system programming.
Keywords: Embedded Digital System Design, Embedded Processor Programming, Verilog, Data path and Control Path design, Hardware-Software Co-design
Default Course Mode of Study: Lab only, 10 weekly 3-hr lab sessions
Default Delivery Period: Semester 2, starting in Week 2.
Learning Outcomes:
1. Knowledge and understanding of:
I. Data paths and Control paths and number of ways of designing them;
II. Instruction-set based control path design;
III. Control and data path integration;
IV. Capture the design of hardware-software digital systems in a standard hardware description language;
2. Intellectual
I. Ability to use and choose between different techniques for digital system design and capture;
II. Ability to evaluate implementation results (e.g. speed, area, power) and correlate them with the corresponding high level design and capture;
3. Practical
I. Ability to use a commercial digital system development tool suite to develop hardware-software digital systems and prototype them on to FPGA hardware;
Lab Content, What You Are Required To Do
You are required to develop a microprocessor-based system on FPGA with a demo application, written in software running on the microprocessor, which controls toy race-cars remotely. Students will be split into groups of two students each to tackle this problem. The final system will allow a user to simulate controlling cars remotely using a mouse, a VGA screen, and the BASYS 3 FPGA board as illustrated in the figure below.
Figure 1. Proposed System for FPGA-Based Remote Car Control
A user will be able to hover a mouse pointer over a VGA screen with the position of the mouse pointer on screen commanding the movement of the remote car as illustrated in the following figure.
Figure 2. Car movement (command) depending on mouse pointer position
The FPGA-based system will consist of a simple microprocessor, a VGA interface, and a mouse interface, in addition to other peripherals which will be detailed later on this document. An Infra-Red (IR) Transmitter interface can be added (As A Bonus) to control a toy car. Each team member will first develop one of the following peripherals, individually: VGA interface, or mouse interface. The whole group will then collaborate to develop the microprocessor at the heart of the proposed system with all necessary peripherals, as well as the complete demo application.
Assessment: The lab will be assessed during lab sessions through a number of checkpoints. The overall lab mark will be split into individual (60%) and group components (40%) for both undergraduate and postgraduate students. All students are encouraged to keep a lab book.
Verification: To support remote working, a verification environment will be provided for each interface. Details will be provided on Learn.
Assessment: The individual component will consist of two checkpoints:
1. First individual assessment in Week 5, when every team member will be assessed on the particular peripheral interface they developed i.e. mouse driver or VGA interface. Code should be uploaded to Learn prior to the timetabled laboratory in Week 5 for assessment. This will account for 25% of the overall lab mark.
2. Second individual assessment in Week 8, when every team member will demonstrate a working microprocessor + peripheral demo software application. For instance, the team member in charge of mouse driver development will present a demo software application running on the microprocessor with the mouse peripheral. Similarly, the team member in charge of VGA interface development will present a demo software application running on the microprocessor with the VGA interface peripheral. The specification of the individual demo software application will be specified later on this document. This second individual assessment will account for 35% of the overall lab mark. Note that while this assessment is individual, it requires prior design of the same microprocessor architecture by all team members. Code should be uploaded to Learn prior to the timetabled laboratory in Week 8 for assessment.
3. The final assessment will be a group assessment in Week 11, where the entire team will demonstrate the complete demo software application running on the complete microprocessor-based system on the BASYS 3 board. There will be an element of peer assessment in this final group based assignment where individuals will be asked to evaluate the individual performance of colleagues within the group. More details of this process will be given nearer the time of assessment. Again all design files should be uploaded to Learn prior to the start of the scheduled laboratory.
Details of the university semester structure can be found on the university webpages. Note that the week between weeks 5 and 6 is usually an unnumbered week, Flexible Learning Week.
The remainder of this document will present the detailed specification of each component of the proposed system. The details of the assessment components will also be presented where appropriate.
1. PS/2 Mouse Driver
The USB connector on the BASYS 3 board can accommodate a USB mouse. Internally, the signals are converted to PS/2-like signals via a microcontroller as discussed on page 7 and 8 of the BASYS 3 reference manual. Hence, all we need do is implement a driver for a PS/2 mouse as the USB connector could be seen as just a wrapper which has already been implemented.
The PIC24 drives several signals into the FPGA – two are used to implement a standard PS/2 interface for communication with a mouse or keyboard (see figure 3 below).
Figure 3: USB Host signals to PS/2 signal conversion
PS/2 devices use a two-wire serial bus (clock and data) to communicate with a host device
Communication is bidirectional and performed in packets of 11-bit words, with each word containing a start, stop and odd parity bit. The following describes the PS/2 mouse protocol in detail (NB. the PS/2 keyboard protocol can be found in the BASYS 3 user manual if you are interested in developing a keyboard interface but this is not required in this lab).
The mouse device only outputs a clock and data signal when it is moved. Otherwise, the clock and data lines remain at logic high (i.e. ‘1’). Open-Collector drivers are usually used to drive the two-wire bus between the mouse and host.
The device can send data to the host only when both data and clock lines are high. Because the host is the bus master, the device must check whether the host is sending data before driving the bus. The clock line is used for this purpose as a “clear to send” signal; if the host pulls the clock line low, the device must not send any data until the clock is released.
Communication is performed in 11-bit words, where each word consists of a ‘0’ start bit, followed by 8 bits of data (LSB first), followed by an odd parity bit (i.e. a bit that is set to ‘1’ if the number of 1’s in the 8 bits of data is even, and ‘0’ otherwise), and terminated with a ‘1’ stop bit. The odd-parity bit is used for error detection.
Data sent from a PS/2 device to a host is read on the falling edge of the clock signal, whereas data sent from a host to a PS/2 device is read on the rising edge of the clock signal. The following figure shows PS/2 signal timing for a device to host communication. Note the timing requirements which must be strictly adhered to. The clock frequency, for instance, must lie between 10 and 16.7 KHz.
Figure 3. PS/2 Device to Host Signal Timing
The following figure shows PS/2 signal timing for a host to device communication. The host brings the clock line low first, for at least 100µs. It then brings the data line low and releases the clock line. The host then waits for the PS/2 device to bring the clock line low. After that, it sets or resets the data line with the first data bit, and waits for the device to bring clock line high. It then waits for the device to bring the clock line low before it sets/rests the data line with the second data bit. This process is repeated until all eight data bits are sent as well as the odd-parity bit. Next, the host releases the data line, and waits for the device to bring the data line low, and then the clock line low. Finally, the host waits for the device to release data and clock lines.
Figure 4. Host to PS/2 Device Signal Timing
Now that we have seen the low level PS/2 protocol, let us look at the high level host-mouse communication. At power-up, a typical host-mouse communication consists of the following steps:
1) The host sends a Reset Command (consisting of byte “FF”) to the mouse,
2) The mouse responds with an Acknowledgement byte “FA”,
3) The mouse then goes through a self-test process and sends “AA” when this is passed. Then a mouse ID byte “00” is sent to the host, after which the host knows that the mouse is functioning well and ready to transmit data,
4) The host sends byte “F4” to instruct the mouse to “Start Transmitting” its position information,
5) The mouse acknowledges the “Start Transmitting” command by sending byte “FA” back to the host**,
6) After this, the mouse starts transmitting its position information in the form of 3 bytes at a sample rate that can be set by the host (the default is 100Hz)
**Note however that in the Basys3 FPGA board, probably due to the USB to PS/2 conversion, F4 instead of FA is returned, and parity test fails. Hence in state 8 of MasterStateSM module, the acknowledgement code have been changed to F4, and parity check skipped.
Thus, each data transmission from the mouse to the host after initialisation consists of 33 bits, where bits 1 (first bit), 12, and 23 are ‘0’ start bits; bits 10, 21, and 32 are Odd-Parity bits; and bits 11, 22, and 33 are ‘1’ stop bits. The three-byte data fields contain status and movement data as shown in the figure below.
Figure 5. Mouse Data Format
The mouse reports a relative coordinate system whereby a move to the right generates a positive number in the X Direction Byte field, and a move to the left generates a negative number in this field. Similarly, a move upwards generates a positive number in theY Direction Byte field, and a move downwards generates a negative number. Note that the X and Y Direction Bytes represent the magnitude of the rate of mouse movement, the larger the number the faster the mouse is moving. Bits XS andYS in the Status Byte are the sign bits, whereby a ‘1’ indicates a negative number, whereas XV and YV bits are movement overflow indicators, whereby a ‘1’ means overflow has occurred. The L and R fields in the Status Byte indicate that the left and right button have been pressed, respectively (‘1’ indicates the button has been pressed).
What you are required to do
You are required to design an FPGA PS/2 mouse interface and implement it on the BASYS 3 board. The clock line is physically connected to pin “C17” of the Artix7 FPGA chip, and the data line is physically connected to pin “B17” of the chip.
Note that in connecting these pins in the XDC file, pull up need to be set true by using the additional comment of the form. set_property PULLUP true [get_ports PS2_CLK] after the PS/2 clock and PS/2 Data ports.
The FPGA mouse interface can be built from three modules: a “Transmitter” module, a “Receiver” module and a “State Machine” module to control the FPGA-Mouse communication, as shown in Figure 6.
Figure 6. Mouse Interface: Simplified Block Diagram
The following shows Verilog code fragments for the “Receiver” module:
module MouseReceiver(
//Standard Inputs
input RESET,
input CLK,
//Mouse IO - CLK
input CLK_MOUSE_IN,
//Mouse IO - DATA
input DATA_MOUSE_IN,
//Control
input READ_ENABLE,
output [7:0] BYTE_READ,
output [1:0] BYTE_ERROR_CODE,
output BYTE_READY
);
/* Fill in the code */
endmodule
The following shows Verilog code fragments for the “Transmitter” module:
module MouseTransmitter(
//Standard Inputs
input RESET,
input CLK,
//Mouse IO - CLK
input CLK_MOUSE_IN,
output CLK_MOUSE_OUT_EN, // Allows for the control of the Clock line
//Mouse IO - DATA
input DATA_MOUSE_IN, output DATA_MOUSE_OUT,
output DATA_MOUSE_OUT_EN,
//Control
input SEND_BYTE,
input [7:0] BYTE_TO_SEND,
output BYTE_SENT
);
/* Fill in the code */
endmodule
The following shows Verilog code fragments for the Master State Machine module:
module MouseMasterSM(
input CLK,
input RESET,
//Transmitter Control
output SEND_BYTE,
output [7:0] BYTE_TO_SEND,
input BYTE_SENT,
//Receiver Control
output READ_ENABLE,
input [7:0] BYTE_READ,
input [1:0]
BYTE_ERROR_CODE, input
BYTE_READY,
//Data Registers
output [7:0] MOUSE_DX,
output [7:0] MOUSE_DY,
output [7:0] MOUSE_STATUS,
output SEND_INTERRUPT
);
/* Fill in the code */
endmodule
Finally, the above three blocks should be connected in a “Mouse Transceiver” module as suggested in the code fragments below:
Module MouseTransceiver(
//Standard Inputs
input RESET,
input CLK,
//IO - Mouse side
inout CLK_MOUSE,
inout DATA_MOUSE,
// Mouse data information
output [3:0] MouseStatus,
output [7:0] MouseX,
output [7:0] MouseY );
// X, Y Limits of Mouse Position e.g. VGA Screen with 160 x 120 resolution
parameter [7:0] MouseLimitX = 160; parameter [7:0]
MouseLimitY = 120;
/* Fill in the code */
endmodule
Note how we deal with bidirectional ports (inout’s) needed here as the Data line and the Clock line are both written to and read from. In general, to make use of an inout port “Port_Inout_Example”, you need to create an internal wire (“Port_Inout_Example_In”) with the value of the “Port_Inout_Example” port assigned to it. This can be used internally as an input to user logic when the port is in input mode. To write data to the port, we create an enable signal “Port_Inout_Example_Enable” which when set causes the output port to take the value of an internal signal “Port_Inout_Example_Out” from user logic. Otherwise, the inout port is set to high impedance. The following show Verilog code snippets to the above effect.
wire Port_Inout_Example_In;
assign Port_Inout_Example_In = Port_Inout_Example;
// Use Port_Inout_Example_In as an input to your logic
…. ….
// Internal signal Port_Inout_Example_Out can be assigned to the inout port if an enable
// signal (Port_Inout_Example_Enable) is set
assign Port_Inout_Example = ( Port_Inout_Example_Enable ? Port_Inout_Example_Out : 1’bZ);
Assessment
You will need to complete the mouse interface code based on the above, synthesise and verify your code with test benches, generate an FPGA bitstream and test on the BASYS 3 board. The team member in charge of this peripheral development will be tested in Week 5. This individual assessment will account for 25% of your overall lab mark. During the test, you will need to demonstrate a functioning mouse interface on the BASYS 3 board through plugging a USB mouse to the board, and showing the various mouse register values (Status Byte, X Direction Byte, andY Direction Byte) displayed on the LEDs and seven segment displays of the BASYS 3 board as the mouse is moved around. You will be supplied with the Verilog description of a seven segment display interface (SevenSeg). A specification of the latter can also be found in the Digital System Laboratory 3/A material. During the assessment, you will need to be able to take the assessor through your code answering any possible query about your design choices, coding style, etc. Your code will have been uploaded to Learn prior to the start of the laboratory session.