Файл: Circuit Design with VHDL (A.Pedroni, 2004).pdf

(a) In order to provide the necessary security, introduce some kind of handshake between the controller and the external circuitry. As an example, the handshake could include the following:

(i)an ‘‘input valid’’ signal (call it coin_valid), from the external circuit to the controller, informing that a new input is ready to be read. This signal should return to ‘0’ as soon as it has been processed by the controller, so a new input will only be considered by the controller at its rising edge. This is important to avoid possible confusion which may occur when nickel_in, dime_in, or quarter_in stays present at the input of the FSM for more than one clock cycle (so it will not be interpreted as a second coin, as in the design of section 9.5)

(ii)an ‘‘input accepted’’ signal (call it coin_accepted), from the controller to the external circuit, informing that the present input has already been processed. Upon receiving this signal, the external circuit should cause coin_valid to return to ‘0’.

(b)Consider that the nickel or the dime box in the vending machine might run out of coins. Design alternative return paths taking such possibilities into consideration. (Suggestion: simply include new arrows between st45 ! st40 and st35 ! st30 in the FSM diagram of figure 9.11).

(c)Finally, consider the situation where a customer might continue depositing coins even when the necessary amount has already been reached. What should be done in such a situation?

Problem 9.4: Serial Data Receiver

Try to model and design the serial data receiver of section 9.6 utilizing the FSM (finite state machine) approach (chapter 8). Before you start writing you VHDL code, present a clear states diagram of the system.

Problem 9.5: Serial Data Transmitter

This problem is the counterpart of that treated in section 9.6. Here, the stored data must be transmitted serially. A diagram of the circuit is shown in figure P9.5. The

data in

TLFeBOOK

protocol is the same 10-bit structure of section 9.6; that is, a start bit (high), followed by seven bits of actual data, plus a parity bit, computed such that the total number of ‘1’s in positions 2 to 9 is even, and finally a stop bit (also ‘1’). Consider that a data_ready signal is available to inform when the data can be loaded into the registers and sent out.

Problem 9.6: Playing with an SSD

You are asked to introduce additional features in the little seven-segment display (SSD) game of section 9.8.

(a)Add a 2-bit input, called ‘‘speed’’, which should be able to select four di¤erent speeds for the circulatory movement. Keep the overlap time (time2) fixed at 30 ms, changing only time1. Choose four di¤erent circulatory periods and physically verify whether the circuit behaves as expected.

(b)Change the functionality of the stop input, such that instead of going to state when a stop is asserted, it freezes in whatever state it was when stop was activated, proceeding from there when stop returns to zero.

(c)Finally, add a ‘‘direction’’ pin. When low, the circuit should behave as above, but when high, it should circulate in the opposite direction (counterclockwise).

(d)Physical verification: After synthesizing and simulating your design, physically implement it in you PLD/FPGA development kit, following the steps below.

(i)First, verify in the report file generated by the compiler which pins of the chip were assigned to the inputs (clock and switches) and to the outputs (SSD).

(ii)Next, connect the signal generator (set to 1 kHz, with the appropriate logic levels, but leave it OFF while you make the connection) and the switches (which should provide VDD and GND levels) to the inputs of the circuit (your development kit board is normally equipped with test switches).

(iii)Connect the outputs of the chip to the SSD (your development kit board is normally equipped with seven-segment displays).

(iv)Finally, download the compiled file from your computer to the development kit, turn ON the signal generator, and verify the operation of your circuit. Play with the switches in order to test all operation modes.

Problem 9.7: Speed Monitor

Figure P9.7 shows a possible view of a car speed monitor. The specifications of the system are the following:

TLFeBOOK

ON/OFF

SPEED

35 45 55 60 65 70 75 80

Figure P9.7

Speed selection button (SPEED), which, at each touch, selects the next speed to be monitored (35, 45, 55, 60, 65, 70, 75, or 80 miles/hour).

Set of eight LEDs, one for each speed. The LED corresponding to the selected speed should be ON.

Two SSDs, which show the actual speed of the car. The car’s electronic speedometer provides a clock signal whose frequency is proportional to the speed. You may check the data sheet of the speedometer that you are going to use, or you can start with a simple round number, which you can provide with a signal generator to test your circuit (say, 100 Hz per mile/hour).

Buzzer, which emits alarm signals as the car approaches the selected speed. A 2 Hz signal should be emitted when the speed is three miles/hour or less from the selected speed, or a continuous alarm when at or above the selected speed. Consider a buzzer with internal oscillator, so only a DC signal must be provided in the latter case, or a square wave with frequency 2 Hz in the former case.

