Universität Duisburg-Essen FCE 1. Experiment 4. Microprogramming

Size: px

Start display at page:

Download "Universität Duisburg-Essen FCE 1. Experiment 4. Microprogramming"

Ronald Montgomery
5 years ago
Views:

1 Universität Duisburg-Essen PRACTICAL TRAINING TO THE LECTURE FCE 1 Experiment 4 Microprogramming Name: First Name: Tutor: Matriculation-Number: Group-Number: Date: All questions marked with Q1 to Qn must be answered before the lab begins. All tasks marked with T1 till Tn must be completed to finish the lab. Prof. Dr.Ing. Axel Hunger Dipl.Ing. Joachim Zumbrägel Universität Duisburg-Essen Faculty of Engineering, Department Electrical Engineering and Information Technology Computer Engineering Copyright (C) Computer Engineering

2 Introduction Up to now we have been working with simple logical devices, such as flip-flops. In the current experiment, however, we will get familiar with a new type of logical device, the ROM. We will attempt to build a traffic-light control system, during which the programming of a ROM device will be clarified and carried out. 1. Specification of Traffic-Light Behavior In this experiment we will develop and simulate a traffic-light control system, which purpose is to regulate 4 distinct traffic-lights on a crossroad. Fig. 1.1 shows the structure of the crossroad and position of the traffic-lights. Using 3 distinct signal lights (red, yellow and green), each traffic-light follows a well known light patter consisting of 4 different states: red (rd), red and yellow (ry), green (gr) and yellow (yl). All 4 traffic-lights repeat periodically the 4-state pattern, which results in a period of 16 states for the whole crossroad. Fig. 1.1: Crossroad with 4 traffic-lights In Table 1.1 the 16 states cycle for the crossroad is shown along with the duration for each system state. For example, line 1 of Table 1.1 defines traffic-lights A and B as red, and trafficlights C and D as green. This state lasts for time t5. In reality different crossroad states require different duration. Therefore, for this experiment we define five distinct durations: t1, t2, t3, t4 and t5. The actual time these durations require is of no importance, what is relevant is the relation between them. t1 is defined as basic time period, therefore: t2 = 2*t1 t3 = 4*t1 t4 = 5*t1 t5 = 20*t1 To clear the crossroad from traffic, state 5 will be used and it will last t3 = 4*t1. 2/16

3 State A B C D Duration 1 rd rd gn gn t5 2 rd rd yl gn t2 3 rd rd rd gn t4 4 rd rd rd yl t2 5 rd rd rd rd t3 6 rd ry rd rd t1 7 rd gr rd rd t4 8 ry gr rd rd t1 9 gn gr rd rd t5 10 gn yl rd rd t2 11 gn rd rd rd t4 12 yl rd rd rd t2 13 rd rd rd rd t3 14 rd rd ry rd t1 15 rd rd gr rd t4 16 rd rd gr ry t1 Table 1.1: Traffic-light states for one cycle Q1: How many different combinations of traffic-light system states are there? How many bits are necessary to encode these combinations? Q2: How many bits are needed to encode the states of a single traffic-light? 2. Building the Traffic-Light system The controller for the crossroad traffic-light system is now to be developed, making use of a constant memory storage device, a ROM (Read Only Memory). The ROM should be programmed with all crossroad traffic-light system states. The input signals for the individual 3/16

4 traffic-lights will be the output of the programmed ROM. The addressing of the specific ROM output is done by a counter. Since the ROM has only 8 outputs and we have 4 distinct trafficlight with 3 lamps each, we need a decoder to translate the output from the ROM to input for the traffic-lights. Overall we need 4 decoders for each traffic-light. Each decoder takes 2 input signals and produces an output of 3 signals for red, yellow and green. Fig. 2.1 shows the structure of the traffic-light system controller. Counter & Address defining circuit Red Yellow Green Red Yellow Green Red Yellow Green Red Yellow Green Prof. OE Fig. 2.1: Traffic-light system controller 2.1 General specification of the structuring elements Before we begin with the development of the traffic-light system, the structuring elements of the system will be shortly clarified Read-Only Memory (ROM) A ROM (Read Only Memory) is a storage device, from which during runtime data can be read, but to which no data can be written. Typically, a ROM can be programmed with a specific number (2 n ) of data words, each having a data length of m. For example if m = 8 a word with the length of 8 bits is stored. These data words are written in addressable storage places in the ROM. To output the content of a specific storage place in the ROM, the address of that place must be input in binary code. In order to calculate the storage capacity of a ROM, we use the formula 2 n x m. For example a 1024x8-bits ROM, means that 2 10 = 1024 data words, each being 8 bits long, can be stored. Furthermore, the device must have 10 inputs (A0 A9), which will define the desired data word s address, and 8 outputs (O0 O7), which will give out the addressed data word. 4/16

