VHDL Workshop: Camera

• LAB 1: A Multiplexer
• LAB 2: Extending the Multiplexer
• LAB 3: A 7-Segment Display Driver
• LAB 4: A Three Digit 7-Segment Display Driver
• LAB 5: A Decoder
• LAB 6: A Register
• LAB 7: A State Machine for the Display
• LAB 8: A Timer
• LAB 9: A BCD-Counter
• LAB 10: A State Machine for the Main Controller
• LAB 11: The Camera

This VHDL teaching program is divided into several exercises. By writing typical VHDL programs you learn how to use this hardware description language. In the beginning you are guided in a step by step manner, later on when you are used to the language and the tools you will solve the tasks on your own. We are referring to the VHDL’87 standard, because the VHDL’93 is not yet supported by all tool manufacturers.

The tasks are divided into different sections:

• Synopsis: In this section you learn about the goal of the task and the function of the model within the whole design.
• Behaviour: This section tells you more about the function of the model.
• Data Types: In this section the types to be used in the current exercise are described.
• To Do: Here is the precise description of your job to solve the task.
• Implementation: Here you find a list of VHDL code which represents a possible implementation.

In VHDL it is very important to have a consistent naming. The following naming conventions should be followed within this workshop:

The goal of this course is the design of a camera control system. Its main focus is to demonstrate the application of the hardware description language VHDL in a real world setting. Of course, the problem has been heavily simplified, yet it is powerful enough to point out all main concepts of the language to the beginner. After completing the course you should feel comfortable writing VHDL code on your own.

The camera control system has to generate the appropriate signals for the lens shutter and the film transportation motor. It also generates the input signals for a small 7-segment display showing either the current exposure time or the total number of pictures taken so far. The user controls the camera operation via several keys.

The central control system that is to be developed in this course is split into seven modules:

1. A decoder (decoder) is used to preprocess the signals from the input device for the controller.
2. The exposure latch (exp_ff) stores the selected exposure time.
3. A timer for the film transport (motor_timer) is used to detect errors during film transportation, e.g. if the film is torn apart.
4. The exposure controller (exp_ctrl) opens the lens shutter for the selected exposure time and counts the number pictures that have been taken.
5. The photo controller (main_ctrl) is the central control unit for the camera control system.
6. A specialized display controller (disp_ctrl) selects the appropriate data for the 7-segment display.
7. The display driver (disp_drv), finally, converts the internal data signals into a format suitable for the output device.

The clock frequency of the camera control is 8192 Hz. It allows for exposure times according to the following formula:

2^(-i) seconds (for i = 0..9).

You need this information later on in order to implement the required times. The camera control system has to:

• determine the exposure time
• take a (sequence of) picture(s)
• generate the exposure control signal
• generate a control signal for the servo which transports the film
• detect end of film and tear in film errors while transporting the film

In order to follow the exercises you will need an editor to enter the code. It is advisable to use an editor with a VHDL language mode as they facilitate the detection of typographic errors in VHDL keywords. The notorious Emacs disposes of a powerful VHDL macro set with templates for most language constructs, special copy & paste functions for signal lists and much more.

As the VHDL simulators can not deal with ASCII text immediately, your designs need to be compiled into a machine readable format first. After the proper behaviour has been verified, a synthesis tool is used to map the RTL description to a network of gates. In addition to the software package you will also need a library containing a description of the properties of all available cells.

The goal of this pre-exercise is to get used to the simulation and synthesis tools, and to learn the basic commands of the tools used. As there is a great variety of tools we can give only very generally descriptions of the tasks to do. This exercise does not require any specific VHDL knowledge. In order to get used to the tools, please refer to the corresponding user manuals of the software tools used and proceed through the following steps:

First, you will need a directory where you can store the VHDL source code files. In the following, we assume that ~/workshop is the base directory for this project. It is advisable to separate the VHDL sources from their derived files, i.e. we will create a subdirectory ~/workshop/WORK for the analysed objects.

The simulation and synthesis software can have their own setup files. Especially if You are using tools from different producers. The principles for initializing the software are quite often similar. Please consult your software documentation for detailed information.

