K. Ganchev F. He S. Finney Friday, February 9th, 2001 CS23/E22 Laboratory Assignment #1 ABSTRACT In this laboratory experiment we designed, programmed, and implemented device able to control a bank of 8 light-emitting diodes. The final product was a device that consisted of an accumulator register, an instruction register, a light register, a program counter, and memory space for a ROM program. The initial project was compiled, simulated, and programmed onto a Altera MAX EPM7128SLC84-6 programmable chip board. A second device with expanded capabilities (on the fly programming) was also designed, but due to space restrictions was implemented on the Altera board's FLEX EPF10K20RC240-3 chip. DESCRIPTION The actual design of our circuit was specified to some extent in the lab, but that specification left some room for flexibility, mainly in the extensions and in the program itself. First let us describe the part of the circuit not involving the program memory (since that is the part that has the most variation - see below.) The steps that I describe do not happen sequentially, but in parallel; this description is just a guide as to what happens and how it works. On the rising edge of the clock, a new instruction is loaded from the program memory into the instruction register. The value in the program counter is asynchronously updated to the address of the next instruction. The accumulator executes the instruction (on the rising edge of the clock), that was selected using the three selector inputs. The light register also executes its instruction, and the circuit waits for the next clock cycle. The intent of this circuit is to be able to execute some rudimentary programs to control 8 LEDs connected to the outputs of the circuit. The programs are stored either on a ROM, or in the extended version that we were not able to test in hardware the user can program the memory. The instruction register contains only 5 data bits, so it requires 2 data cycles to update the accumulator register and the light register (each of which are 8 bit registers). An example program is the counting program, that uses the accumulator register's increment operator to count in binary using the lights. It does not involve a case statement and always returns: "010001000000000" The bits are written so that bit 0 is farthest right. The first 4 bits are the address of the next instruction (0000 - this is not used in such a simple program). The next 5 bits are the data bits.. these are not used either. Bits 9 and 10 are used to give an instruction to the light register. In this case the instruction is 01 which means load a new value from the accumulator. The next 3 bits are the accumulator instruction bits, in this case 100, meaning increment your current value. The last bit is the conditional jump bit, again this program does not jump conditionally, in fact it does not use the address bits at all. To write this more simply: program then instructs the accumulator to increment its value at every clock rising edge and also instructs the light register to load a new value on every rising edge of the clock. Our design process was guided by the lab instructions. We implemented the various parts as instructed, testing each component and then built the circuit by connecting the components in the graphical editor. After this, we started to do the extensions. We discussed how each should work and then implemented it (some of the extensions were two people at the computer coding, the others were one person doing the actual implementation and debugging.) The design process is sort of trivial in this case, since most of the planning was done for us. EXTENSIONS o We wrote a single line program for our first working model that used the accumulator to increment itself, and subsequently feed that value to the light register, and at the same time the light register was instructed to use the accumulator value to light the LED's. The result: a program that could use the LED's to count to 255 in binary. o We expanded the accumuilator and light registers to 8 bits. the result of this was the ability to count to 255 instead of 127 in the previous extension. o We added one additional input to our circuit: a pause button. The pause button basically intercepts the clock cycles, keeping the chip in a single state, which could prove somewhat useful for someone testing and debugging another feature. o We designed the circuit so that the ROM could be programmed on the fly. (See separate attachment on this) o The entirety of the project was written in VHDL. DETAILS REGARDING ON-THE-FLY PROGRAMMING This circuit has the ability to be programmed with up to 16 lines of instruction code in its memory. To program it, 4 new inputs were added to the overal circuit. They are: o program_address o program_cmd o program_hilo_bit o program_am_i_being program_address is a four bit representation of the address to which the program shall be written (2^4 == 16 possible locations) program_cmd is actually in this representation a group of 8 configurable jumpers, but on the design level is one object, which could be interfaced with something else not requiring separate inputs for each bit to be set. program_hilo_bit instructs the circuit whether to write to the low 8 bits of the program or the high 7 bits. This was our solution to a shear lack of enough inputs to set the entire instruction at once. Another possible solution we were considering involved a single bit toggle and to buttons to shift the command left and right to allow for the entire line to be set. However, this would have required some form of visual output for confirmation if it were to be at all user friendly and that would have required more time than was available for the lab. program_am_i_being is the only input actually watched in any processes of the circuit. It is used to inform the circuit that a new piece of program code is being entered into memory, and the circuit responds accordingly. LAB QUESTIONS Q1: What capabilities does your circuit share with a general purpose computer? The first point to clarify is that there are several versions of our circuit. This is significant because there is one version that has a ROM program memory, while there is another version that has a programmable memory. We were not able to test the programmable version on a physical PLA because no board was available with a functioning FLEX chip. So We discuss the features of the ROM version and then the extra features of the programmable version. There are some features that our circuit has that a modern computer also has, only to a far larger degree. Our circuit has a limited input/output capability, in the form of pause and reset buttons (the main input of computers running two major operating systems), and output in the form of flashing LEDs. Our circuit also has some way of storing a state in the form of several registers. Our circuit can execute conditional expressions (skipping an instruction in one case and not in another), as well as simple arithmetic operations (increment and decrement). This ability can be extended further depending on the program in the ROM, where it is possible to implement simple loops. The main difference between our circuit and a general purpose computer is in scale, extendibility, speed, connectivity, and programmability. Another very important difference is in that our circuit stores its program in a separate place that the data on which the program operates (even though the only way to change that data is to reset the circuit). This is known as a Harvard Architecture, whereas most general purpose computers use a von Neumann architecture (store their program and their data in the same memory). The programmable memory circuit has the ability to receive data from the user (when being programmed), and also can be said to have better input characteristics. Q2: What were the major problems you encountered and how did you solve them? Most of the problems we encountered were not conceptually complicated things, they were bugs, problems with using Altera, or not knowing how to do something in Altera or VHDL. These are not of considerable interest, but for the sake of completeness, we include a brief description of the more noteable ones. The first obstacle to overcome was learning VHDL (before we knew that it would be introduced in class). This involved online tutorials and general purpose code modification. The first major bug arose when in the graphical editor, connecting busses Kuzman accidentally reversed the labelling of one of the ends (causing the compiler to ignore the clock as an input). The second obstacle was converting the entire circuit to VHDL. The problem was that the error messages were not descriptive enough to narrow the problem down (and there was more than one problem). The solution was to build the circuit up one component at a time, and connect the inputs that were currently non-existent to inputs in the PORT statement. Other than that there have been a few technical difficulties with the boards. Q3: What were the relative strengths and weaknesses of designing using the graphical editor versus VHDL? There are a number of things to consider when answering this question. It would be incredibly simple to say that VHDL just blows the graphical editor completely away and there is no contest. I am inclined to take this view, but I realize that it is not entirely correct. The strengths of VHDL the ease of designing a circuit that does something in particular without having to plan out exactly how it is implemented. Another of the strengths of VHDL over the graphical editor is an issue of legibility. When one person implemented one part of the project using VHDL it was a quick task to explain to the partners what it did and how it works (even before we all knew VHDL). Explaining and debugging a graphical editor segment is a far more tedious task. In a sence you don't know where to start, and the organization is not as obvious. The strength of the graphical editor would have to be its relative closeness to the logical structure of the final circuit. It does not allow as great a level of abstraction, so the designer sees how it is that a particular piece of hardware wokrks. The second strength is the intuitive nature of the graphical editor. It is easy to see what you are doing without being taught. We will not discuss issues that might make VHDL better than the graphical editor that we have not run into (like portability), since we do not have enough experience to judge. Q4: What was your testing plan, and how did your circut fare? Did you test the capabilities of the circuit? If not, what parts were not fully tested? Our testing plan consisted of three seperate phases: compilation, simulation, and run-time testing. Compilation testing generally consisted of head scratching, frustration, screaming, pressing of the face against the screen, and at one point a voodoo shaman was called in--all because of Altera and the ourselves having what could only be characterized as a personality conflict and a communication breakdown at the same time. To help avoid problems, or at least deal with them easier, we built on a strictly module based scheme, so that individual components could be compiled and tested to find errors more quickly. Simulation was the next step of testing, and could be implemented very easily do the particular approach we took as a team. Basically, we could have two members of the group working on the next module already while one person verified that a previous module performed as expected. Run-time testing was the final step, and usually by this point any bugs in the system had already been flushed out. That's not to say that it worked perfectly on the first try, of course. Actually, our circuit didn't perform as expected on our first trial run only because of a misunderstanding in the actually programming of the instruction code. We were able to determine this because of our previous stringent testing of components, and it saved us more time than any of us even want to consider imagining. As far as we know, the entire circuit has been tested and verified on a component by component basis, and performs exactly as expected with zero abnormalities. WHAT WE LEARNED AND SUGGESTIONS In terms of what we learned from the lab, we can divide the things we learned into two categories: the specific and the abstract. A couple of examples of specific things are VHDL syntax and how to use Altera. More importantly we learned how to go about designing a simple circuit, both graphically and using VHDL. We got a chance to make an electronic device that shares some features with the general purpose computer. One of the things that made the lab a little intimidating was the lack of "Altera how-tos" and also to an extent the fact that we were only introduced to VHDL a while after we started the lab. This made the task of doing the lab more intimidating, and in this way more difficult without being much more instructive.