Final Report

Electrical Engineering 552

This report details the present state of the Logic Analyzer project. A Logic Analyzer has been designed, constructed, and tested to meet certain specifications.

The Logic Analyzer uses Altera's UP1 Education board, specifically the EPF10K20RC240-4, along with minimal external hardware components in order to function correctly.

The project implements both data and control paths in order to successfully complete the project.

The functionality of the design contains three major components. The first is the pattern detector that detects a certain pattern and displays the corresponding waveform after it. Secondly, the IC tester is used to test certain 74HCxx series. Finally, the main menu is used (utilizing the VGA monitor) in order to scroll and choose between the two parts of the Logic Analyzer.

The Logic Analyzer serves two major purposes. The first of these functions is a 16-bit parallel pattern detector that captures data from eight to twelve bit buses containing up to 8 control lines. The second function of the Logic Analyzer is a static IC tester that is suitable for the 74HCxx series.

Structurally, the Logic Analyzer is composed of three main parts: the menu driver, the pattern detector and the IC tester. The menu driver acts as a controller. It enables either the pattern detector or the IC tester section when the appropriate menu selections are made. The user can drive the menu using the two push buttons devoted to the FLEX10K. One button will toggle between menu selections and another will select the mode driving the operation of the Logic Analyzer. The first menu will allow the user to select between the IC Test and pattern detector modes. If the IC Test mode is selected, the user will have to choose from one of the available 74HCxx devices. Upon pressing the selection button the IC will be statically tested. After testing the validity of the input and output pins, the functionality of the IC will be tested using input and output vector pairs.

If the user selects the "pattern detect" mode they are be asked to enter two 8-bit (high and low byte) values. The concatenation of these values acts as the "pattern" to detect. Upon pressing the start button, the pattern detector at every clock cycle compares the present inputs with the desired pattern. If the patterns match the data present then the next 16 samples which occur at every tenth clock cycle are recorded in RAM. This section is functional and tested on an internal counter.

The IC Tester allows the user to select a particular IC and test its input/output pairs. The results returned from testing an IC are on a per-pin basis. Each pin is checked to see if it functions properly as an input or output and whether or not it produces the correct test vector results. The two-way nature of the interfacing is achieved by placing a dissipation resistor between the output of the FPGA and the IC in question and connecting the input of the FPGA to the IC pin. A schematic is provided. The IC Tester has been tested using a 74HC00, 74HC04 and 74HC08. Limited chip space has prevented us from adding more examples to this report.

The pattern detector section loads data from the input port of the FPGA (16 bits) and compares this value to one selected by the user. If there is a match the next 16 clock cycles of 16 bit data are recorded into RAM. Once all the data is collected the VGA display is updated with the recorded digital values. This section will have no external hardware except for a ribbon cable for ease of connection. The pattern detector will be tested by implementing a 16 bit counter. After a pattern is encoded and detected the output should reveal the recognizable pattern. This section compiles and functions under static testing from DIP switches.

In order to implement the code within the project, it was decided to create a top-level structural component that puts together all of the other code. The following diagram displays the hierarchy for the Logic Analyzer. The top-level file display.vhd is used to connect all the sub-components together.

The following list describes the function of each of the components:

1. Display – Contains all of the structural information that connects all the entities together
2. pd_state_machine – Controls the pattern detector, one of the main functions of the logic analyzer
3. ic_tester_state_machine – Controls the testing of IC’s for the 74HCxx series
4. main_menu_state_machine – Cycles through all of the menus used on the VGA monitor
5. title – All of the visual display shown on the VGA monitor and the .mif files are stored here.
6. ram – Acts as a dual port clock (in & out) for 32 x 16 addresses.
7. data_loader – communication between hardware and software. It takes the information from the socket and brings it back to the FPGA so the result can be displayed on the monitor.
8. test_counter – test bench for the pattern detector
9. grid – The display for the grid itself is created in this file
10. syncgen – synchronize the VGA monitor in terms of vertical and horizontal sync
11. count_xy – count number of pixels on the 640 x 480 monitor
12. mem_mux – Selects the appropriate addresses for the ram
13. debouncer – This entity provides a debounced output from push button inputs

A VGA monitor was implemented in order to display the appropriate output of the Logic Analyzer.

The Altera board comes with the ability to interface with a VGA monitor using the EPF10K20 as a control module using a 15-pin D-sub connector.