Normally a setup file has to be created. You can do this either by hand with an editor (save the file in the current, it is the ~/workshop directory) or within a menu of the software used.

Example of a simulation setup file:

TIMEBASE = NS

WORK    >  DEFAULT
DEFAULT :  ./WORK

USE = .

• TIMEBASE defines the timescale (nano seconds) for the simulation.
• The VHDL library WORK is mapped to the logical library DEFAULT. The physical path for this library is /WORK, i.e. the analysed files will be stored there (~user/workshop/WORK).
• USE defines a list of directories where the simulator searches for the VHDL source code.

Normally a setup file has to be created. You can do this either by hand with an editor (save the file in the current, it is the ~/workshop directory) or within a menu of the software used. If you use a framework perhaps only one setup file for simulation and synthesis is needed.

Example of synthesis setup file:

.synopsys_dc.setup

search_path = search_path + { . }
 
define_design_lib work -path ./WORK
 
link_path = {vendorlib.db }
target_library = {vendorlib.db }
symbol_library = {vendorlib.sdb }
link_library = {vendorlib.db }

• “search_path +“ adds current directory to the search path
• define_design_lib defines library for the analysed files (~user/workshop/WORK).
• The last 4 lines define the link-, target-, and symbol-library of the target library.

The design flow that will be followed throughout the exercises will be demonstrated at the example of a simple AND-gate. Please create a file named and_gate.vhd in your VHDL sources directory (~/workshop) and enter the following code.

and_gate.vhd

-- VHDL model of an AND gate
library IEEE;
use IEEE.std_logic_1164.all;
 
entity AND_GATE is
port (A,B : in std_logic;
        Z : out std_logic);
end AND_GATE;
 
architecture RTL of AND_GATE is
begin
  Z <= A and B;
end RTL;

Before you will be able to simulate the design you have to compile your ASCII sources. An so called analyser (sometimes also called “compiler”, “reader”, …) is used for this purpose. The resulting files are stored in the default library which is mapped to the directory ./WORK in the simulation setup file. If you need to compile your sources into a different library, please refer to the corresponding user manual. Of course, the other library has to be mapped to a physical directory, as well.

Please remember that the VHDL design units have to be analysed in a certain order. You (sometimes the software will do this for you) will have to observe the following rules in order to avoid compilation errors:

• Main units have to be analysed before side- or sub-units
  • entity before architecture
  • package before package body
• Units that others refer to have to be analysed first
  • package before entity/architecture
  • entity/architecture before configuration

The referenced standard package std_logic_1164 is already available in compiled format, i.e. you just have to analyse the entity AND_GATE before its RTL architecture. As the entity description is located in front of the architecture definition in the source code, please just compile this file and you will be ready to simulate the design.

In order to verify the proper behaviour of your VHDL code, you will also need to create testbenches that stimulate your design. The testbench for the AND gate contains the instantiation of the device under test (DUT) and a simple stimulus process that assigns all possible signal combinations to the component inputs.

Please create the file tb_and_gate.vhd and enter the following VHDL code:

tb_and_gate.vhd

library IEEE;
use IEEE.std_logic_1164.all;
 
entity TB_AND_GATE is
end TB_AND_GATE;
 
architecture TEST of TB_AND_GATE is
  component AND_GATE
    port (A, B : in std_logic;
             Z : out std_logic);
    end component;
 
  signal W_A, W_B, W_Z : std_logic;
 
begin
  DUT : AND_GATE
    port map(A => W_A,
             B => W_B,
             Z => W_Z);
 
  STIMULI : process
  begin
    W_A <= ’0’;
    W_B <= ’0’;
    wait for 10 ns;
 
    W_A <= ’1’;
    wait for 10 ns;
 
    W_B <= ’1’;
    wait for 10 ns;
 
    W_B <= ’0’;
    wait for 10 ns;
 
    wait;
  end process STIMULI;
end TEST;
 
configuration CFG_TB_AND_GATE of
                   B_AND_GATE is
  for TEST
  end for;