5 bit Counter To realize the addressing of the ROM, a counter would be needed. We could directly use the part from the 7400 library to build the appropriate counter for the job. Depending on the input this device could be set to work in different modes. One of these is a 4-bit counter, where the outputs QA QD (least significant bit being QA and most significant bit being QD) can realize the numbers 0-15 in binary code Decoder A decoder is a sort of converter, which could be built in a software or hardware form depending on the application. In the logical circuits world the function of a decoder is to take any number of inputs n and decode them in 2 n outputs. Table 2.1 illustrates the truth table of a 2x4 decoder. This decoder takes information represented by 2 bits and decodes it in a 2 2 = 4 bit form. Fig. 2.2 shows the logical symbol of the 2x4 decoder. X1 X2 Y1 Y2 Y3 Y X1 X2 2x4 Decoder Y1 Y2 Y3 Y4 Table 2.1: Truth table of 2x4 Decoder Fig. 2.2: 2x4 Decoder symbol 2.2 Encoding the traffic-light system states in a ROM The task now is to encode the different states presented in Table 1.1 of the traffic-light system and program them in a ROM, taking into consideration the corresponding duration of each system state. Before we do that, we have to think about the encoding of the different states of a single traffic-light. For that reason we refer to Table 2.2, from there we see that we need 2 bits to encode all 4 states of a traffic-light. D 1 D 0 Red 0 0 Yellow 1 1 Green 0 1 Red-Yellow 1 0 Table 2.2: Coding of the states of a single traffic-light Q3: How many bits are needed to encode the states of all 4 traffic-lights? What must the data word length be for our ROM? The different duration of traffic-light system states (see Table 1.1) can be easily implemented the following way: system states that last longer than the shortest time period t1 are saved multiple times in the ROM. Exactly how many times each system state is saved depends on its 5/16

6 factor relation to t1 (refer to Page 3). For example the first system state (Nr. 1) from Table 1.1 will be saved 20 times in the ROM (t5 = 20*t1), the second system state (Nr. 2) will be saved only 2 times (t2 = 2*t1). The following table clarifies this principle: Address Content 0 Nr. 1 1 Nr. 1 : : 19 Nr.1 20 Nr Nr Nr Nr. 3 : : Q4: How many memory locations (addresses) are needed to store all combinations indicated in Table 1.1 in a ROM? Q5: Encode the combinations given in Table 1.1 using the code from Table 2.2! Fill Table 2.3 with your results. Traffic - D C B A ROM-Value ROM-Addresses Light (DECIMAL / (Range: DECIMAL/ Output O HEXADEZIMAL) Count: HEXADEZIMAL) 7 O 6 O 5 O 4 O 3 O 2 O 1 O 0 ROM Input Decoder D 1 D 0 D 1 D 0 D 1 D 0 D 1 D / / / / / / / C / / / / / / / / / Table 2.3: Coding the different traffic-lights states 6/16

7 For flawless control of the traffic-light some additional circuitry is needed. It comprises of: a counter, which defines the addresses for the ROM; a circuit for recognizing the last state, which takes care of resetting the counter; a decoding circuit. 2.3 Programming the ROM A ROM is initially empty; it has no data stored in it. In order to load the required data into the ROM, we have to create a file in Intel-Hex-Format. Intel HEX is a file format for conveying binary information for applications like programming microcontrollers, EPROMs, and other kinds of chips. This format is a text file in which each line of data contains hexadecimal values. These values represent encoded sequence of data and their starting address. Each line of the Intel HEX file consists of six parts: Start code; Data length; Address; Record type; Data block; Checksum; Fig. 2.3 clarifies how a single line in an Intel-Hex-File is structured. Each square (field) represents 1 Byte or 8 bits. All bytes in a line (except for the Start code) are represented as ASCII-coded hexadecimal numbers. : n n n n n n n Start code Data length Address Data block Checksum Fig. 2.3: Structure of a line in Intel-Hex-File Every line begins with a Start code, a colon :. Data length specifies the number of bytes in the Data block of that line. The next two bytes (Address) represent the starting address in the memory where the data is going to be located. The Record type byte defines the type of data the line contains. Record type 00 stands for Data and 01 defines the last line in the file. The Data block contains the actual data we want to store. The size of the Data block varies with the size of the data we store. The last byte (Checksum) is a validation check on all bytes in the line except for the Start code. The Checksum byte is calculated the following way: sum up all the bytes in the line (without the Start code), calculate mod 256 of the sum and convert the result to 2 s complement. Given that the sum of all bytes for one line including the Checksum should yield out to zero. 7/16

