System-on-Chip (SoC)

Overview

This term project will give you experience implementing a small-scale SoC (system-on-chip) using an embedded processor, ROM, UART, and custom hardware.

OPTIONAL: You may propose your own project, provided that it meets or exceeds the complexity of the project detailed on this page. Proposals will be due in class by Tuesday of Week 7.

Software

Equipment

Documents

System Concept

Hardware Device Specification

1. The hardware device is the counter specified in Lab C (possibly with minor modifications).
2. The 16-bit counter output will be displayed on the DIO4 (or DIO1) board.
3. The eight discrete LEDs will display the status of the counter inputs (pause, count direction, increment/decrement value, and rate).

NOTE: The intent here is to recycle as much as possible of the Lab C work without making extensive changes.

User Interface Specification

1. A “welcome message” will be displayed upon initial download to FPGA or asserting the master reset pushbutton
2. A new prompt will be displayed at the conclusion of command execution and after the initial welcome message
3. The prompt will be placed at the far left side of the screen and on a new line (this way previous commands and results will remain visible)
4. The command set is defined in Table 1.
5. The command must be executed immediately after the required number of characters has been entered, but not before then. For example, if the multi-character command to load the counter is typed, the counter should only change value after all four hexadecimal characters have been typed.
6. All characters typed by the user must be echoed back to the terminal.
7. UART baud rate is 38,400 bits/second
8. “A” project only: Cause the terminal emulator to beep once (see ASCII code for “bell”) whenever the counter reaches zero, i.e., only the transition from a non-zero count to a zero count should cause the beep. The beep must sound immediately, even if the user is in the middle of typing a multi-character command.

Table 1: Command Set Specification 

 NOTE: Commands must be interpreted exactly as shown in Table 1. Specifically, make no attempt to wait for the “Enter” key to conclude a command entry or to accommodate any other form of “white space” (spaces and tabs) in the commands.

Project Grading

A cumulative approach to implementing the user-interface specifications will give you flexibility in how much time you wish to invest in the project and in how much challenge you seek:

Requirements

1. Your design must conform to ALL of the Synthesis Design Rules, including the naming conventions at the bottom of the document (use at least the minimal format of r_, w_, p_, etc.).

Deliverables

1. Register-level block diagram of the complete hardware system (including processor and program ROM)
2. High-level flow chart of PicoBlaze assembly program
3. Hardcopy of PicoBlaze assembly language program
4. Hardcopy of all Verilog descriptions that you create
5. Brief memo that describes:
    

   ·        A point in your design process where you consciously evaluated whether a particular specification was easier to implement in hardware or in software (the “hardware/software co-design” issue),

   ·        The two possible ways you could implement the specification,

   ·        What you decided to implement, and

   ·        How well it turned out

6. Demonstration of your design to instructor and classmates during lab of Week 10

Tips and Info

General:

1. Our version of ModelSim does not support mixed-HDL designs. Our version of NC-Sim DOES support mixed-HDL simulations, but you will probably need to do something  special with library setups to make this work (I have not attempted it yet).

2. The program ROM should be generated directly from the pBlazeIDE assembler. See the documentation in ROM_template.zip.

Software:

1. Refer to the pBlazeIDE documentation page (http://www.mediatronix.com/pBlazeIDE.htm, scroll to the bottom); take note of the "Directives," "Opcodes," and "Simulated I/O" links.

2. Draft and refine a flowchart for your assembly language program before you do coding.

3. Make subroutines for common activities, e.g., "getchar" and "putchar" for interacting with the UART. This really helps to simply the translation of the high-level flowchart into assembly language.

4. See page 43 of the PicoBlaze app note (http://www.xilinx.com/bvdocs/appnotes/xapp213.pdf) for techniques to compare two values (the instruction set does not include an explicit "compare" operation)

5. Thoroughly simulate and verify your assembly language program before getting too involved in the implementation phase.

Hardware:

1. Draft and refine a register-level block diagram for your hardware before you do Verilog entry.

2. You can save a considerable amount of typing if you collect all (or most) writable interface registers into a single 'always' block and use a 'case' statement for address decoding.

3. Creating external "readable registers" and "writable registers" for the PicoBlaze does  not always require that you make a new physical register. For example, you need make the UART_Rx (receiver module) output available to the PicoBlaze as a "readable" device. Since the UART_Rx module already has the value stored in a FIFO, there is no reason to insert an additional register between the UART_Rx module and the MUX leading to the PicoBlaze data input port. Not only is the register a waste of resources, you can introduce unexpected timing problems into your design. As another example, the UART_Tx (transmitter module) needs to look like a "writable" device. The UART_Tx module effectively looks like a "data register" with its 8-bit data input and "write_buffer" serving as the clock enable. Again, there is no need to insert an additional register between the two.