end CFG_TB_AND_GATE;

Prior to simulation you will also have to compile the file, i.e. please run the VHDL analyser (e.g. ’myanalyser and_gate.vhd’; or you have to select a menu entry, e.g. ’analyse’).

Now you are ready to invoke the VHDL simulator if not already done. If not done automatically you have to choose the object to simulate and specify additional simulation parameters. Remember that the configuration is the only VHDL object that can be simulated. Some tools require no (top-) configuration as they built up a default configuration on their own. In this case you can select the top entity for simulation (here it would be TB_AND_GATE). In the other case please select CFG_TB_AND_GATE and press OK to open the simulation control window. The next points describe features which are common to most simulation tools:

• The source code currently simulated is shown in a window. Normally you can change the content of this window by moving up and down in the design hierarchy.
• In another window some status information (current hierarchy level, current simulation time, etc.) is given and there are a couple of short cut buttons for the most commonly used commands.
• Sometimes there is a command interface to the simulator, e.g. a command line at the very bottom of the display.
• Normally you can move your design hierarchy using commands or a design hierarchy browser. The design hierarchy is mostly presented like a filesystem (UNIX: ’/’ denotes the root of the hierarchy, ’..’ the previous level). In this example, the first hierarchy level contains your testbench (/TB_AND_GATE) and the referenced packages (/ STD_LOGIC_1164 and /STANDARD), which is always loaded.
• In order to view the data in a waveform display, you will have to invoke the waveform display tool. Sometimes this is done automatically when you start the simulation. Please make sure that all signals of your testbench are being traced during simulation (refer to the user manual of the simulation software used).

Simulation Control

• The actual simulation cycle is started with the a ’run’ command (or button). If no additional options are given, the simulator normally stops when no signals need to be updated anymore. In this example, the simulator will stop after 40 ns. Optionally, you may specify a maximum run time, e.g. ’run 100’ to display the signal values for 100 ns.
• If you have for example a clocked design and want to simulate just one clock cycle at a time, it is convenient to enter the clock period as an argument of the ’run’ command. Perhaps you have to fix the simulation step width in a menu entry.
• You may stop the simulation cycle either by setting breakpoints or with a manual interrupt. Of course, the simulation will also be stopped, if an VHDL assertion with the appropriate severity level is violated or if a runtime error occurs.
• There exist two breakpoint variants: The ’Stop at’ function halts the execution when the corresponding VHDL code line is reached. Please note, however, that in this case probably not all signals carry their new values for the current time step. The ’Event Bkpt.’ function enables you to interrupt the simulation whenever the selected signal changes its value.
• Once the simulation is stopped, you normally can proceed step wise via a ’step’ and/or ’next’ command.
• Normally the simulation tool creates a history (file) of the commands you entered. So you can repeat your simulation by loading this history.

After you have verified the function of your model with the simulator you can run the synthesis tool. Again you have to analyse the VHDL source code. This is normally done automatically when you read in your VHDL file.

• Read the file “and_gate.vhd” (via File → Read). Go through the tool messages to check whether your design is conform to the synthesis subset which is supported by your synthesis tool. In general only a subset of the 1076-VHDL standards is supported. This subset is now (end of 1999) standardized but not supported by the tools until now.

In future tasks/exercises we will define our own packages. The synthesis tool requires that packages are read (analysed) before they are used or referenced. The most frequent errors with the synthesis are missing not read (analysed) packages!

• Sometimes you can examine your design after you have read in the source file. This representation is called generic netlist. (Translation of the VHDL code in a set of tool specific symbolic gates).
• The most tools are optimizing for area if no specific synthesis constraints are set. Use the defaults constraint settings and start the design optimization (the actual synthesis; refer to your user manual).
• You will now get a netlist which is optimized for the selected target library (see Synthesis Setup).
• Examine the gate level implementation. Normally commands for zooming in and out, features for highlighting special paths, analysis functions and report generators are available. The report of the area (ASIC) needed or percent of available resources (FPGA) used, the maximum clock frequency possible and sometimes an estimation of the power consumption are interesting reports.