8 It is extremely important to specify the end of the file. To do that leave an empty line after your last entry and add the following line afterwards: : FF This last line denotes the end of the file. The Data length is 00 since nothing is going to be stored, the Address is 0000 and the Record type is 01 meaning last line. Example: Data we want to store: Address we want to store the data in: 0101 Step1: convert the binary numbers into their equivalent hexadecimal values =61 16 and =5 16 Step2: define the Data length Since our data consists of only 7 bits ( ) we will need 1 Byte to store it. Therefore, we enter for Data length 01 (1 10 =1 16 ). Step3: enter Record type Record type would be 00 since we store data and this is not our last line. Step4: calculating the Checksum Sum up all Bytes in one line: Data Length Byte + Address Bytes + Record Type Byte + Data Bytes: The result of the summation is 67 (in hexadecimal!!!) Since the result is in hexadecimal, we have to convert it to decimal first i.e. 67 in hexadecimal equals 103 in decimal. Take the result from above (the decimal value 103) and apply modulo 256 operation to it 103 mod 256 = 103. Take the result from the modulo operation (which is a decimal value) and convert it to binary, i.e. 103 in decimal equals in binary. (The leading zero is extremely important. Do not forget to fill in as many as needed leading zeroes in order to create one whole Byte (8 bits). After that, when we convert the number, the leading zeroes will become ones meaning if we forget to fill in these leading zeroes we will end up with completely different number.) Take the binary number from the step above and find its 2 s complement. How to find 2 s complement: invert every single bit of the binary number ( inverted yields ) and then add 1 to it ( = ). Meaning the 2 s complement of the binary number is /16

9 Take the resulting 2 s complement ( ) and convert it to hexadecimal ( in binary equals 99 in hexadecimal). This is your checksum. With everything in check the corresponding line in the Intel-Hex-File would be: : Data length Address Record type Data block Checksum Q6: Write down the series of command lines (all together 16) required to load the ROM with appropriate data for the control of the decoders. Fill the missing values into the table. Address range Row given in Hex-Format Address 0-19 Address : A : AC Address : A5 Address Address :02001B00C0C063 :04001D DF Address 33 : D6 Address : C5 Address 39 : D2 9/16

10 2.4 Using a 4-bit counter for addressing the ROM Since we need to save each system state several times in the ROM and we have an overall of 16 systems states, we would need more than 16 addresses for sure. Therefore, we would need a counter, which counts up to a value greater than 16 i.e. a counter with more than 4 bits. With the help of the part we can construct an 8-bit counter. (Refer to the data sheet for the specification of the part) Q7: How is the part supposed to be connected, so that it functions as a binary counter? Q8: What purpose does Pin Nr. 1 serve? Q9: What purpose do Pins Nr. 3, 4, 10, 11 serve? Q10: Which pin in the part is used to reset the counter? Q11: Which pins serve as outputs? Which are the least significant and most significant pins? Q12: Up to which decimal number can an 8-bit counter count? Q13: How can we build an 8-bit counter from two parts? Hint: think about when the second part should start counting. 10/16

11 Q14: Complete the following figure (Fig. 2.4) to an 8-bit counter! Fig Circuit for loop detection in the counter Since an 8-bit counter has much higher counting capacity than the number of addresses we need, we should design a circuit, which resets the counter at a specific point in time. Q15: At which number (address) should the 8-bit counter be reset? Please give both the decimal and binary form of the number. (Take into account that the last defined address should remain for a whole cycle) 11/16

12 Q16: Sketch the circuit, which gives the reset signal to the 8-bit counter when the address from Q15 is reached! Q17: At which pins of the 8-bit counter should the output of the circuit from Q16 be connected? 2.6 Decoder circuit for controlling the traffic lights The outputs of the ROM (Table 2.3) encoded with the data in Table 2.2 provide only 2 input signals for each traffic-light. They are not sufficient to directly control the three lamps (Red, Yellow and Green) each traffic-light has. Therefore, a 2x3 decoder would be needed to decode the 2 inputs into the needed 3 output signals for the lamps. Thus, for each of the four trafficlights a decoder is placed. Fig. 2.5: Decoder 12/16