A standard VGA monitor consists of a grid of pixels that can be divided into rows and columns. Any typical VGA monitor contains 480 rows with 640 pixels in each row. Each of these pixels is able to display various colors depending on the concentration of the red, blue and green signals. The monitor refreshes the screen in a way that is controlled by the horizontal and vertical synchronization signals. Refreshing begins in the top left of the monitor and works its way down to the bottom right of the monitor. Therefore we will be using a VGA driver that sends out the five aforementioned signals. The monitor writes to the screen by sending these signals when the screen is at the expected location. The various update times are as follows:

Also it is important to keep the synchronization of the signals accurate to ensure that the monitor can keep track of its current location. Thus we have to make note of the operating frequencies of the VGA display:

In order to implement the VGA interface, the files count_xy.vhd and syncgen.vhd are used to generate the synchronization and coordinates of the VGA monitor.

The main menu is implemented in order to scroll and choose either the pattern detector or the IC tester. In order to implement the main menu, the first step is to create the necessary fonts that will be displayed on the VGA monitor. A state machine is used to control when the text is shown on the screen. The following state machine describes the main menu:

This control path uses both push buttons in order to cycle through menus as well as the different parts of the logic analyzer. Initially, the following screen is displayed on the VGA monitor:

As the user pushes PB1, the menu will scroll through either the pattern detector or the IC tester. As soon as the usee selects PB2, the screen shifts to either of the following diagrams shown in figure 4, (dependent on which menu subset is chosen).

As soon as the button is pressed, the main menu state machine enters a "wait state". If both PB1 and PB2 are depressed in either of these screens, the diagram in figure 3 is shown once again.

In order to obtain an optimal design, minor changes were made to the initial design. Initially fewer states were used because the "release" of a button was not taken into account. Once it was shown that the debounced push buttons only worked roughly half the time, additional states were added to ensure the appropriate states were reached.

The number of logic cells for this piece of code was never a concern since this file only uses roughly 50. Also, the clock period is much less than the required 40 ns, therefore this is not something that was of major importance.

The largest roadblock was to ensure that the right address within title.vhd was pointed to, thus creating the appropriate text on the screen.

The pattern detector performs one of the two main functions of the Logic Analyzer Project: triggered logic level recording. This entails allowing the user to enter the trigger pattern, waiting for this trigger pattern to occur on some bus, and then recording the logic levels on those lines every 10 clock cycles. The pattern detector is an extremely (and often the only) useful device for debugging multiple control line logic. Figure 5 displays the state machine for the pattern detector.

The pattern detector consists of 4 main sections:

• control logic (pd_state_machine.vhd)
• storage (ram.vhd)
• trigger unit (data_loader.vhd)
• display drivers (title.vhd and grid.vhd)

The rest of this section will give a concise description of the above area in reverse order.

The display drivers control what is sent to the VGA display. The entities that control this process are title.vhd and grid.vhd. The file title.vhd contains all the functionality necessary to generate the backgrounds on the displays. The backgrounds include columns of numbers, borders and titles.

The file grid.vhd displays the selectable bit patterns and recorded logic levels. Once data is recorded into RAM and grid is enabled each bit correspond to on of the 16x16 blocks defined by grid.vhd. When the count location is within a display block the logic level present in RAM corresponding to that block is drawn. Due to the horizontal scanning nature of the VGA it is necessary to access one bit at a time from each word stored. The location in RAM is derived from the X and Y position of the counter. If the value is logically low a line is drawn at the bottom of the block and conversely if it is logically high it is drawn in the middle of the block. This spacing technique provides a very readable display.

During the pattern detectors’ process of initialization, it gathers from the 16-bit pattern from the user to trigger on. This pattern is a 16-bit wide binary pattern. The data_loader entity sits directly on the input port for the system being tested. When data_loader is enabled, it compares the bit pattern present on the input port with that desired by the user on each clock cycle. The data_loader will wait until this pattern is seen. Once the data is seen, the data loader will start to collect data from the input port and write it to the RAM. To achieve this, the data_loader will sequentially address each word in the RAM and generate a write pulse (write clock) to make the RAM store the value. After 16 words have been written, the data_loader signals to the controller that its’ job is done and that the RAM contains valid data.

The RAM is readable and writable through the same data and address ports. To allow multiple entities to read data from RAM the input is multiplexed. Data is written to RAM on the input clocks rising edge when the write enable is signaled. The write enable for the ram entity is controlled by the pd_stat_machine while the address and write clock is controlled by the data_loader. Data written to RAM when the write enables must be disabled and both the input and output clocks have rising edges.