Write a VHDL code for such a circuit. Synthesize and simulate it. Finally, physically implement it in your PLD/FPGA development kit, using a signal generator for clock and following steps similar to those in problem 9.6.

Problem 9.8: Random Number Generator

Design a 1-digit random number generator. The number should be from ‘‘0000’’ (display ¼ 0) to ‘‘1111’’ (display ¼ F). Use the circuit of section 9.8, with a modified function for the stop switch. The SSD should remain in a circular motion until the switch is pressed. When pressed, a random number should be displayed, being the circular movement resumed at the next touch of the switch. After compiling and simulating your circuit, physically implement it in your PDD/FPGA development kit.

TLFeBOOK

II SYSTEM DESIGN

TLFeBOOK

10 Packages and Components

10.1Introduction

In Part I of the book, we studied the entire background and coding techniques of VHDL, which included the following:

Code structure: library declarations, entity, architecture (chapter 2)

Data types (chapter 3)

Operators and attributes (chapter 4)

Concurrent statements and concurrent code (chapter 5)

Sequential statements and sequential code (chapter 6)

Signals, variables, and constants (chapter 7)

Design of finite state machines (chapter 8)

Additional circuit designs (chapter 9)

Thus, in terms of figure 10.1, we may say that we have covered in detail all that is needed to construct the type of code depicted on its left-hand side. A good understanding of that material is indispensable, regardless of the design being just a small circuit or a very large system.

In Part II, we will simply add new building blocks to the material already presented. These new building blocks are intended mainly for library allocation, being shown on the right-hand side of figure 10.1. They are:

Packages (chapter 10)

Components (chapter 10)

Functions (chapter 11)

Procedures (chapter 11)

These new units can be located in the main code itself (that is, on the left-hand side of figure 10.1). However, since their main purpose is to allow common pieces of code to be reused and shared, it is more usual to place them in a LIBRARY. This also leads to code partitioning, which is helpful when dealing with long codes. In summary, frequently used pieces of code can be written in the form of COMPONENTS, FUNCTIONS, or PROCEDURES, then placed in a PACKAGE, which is finally compiled into the destination LIBRARY.

We have already seen (chapter 2) that at least three LIBRARIES are generally needed in a design: ieee, std, and work. After studying Part II, we will be able to construct our own libraries, which can then be added to the list above.

TLFeBOOK

As mentioned above, frequently used pieces of VHDL code are usually written in the form of COMPONENTS, FUNCTIONS, or PROCEDURES. Such codes are then placed inside a PACKAGE and compiled into the destination LIBRARY. The importance of this technique is that it allows code partitioning, code sharing, and code reuse.

We start by describing the structure of a PACKAGE. Besides COMPONENTS, FUNCTIONS, and PROCEDURES, it can also contain TYPE and CONSTANT definitions, among others. Its syntax is presented below.

PACKAGE package_name IS (declarations)

END package_name;

[PACKAGE BODY package_name IS

(FUNCTION and PROCEDURE descriptions) END package_name;]

As can be seen, the syntax is composed of two parts: PACKAGE and PACKAGE BODY. The first part is mandatory and contains all declarations, while the second

TLFeBOOK

part is necessary only when one or more subprograms (FUNCTION or PROCEDURE) are declared in the upper part, in which case it must contain the descriptions (bodies) of the subprograms. PACKAGE and PACKAGE BODY must have the same name.

The declarations list can contain the following: COMPONENT, FUNCTION, PROCEDURE, TYPE, CONSTANT, etc.

Example 10.1: Simple Package

The example below shows a PACKAGE called my_package. It contains only TYPE and CONSTANT declarations, so a PACKAGE BODY is not necessary.

1 ------------------------------------------------

2LIBRARY ieee;

3 USE ieee.std_logic_1164.all;

4 ------------------------------------------------

5PACKAGE my_package IS

6 TYPE state IS (st1, st2, st3, st4);

7TYPE color IS (red, green, blue);

8 CONSTANT vec: STD_LOGIC_VECTOR(7 DOWNTO 0) := "11111111"; 9 END my_package;

10 ------------------------------------------------

Example 10.2: Package with a Function

This example contains, besides TYPE and CONSTANT declarations, a FUNCTION. Therefore, a PACKAGE BODY is now needed (details on how to write a FUNCTION will be seen in chapter 11). This function returns TRUE when a positive edge occurs on clk.

1 -------------------------------------------------

2LIBRARY ieee;

5PACKAGE my_package IS

6 TYPE state IS (st1, st2, st3, st4);

7TYPE color IS (red, green, blue);

8CONSTANT vec: STD_LOGIC_VECTOR(7 DOWNTO 0) := "11111111";

9 FUNCTION positive_edge(SIGNAL s: STD_LOGIC) RETURN BOOLEAN;

