Exercise #4: Packages and Busses

Course Home

Exercise Home

General Instruction

Before we start

Important part of this lab is to first read through the General instructions which should consist of all important notes about lab class, how to access the programs at home, coding conventions, defense of the lab and report requirements. Attending the lab means that you have agreed to the letter of commitment (so please read it carefully).

Important Note:

Please make sure you read Jiri Gaisler's "A structured VHDL design method". This document would be used as our coding reference throughout the labs.

Format of Exercises

Before coming into the exercise sessions, students are required to understand prerequisites for each session.

When the students arrive in the laboratory, they must have ,

Tools user guides and manuals

You can find the user guides and manuals for these labs here:

Pre-Requisite

Students are assumed to know what are packages and functions. They should have gone through the lectures material on packages, types and resolution function. Students are suggested to look at different IEEE 1164 packages specially Std_logic_1164 and study how resolved function works. It can be seen within modelsim. There will not be any test this week.

Design and Test your own Resolution Function

Introduction

In this lab you will learn how to make your own package, How function and operations are resolved and you will also learn to design a bus in vhdl. You are recommended to use modelsim to perform the following operations.

Tasks

  1. Open ModelSim and open the 1164 standard library. Library → IEEE → std_logic_vector → right click → edit (But do not Edit it)
  2. This package defines the standard representation of std_logic/std_logic vector e.g. the possible values of a standard logic (multi-valued logic) and how it is resolved. The representation of logic is given by following code.

    Here std_ulogic is defines a Type based on all possible values.

    Here std_logic is defined as a subtype of std_ulogic which uses a resolution function called resolve.

    The resolution function resolves conflict within multiple levels of which drive a particularly std_logic. To do so they require a resolution table.

    This resolution table is used within the body of the resolved function to resolve these conflicts.

  3. Make a package for your own multi valued logic. In the IEEE library you can find the definitions for the IEEE standard 1164 which uses nine-valued-logic. Use those as a template and define your own enumerated data type ttu that can handle open collector logic with the following interpretation:
    1. 'X', -- Forcing Unknown,
    2. '0', -- Forcing 0,
    3. '1', -- Forcing 1,
    4. 'Z', -- High Impedance,
    5. 'H', -- Weak 1,
  4. Make a resolution function similar to the resolution function given in the IEEE std_logic_1164 package.
  5. Use a table lookup for the evaluation of any two pairs of ttu. No if- or case statements are allowed. Remember that a normal open collector resolution function assumes that the driving strengths of the zero is much stronger than the driving strength of the one. Define new types ttu_logic and ttu_logic_vector that use your ttu resolution function.
    1. What is the interpretation of the table lookup?
  6. Now we want to test that the open collector function work properly. You can try to go through all possible combinations. To do this with a multi-valued signal is a bit trickier. First, we have to loop through all values in the new type, and then we have to make sure that the other signal is updated at an interval that is long enough for the first one to go through all values. To do this, we use the test pattern generator which incorporates following logic.

    1. Why is the clock period of clk2 50 ns when the clock period of clk1 is 10 ns?
    2. In which order are the values selected from ttu by the FOR - LOOP statement? Why that particular order?
  7. Now we will perform an overloading of operators
  8. Redefine and overload the operator XOR for the ttu type. Include the operator in your previous made package. As before, use the table lookup style of writing.
  9. Test your function with the same test pattern as before, although instead of assigning both values to the same wire, assign one of them to a signal a, and the other to a signal b and use a dataflow statement to evaluate the XOR-functionality.
    1. Is it possible to define a new operator XNOR, which will perform the operation NOT(a XOR b) in VHDL'87? What about VHDL'93? (HINT! Try to compile with VHDL'87 and VHDL'93, respectively, by changing the default in the compiler options menu)
  10. Prototyping a Data bus
    1. The last task is to prototype a data bus onto the FPGA-board and evaluate how FPGAs interpret data buses. Write a VHDL component that connects two registers with four bits each to a data bus. Then connect the two registers to the DIP switches of the FPGA board and connect the individual bits of the data bus to four LED segments of your choice. Prototype your design and see what functionality that the resulting bus gets. A lso, examine the produced layout and see how the Xilinx ISE has connected the components on the data bus together. Use the Technology viewer (Post-mapping) and click your way down in the hierarchy and go inside the Tri-state function. The equations are shown if you place the mouse pointer on top of the LUT.
    2. What functionality does the data bus exhibit and how are the wires on the bus (actually) connected?