The final piece for pattern detector system is the pd_state_machine that exhibits control over all the other sections of the pattern detector. The pd_state_machine, once enabled by the main_menu_state_machine, is prepared to accept the input of the trigger pattern on the DIP switches. The user selects the high byte of the trigger pattern desired and then the low. The values are recorded on the rising edge of the push button. After both bytes have been selected, one more button press is necessary to start the data acquisition process. The process is initialized by presenting the trigger byte to the data_loader and enabling it along with the write enable on the RAM. Once this process is started the pattern detector waits for the data_loader to signal its completion. When the data is completely recorded the pd_state_machine disables both the data_loader and the write enable to the RAM, and relinquishes control of the RAM to the grid entity. If the push button is fully depressed once more, the data_loader and ram are again enabled.

During the development process of the pattern detector several problems arose that made the pre-conceived notion of how was supposed operate and appear obsolete. The first of these was the vertical lines that should appear in the low to high transitions.

To some degree change there is a short period of time where the voltage is transitioning between the high and low values at each logic level. To display this, vertical edges would be required on the transitions. To achieve these two different methods were attempted. One was using charter-based display and the other was position based. For both methods the bit before and the bit in question were compared to one of four possible combinations (00,01,10,11) and an appropriate character was display. This method required the addition of 4 more characters. The second method tested for when the horizontal counter to lay directly on the transition lines and drew the line according the result of the XOR of the two bits.

The first method was slightly awkward and not implemented. There was an attempt to incorporate the second method, but it was decided that the display became cluttered. As a result neither method was applied in the final project.

Another early developmental path replaced the ram entity with the register-based logic. Originally it was thought that this would supply rapid access to data memory. This notion was not true and moreover led to unmanageable code. The register-based method was superceded by the two-port RAM method supplied in the LPM functions. It was faster and led to manageable code, while utilizing the resources already dedicated on the FLEX 10K series

The IC Tester performs one of the two main functions of the Logic Analyzer: specific integrated circuit testing. This entails allowing the user to select exactly which IC to test, and then performing the specified test on that specific IC. The user can test several chips very quickly and efficiently using the ZIF socket. The IC Tester is an extremely (and often the only) useful device for testing specific IC's. Figure 6 displays the state machine for the IC Tester.

The IC tester starts in a dummy state and is immediately transferred to the test vector states. The test vector states were states that the user would specify as inputs and outputs, and the IC Tester would check these vectors. This part wasn't implemented due to size restrictions. From the test vector states the user would push PB2 and move into the IC test states. The user can choose between the 74HC00, 74HC04, 74HC08, 74HC32, or the 74HC86.

The user selects the state by pushing PB2 and can see their new selection highlighted. Once the user is satisfied with the chip selection, PB1 is pressed to test the chip. Each state for the corresponding DUT contains data on that chip.

When the users presses PB1 to test the chip the state machine runs through a series of tests. These tests include examining if the inputs and outputs of the chip respond correctly as well as looking at some of the logic functionality of the chips. The XOR function performs these tests. The input data and the correct data are put through and Exclusive Or gate, and the results are evaluated. A user can select an IC using PB2, place the IC in the ZIF socket, and then press PB1 to test the IC. If the IC is performing correctly the user will see a series of Y's indicating that "YES" this pin is good.

The user can test many IC's in a row simply by depressing PB1, inserting a new chip in the ZIF socket, and then pressing PB1 again.

During the development process of the IC Tester several problems arose that were necessary to overcome. The first problem that we ran into was having too large a state machine. We received an error stating the state machine being only 256k. To reduce the state machine the test vectors were removed from the program.

The second problem that was detrimental to this program was logic cell consumption. When testing many bits using the XOR function, many logic cells are consumed in the process. The first approach to solving this problem was to check each bit individually using up to 16 if-else statements per test section on each chip. Again, this would increase the number of logic cells too high. Our second idea was to get rid of IC's to be tested. This reduced the total number of logic cells consumed, but failed to meet our specifications. A compromise between the two choices was to test the functionality of three of the chips, and test the input/output functionality of 5 chips. For the 2-bit NAND and AND chips we tested for inputs "00" and "11" only and for the 1-bit INVERTER chip we tested for input "0". By doing this we utilized our chip consumption to the fullest by testing 3 chips completely (input/output check and functionality check) and half-testing 2 more chips (input/output check only).