10 END my_package;

TLFeBOOK

11 -------------------------------------------------

12 PACKAGE BODY my_package IS

13FUNCTION positive_edge(SIGNAL s: STD_LOGIC) RETURN BOOLEAN IS

14BEGIN

15RETURN (s'EVENT AND s='1');

16END positive_edge;

17END my_package;

18 -------------------------------------------------

Any of the PACKAGES above (example 10.1 or example 10.2) can now be compiled, becoming then part of our work LIBRARY (or any other). To make use of it in a VHDL code, we have to add a new USE clause to the main code (USE work.my_package.all), as shown below.

------------------------------------

LIBRARY ieee;

USE ieee.std_logic_1164.all;

USE work.my_package.all;

------------------------------------

ENTITY...

...

ARCHITECTURE...

...

------------------------------------

10.3 COMPONENT

A COMPONENT is simply a piece of conventional code (that is, LIBRARY declarations þ ENTITY þ ARCHITECTURE, as seen in chapter 2). However, by declaring such code as being a COMPONENT, it can then be used within another circuit, thus allowing the construction of hierarchical designs.

A COMPONENT is also another way of partitioning a code and providing code sharing and code reuse. For example, commonly used circuits, like flip-flops, multiplexers, adders, basic gates, etc., can be placed in a LIBRARY, so any project can make use of them without having to explicitly rewrite such codes.

To use (instantiate) a COMPONENT, it must first be declared. The corresponding syntaxes are shown below.

TLFeBOOK

COMPONENT declaration:

COMPONENT component_name IS PORT (

port_name : signal_mode signal_type; port_name : signal_mode signal_type;

...); END COMPONENT;

COMPONENT instantiation:

label: component_name PORT MAP (port_list);

As can be seen, the syntax of the declaration is similar to that of an ENTITY (section 2.3); that is, the names of the ports must be specified, along with their modes (IN, OUT, BUFFER, or INOUT) and data types (STD_LOGIC_VECTOR, INTEGER, BOOLEAN, etc.). To instantiate a component a label is required, followed by the component’s name and a PORT MAP declaration. Finally, port_list is just a list relating the ports of the actual circuit to the ports of the pre-designed component which is being instantiated.

Example: Let us consider an inverter, which has been previously designed (inverter.vhd) and compiled into the work library. We can make use of it by means of the code shown below. The label chosen for this component was U1. The names of the ports in the actual circuit are x and y, which are being assigned to a and b, respectively, of the pre-designed inverter (this is called positional mapping, for the first signal in one corresponds to the first signal in the other, the second in one to the second in the other, and so on).

-----COMPONENT declaration: -----------

COMPONENT inverter IS

PORT (a: IN STD_LOGIC; b: OUT STD_LOGIC); END COMPONENT;

-----COMPONENT instantiation: -----------

U1: inverter PORT MAP (x, y);

There are two basic ways to declare a COMPONENT (figure 10.2). Once we have designed it and placed it in the destination LIBRARY, we can declare it in the

TLFeBOOK

main code itself, as shown in figure 10.2(a), or we can declare it using a PACKAGE, as in figure 10.2(b). The latter avoids the repetition of the declaration every time the COMPONENT is instantiated. Examples of both approaches are presented below.

Example 10.3: Components Declared in the Main Code

We want to implement the circuit of figure 10.3 employing only COMPONENTS (inverter, nand_2, and nand_3), but without creating a specific PACKAGE to declare them, thus as in figure 10.2(a). Then four pieces of VHDL code are needed: one for each component, plus one for the project (main code). All four files are shown below. Notice that, since we have not created a PACKAGE, the COMPONENTS must be declared in the main code (in the declarative part of the ARCHITECTURE). Simulation results are presented in figure 10.4.

1------ File inverter.vhd: -------------------

2 LIBRARY ieee;

3 USE ieee.std_logic_1164.all;

4 ------------------------------------

5 ENTITY inverter IS

6 PORT (a: IN STD_LOGIC; b: OUT STD_LOGIC); 7 END inverter;

8 ------------------------------------

9 ARCHITECTURE inverter OF inverter IS

10 BEGIN

11 b <= NOT a;

12 END inverter;

13 ---------------------------------------------

1------ File nand_2.vhd: ---------------------

2LIBRARY ieee;

3 USE ieee.std_logic_1164.all;

4 ------------------------------------

5ENTITY nand_2 IS

6 PORT (a, b: IN STD_LOGIC; c: OUT STD_LOGIC); 7 END nand_2;

8 ------------------------------------

9 ARCHITECTURE nand_2 OF nand_2 IS

TLFeBOOK