Introduction to Digital Simulation

 

Purpose

We have seen some of the basic combinational logic devices, and designed some circuits to implement simple logic functions. For larger designs, it is important to verify our designs through simulation, while maintaining the look and feel of a real workbench. In this lab, we introduce a simple graphical simulator called Diglog.

Required Reading

Appendices  and  of this manual.

Preparatory Exercises

Implement the following in Diglog. Please annotate appropriately.

1. Sample circuit discussed in Appendix .
2. Circuit in Figure B.2 of P&H. Verify that it is indeed the function .

Discussion

Simulation

For the purposes of this laboratory course, we will do all lab work in a simulation environment. For this reason, please become familiar with the Diglog program -- we shall use it extensively.

What is different about what we do in simulation than what occurs in a physical circuit? Most devices are idealized in simulation, whereas real devices are subject to physical constraints. The biggest difference we will be concerned with is timing (the subject of Appendix B.7 in P&H). Needless to say, our ``perfect'' gates in Diglog are not completely accurate representations, but these gates are quite suitable for our purposes.

Most of the gates we will use are generic versions of real, production gates. However, we will sometimes need to use standard gates as they provide us with some of the functionality we need (e.g. a mux or a decoder.) Please note that any pin configurations needed will be provided.

Some of these standard logic gates are better known by their part numbers which were popularized by Texas Instruments in the 1960's and 70's, called the 74-series TTL chip family. (``TTL'' stands for ``transistor-transistor logic'' which describes the technology used to create the gates.) All the chips in this family have names of the form 74xxx, where xxx is a numeric designator. For example, the chip with four 2-input NAND gates on it is called the ``7400.''

A closer look

Diglog has many of the 74-series TTL chips in its library of gates, in addition other generalized devices such as the basic AND, NAND, etc. gates and even a ROM. Let's first look at a decoder and a mux, and see how the TTL version differs from the ideal version we have been introduced to in P&H. See Figure .

  
Figure: A decoder and a mux

The chip on the left is a 74138 3-to-8 decoder. It has three enable pins labeled G1, G2A, G2B. Notice how two of the enable pins have bubbles next to them. These pins are ``active low'' (explained in both Lab  and Section ). Also note that all the outputs are active low. So what does the truth table for this chip look like? See Table .

  
Table: Truth table for 74138 3-to-8 decoder.

Does this table make sense? Verify that it does act like the decoder depicted in Figure B.4 in P&H. The chip on the right is the 74151, an 8-bit, one input mux. which one active low enable pin. See Table  for its truth table.

  
Table: Truth table for 74151 8-bit, one input mux.

Confirm that this is correct. Next, let's look at a 8Kx8 ROM device in Figure  (known as the SRAM8K device).

  
Figure: Diglog ROM device (annotated).

Notice there are 13 address pins and 8 data pins. Why? We need 13 address pins to access all 8K ( ) entries, which are 8 bits wide. This means we can implement at a logic function with 13 inputs and 8 outputs. How does Diglog let us ``program'' this device? If we type 'c' (for CNFG-mode) and then click on the device. Figure  shows what appears in the newcrt window. The following options are of interest to us:

Mode:

We want ``Read-only.''

Address (hex):

This field allows us to scroll through the values stored in our ROM with the left and right cursor keys. The current values at the hex address shown will be reflected in the Data fields below.

Address (decimal):

Decimal equivalent of current address.

Data (hex):

The hex value stored in the address shown above.

Data (decimal):

The decimal value stored in the address shown above.

Save in circuit file?

If 'yes' is selected, then the ROM image we load will be hard-coded into the Diglog '.lgf' file. If 'no' is selected, then a ROM image file will have to be loaded every time Diglog is started.

File name to load:

The name of the ROM image file.

File name to save:

Only useful when device is used as a RAM device (we will use this option in the future).

  
Figure: Configuring the SRAM8K device.

Does it make sense that the data can be represented with two hexadecimal digits? And what is a ``ROM image file?'' We will answer that question in the Design Exercises section.

Design Exercises

1. Enter your design for Problem 3 of Lab  into Diglog. Attach LEDs to the outputs and switches to the inputs.
2. Design a 9-bit parity circuit with two outputs, one for even, one for odd. (Do not simply invert one of the outputs to get another! The structure for this circuit is described below.)
   1. A 3-bit odd parity circuit is given in Figure  below.

        
      Figure: Simple 3-bit odd parity circuit.
      

   2. After reading the section on hierarchical design (Section ), create a 3-bit parity instance using the INST0 gate, using the label ``3-par'' as its name. Make sure to box the entire circuit using the 'b' command, and be sure to include the label inside the box.
   3. Now scroll over to another part of the page, and design a 9-bit odd parity circuit using four copies of your new instance gate only. Make a two-stage design (Hint: Use all nine inputs in the first stage.)
   4. Add a another output for even parity using one more 3-bit parity instance and an inverter (which must be put before the instance gate!)
   Congratulations! You just designed a 74280.
3. Design a circuit that takes a eight bit number as input and outputs four bits, each indicating one of the following conditions (answering yes to the question means a high should be output):
   • Is the number less than 200?
   • Is the number a perfect square?
   • Do the sum of the digits in the number add up to 9?
   • Is the last digit of the number a 5?
   Use a ROM to solve this problem. We need to create a ROM image that possesses all this information. But how? Let's first look at the format of a Diglog ROM image:

   0000:FECC0000000000000000000000000000
   0010:00000000000000000000000000000000
   0020:00000000000000000000000000000000
   .
   .
   .

   The number in front of the colon is the input address in hexadecimal. The long string after the colon represents the data (16 bytes per line) stored in the ROM, byte by byte, again in hex format. For example, at address 0 the data is 'FC' which in decimal is '253.' So, we will solve the problem in the following manner:
   • Write a C/C++ program that outputs the correct ROM image to some file. Only the first 256 ( ) bytes are needed.
   • Create a Diglog schematic with a ROM, eight switches on the eight least significant address pins, and four LEDs on the the four least significant data bits. This means you should write out your ROM image this way too (e.g. the upper four bits of every byte will be a '0').
   • Test the circuit to see if it works.
   To answer this problem, hand in your C/C++ program, the ROM image in created, and the Diglog schematic. As always, properly comment and annotate everything.