At one point over 600 logic cells were consumed and the final outcome resulted using 410 logic cells for this file.

The file title.vhd is used as a display driver in order to tell what is sent onto the screen. It utilizes the LPM ROM function in order to store characters on the screen. The .mif file contains the address and corresponding information located at each address. The mif files used for this project can be seen in Appendix D. The following code is taken from title.vhd and displays the method used to display fonts on the screen.

If main menu is enable and the screen is refreshing at a certain point within the screen then "Main Menu" will be displayed at the corresponding coordinates. The addressing for columns and rows in regards to font is split into 16 bit chunks. This means that a 640 x 480 screen is represented as a grid with 40 columns and 30 rows.

Since the Altera push buttons are not initially debounced, it is necessary to implement code to debounce the push buttons. A simple counter is used. This code can be seen in Appendix C.

Since our project contains minimal hardware, the design and testing for the hardware specifically went smoothly. The ZIF socket is connected to the resistor array and to specific pins of the FPGA. The hardware has been simply tested by using a multi-meter and testing the I/O depending on the gate. These values correspond to the value of the IC tester as displayed on the VGA monitor.

In order to configure a connection between the Zif socket and the flex chip, the configuration shown in figure 7 was used.

This arrangement serves dual purposes. First of all, it prevents large amounts of currents from the DUT to the Flex chip (as a direct connection can result in). Therefore there is protection to the pins from a chip that can drive potentially large amounts of currents. Secondly, it allows us to tell whether the pin of the ZIF socket is either an input or output. If it is an output then it will drive and the input of the Altera Board will be logic low. If it is an input then the output of the Altera Board will drive the pin and the input will be a logic high.

A schematic of the hardware can be seen in Appendix B.

There are two concerns in terms of area on the chip: logic cells and the embedded array blocks. The limiting factor for area for the logic analyzer is the embedded array blocks Since we are generating a lot of characters and lines on a VGA monitor, the .mif files that are used to store letters and numbers take up space. The following table displays the number of logic cells used to complete the project. It is also important to note that the "Global Project Synthesis " under the assign menu was set to optimize area rather than speed initially. This is a trade-off that is worthwhile for the Logic Analyzer.

The number of embedded array blocks that are used are primarily taken up by title.vhd. The actual number is:

The following information is taken from the registered performance of the top-level file display.vhd:

Clock period: 60.5 ns

Frequency: 16.52 MHz

In order to ensure proper functionality of the project a clock period of 40 ns is needed. In order to compromise between area and speed, the slide bar under "Global Project Synthesis" in Altera is varied to achieve the necessary clock period, but still try to optimize in terms of area. All tests have ensured correct functionality of the chip, therefore speed has not been a factor thus far.

The following table describes the clock period and frequency for the major entities within the chip.

Since the critical path for the ic_tester_state_machine is the only file that puts the clock above the 40 ns, a more in depth look was taken to identify the cause of the larger delay. Since this is a larger file and has a lot of test cases, the delay is increased. However, this is not a worry for the logic analyzer because the critical paths for this file show that the states are user dependent. Therefore, there is no worry about the logic analyzer not functioning properly.

In order to verify proper function of our project, it is important to have test cases. The most efficient way to test is a bottom-up approach. If the lower level files are ensured to function correctly, then any error that occurs at a higher level is easier to detect. All simulations are provided is Appendix E.

For the logic analyzer, the following list describes the tests used to describe the lower level (smaller) files:

1. mem_mux : a two input 5 bit mux used to select the origin of the RAM address data
2. debouncer: simulation waveforms along with increased the delay period until it was aesthetically pleasing.
3. count_xy: simulation waveforms to ensure the horizontal rows are counted and then vertical columns are instantiated after a row is completed
4. syncgen: referenced from dice race. Putting something on a VGA monitor (such as what was completed for fun lab6) proved the functionality of this file.
5. Grid: was created and tested alongside a VGA monitor
6. Ram : the lpm RAM provided with the Altera software, it is a dual port syncronous RAM.
7. Data_loader : triggering on a vector presented by the pattern detector state machine the module transfers data regularly to the RAM