13 Q18: Sketch the circuit of the decoder given in Fig. 2.5! 3. Implementing the traffic-light system circuit Your assignment is to build a circuit, which will serve as a working real life traffic-light system. The tasks in this chapter will lead the creation process of the traffic light system. We will also get familiar with the functionality of ROM and how to use such devices in OrCAD. We begin with the creation of a new project as with any new assignment and setting up our work area for the final circuit. T1: Create a new Analog or Mixed A/D project named Lab3. Rename the default schematic folder SCEMATIC1 to TrafficLightSystem and the default schematic page PAGE1 to TrafficLightCircuit. These will be your traffic-light system s schematic page and schematic folder. The first steps into the creation of our traffic-light system begin with a counter. T2: Create a new schematic folder by right-click on the Project Design and name that new folder Counter. In it create a new schematic page by right-click on the schematic folder and name the new schematic page CounterCircuit. T3: Create the circuit for the traffic-light system counter from question Q14 (Fig. 2.4) in the CounterCircuit schematic page and place, and name the appropriate ports at the inputs and outputs. Hint: For input ports use PORTRIGHT-R and for output ports use PORTLEFT-L After we have defined the counter, it is time to build the circuit for the decoder, which will control the actual lights. 13/16

14 T4: Create a new schematic folder named Decoder. In it create a new schematic page and name it DecoderCircuit. T5: Build the circuit for the traffic-light system decoder in the DecoderCircuit schematic page. Place and name the appropriate ports at the inputs and outputs of the circuit. Now that we have all the circuits in place we have to assemble our traffic-light system. T6: Open the TrafficLightCircuit schematic page. In that page define a hierarchical block for the traffic-light system counter. Now define a hierarchical block, referring to the decoder, for each traffic-light in the system. Hint: To create multiple instances of the same hierarchical block give a different Reference for each one. The only component missing in our traffic-light system is the ROM. It has the same functionality as the 7-segment controller in Lab2, but instead of encoding the input from the counter, it outputs certain patterns on corresponding input signal. T7: Place a ROM32KX8break in the TrafficLightCircuit schematic page. You will find the ROM device in the BREAKOUT.OLB library The end result of the traffic-light system circuit in the TrafficLightCircuit schematic page should resemble Fig Fig /16

15 The outputs O0 to O7 of the ROM32KX8break are used to trigger each decoder corresponding to a traffic light. The counter s outputs Q1 to Q8 serve as inputs A0 to A7 to the ROM and define the address for the referred output. The inputs A8 to A14 should be set to low (logical 0), since they are not used in the addressing of the ROM. Hint: you can use Place Power $D_LO (Library: SOURCE.OLB) to define a permanent low signal. T8: Use the results from Q6 and generate an Intel-Hex file named ROM.txt Hint: use Notepad text editor to create and edit your Intel-Hex file. Now you have to tell the ROM which Intel-Hex file it should refer to when a simulation runs. T9: Select the ROM from the TrafficLightCircuit schematic page. Navigate to Edit PSpice Model. The OrCAD Model Editor with the ROM s model should open. Search for the entry: *+ FILE = Delete the asterisk * it comments the line out. Write the name of your Intel-Hex file in quotation marks after the equal sign =. In our case that would be: + FILE = ROM.txt Save and exit the Model Editor. The Intel-Hex file is referred to during simulation when PSPICE looks for the specified file in the corresponding simulation profile folder. T10: Create a simulation profile and save your project, so that OrCAD can generate the necessary folders. Go to your project folder (should be C:\ORCAD_DATA) and search for the simulation profile folder in it named Lab3-PSpiceFiles. Copy your Intel-Hex file (ROM.txt) to the simulation profile folder. T11: Insert the appropriate signal sources and simulate the circuit. Check if your traffic-light system outputs the correct signal. Q19: How should we set OE (DSBL) of the ROM, so that the stored content appears at the corresponding outputs? 15/16

16 Digital Components Symbol-Name Type-Number Library NOT AND 2-Input AND 3-Input NAND 2-Input NAND 3-Input NAND 4-Input OR 2-Input NOR 2-Input NOR 3-Input XOR JK-FF with CLR JK-FF with PRE/CLR JK-FF with CLR JK-FF with PRE/CLR D-FF with PRE/CLR D-FF D-TYPE REGISTER REGISTER FILE O.C. PRESETTABLE BINARY COUNTER BINARY COUNTER ROM Input, 8 Output 32 bytes memory 74LS173A 74ls LS A, 74293, ROM ls 7400 BREAKOUT 16/16

Introduction to FCE1

Universität Duisburg-Essen PRACTICAL TRAINING TO THE LECTURE Introduction to FCE1 Introduction to computer-aided design with OrCAD Name: First Name: Tutor: Matriculation-Number: Group-Number: Date: Prof.