Now that the lower levels are finished, test cases have to be created in order to test the higher level files. The most efficient method to test title.vhd was work alongside a monitor. This is due to inability to simulate waveforms with relative ease with any of the signals that depend on the VGA (to large of a time scale). Each address referenced certain characters as per the .mif file (ic_test.mif) burned into the ROM. Tiny errors, such as referencing the incorrect line on the screen, or pointing to the wrong address in the mif file.

Altera’s waveform editor tested the functionality of the design of the main menu. Since this file depends on certain state and what is enabled, it is easy to find errors in the simulations. For instance, when a button is pushed, the next state was incorrect sometimes. An additional state for when the button is released solved the problem.

The Ic_tester_state_machine is implemented when the user selects the IC tester from the main menu. In this entity the user can scroll through the various different IC selections. When the user highlights the specified IC the user can then press a push-button, which will run the IC Tester.

The following two test were performed for the IC tester:

1. The tester checks whether the pins on the IC are inputs or outputs.
2. The tester does a functionality test of the chip.

In the functionality test section the tester runs through a set of test cases specified for the designated IC that it is testing i.e. If we were testing a 2-input and gate, we would need to test for inputs 00, 01, 10 and 11.

For the pattern detector three simulations are provided: RAM, Data Loader and State Machine. These are presented separately because of the detail necessary to explain them fully.

The pattern detector state machine is a synchronous process, which is guided by user button presses. The first 5 state is used to load in the high and the low bytes of the pattern to be detected. Each state is concerned with one edge of the button press. Once both bytes are received the combined vector is presented to the data loader through an external port. This will be the pattern that the data loader will look for once properly enable.

Enable the data loader occurs after the user has depressed the button for a third time starting the measurements. The data loader is fully enables by an enable line, selecting the RAM as writable and directing the memory address mux to select the data loaders address to its address port.

When the data loader has collected all data it signals the pattern detector state machine by raising the data acquisition complete flag. The data acquisition cycle is complete by resetting the data loader for the next pattern and display the data in memory.

The data loader when enabled has five possible states. The first state waits until the desired pattern is detected. Once it is, data present on the input port is loaded into the RAM via a counter that holds the memory address. Once data collection is complete the pattern detect state machine is signaled. Upon reset, the address counter is returned to zero.

The final interesting element in the pattern detector is the RAM. The simulation is presented here to high light an apparent discrepancy (in the authors’ eyes). The simulation shows data first being written to RAM and then being read. To read the RAM properly both the write and the read clock need to be active.

This is the top-level entity it instantiated 3 state machines, the main menu, the pattern detector and the IC tester. To demonstrate the complete functionality simulations were performed to take the system through it's various states.

It is important to note that an unsuccessful attempt at creating a test bench was attempted for one or two of the files. Since Altera cannot be used to implement test benches, Mentor Graphics became the obvious replacement. However, QHSIM does not like the LPM ROM functions therefore we could not find any way around it.

A test counter was created to test the pattern detector in Altera and this was used as a "pseudo-test bench".

The Logic Analyzer is a powerful tool for the design and debugging of digital hardware. Its wide 16-bit input port can be configured to trigger on any combination of data allowing a high level of flexibility when trying to capture elusive faults. The Logic Analyzer can store up to 16 samples of the input port presenting the user with a wide time period of measurement. Sampling interval occurs at one-tenth the input clock rate. This allows the user to alter the timing requirement of the Logic Analyzer to suit their own needs.

The Logic Analyzer also has the ability to test commonly used ICs. The 74HC00, 74HC04 and 74HC08 are presently implemented. The tests performed by the Logic Analyzer are strict enough to guaranty the performance and functionality of these ICs.

The Logic Analyzer results are all displayed on a generic VGA monitor. The Logic Analyzer output is large and easy to read making it a highly flexible tool

The following information was obtained using version 9.01 of Max+II.

Maximum Clock Period:

The following information displays the usage of the cells of the EPF10K20RC240-4 due to the logic analyzer:

Total dedicated input pins used: 1/6 ( 16%)

Total I/O pins used: 65/183 ( 35%)

Total logic cells used: 1082/1152 ( 93%)

Total embedded cells used: 38/48 ( 79%)

Total EABs used: 5/6 ( 83%)

Average fan-in: 3.41/4 ( 85%)

Total fan-in: 3691/4608 ( 80%)

Total input pins required: 27

Total output pins required: 39

Total logic cells required: 1082

Total flipflops required: 381

Synthesized logic cells: 449/1152 ( 38%)

The following list of references has and will be used in order to complete the final design: