This document was uploaded by user and they confirmed that they have the permission to share
it. If you are author or own the copyright of this book, please report to us by using this DMCA
report form. Report DMCA
Specifications . . . . . . . . Deliverables . . . . . . . . . Old Specifications . . . . . Voltage Levels of Interfaces
. . . .
. . . .
List of Figures
3
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 4 4 5
Acknowledgment Dr. William Rison Project mentor Dr. Robert Bond Advice concerning project management and advice concerning design for testability John Battles Advice concerning design of programmable logic programs for easier in-circuit testing
4
1. LED blinker must connect to a PC/XT or PC/AT ISA bus 2. Drivers must be provided for Linux 2.4 or for RTLinux 3. A convenient user interface must be wrapped around the drivers 4. Costs should remain under $200 Table 1: Specifications 1. A report discussing the implementation of a complete blinking LED system 2. Printed circuit board drawings for the system 3. All source code for drivers, user interface, and programmable logic devices Table 2: Deliverables
1
Introduction
The original goal of this project was to create a multi-channel digital oscilloscope, as described in §2. Due to many constraints, the project was trimmed down to an LED blinker described in §3. The specifications for the LED blinker are presented in Table 1. The deliverables for this project are presented in Table 2. The specifications for the digital oscilloscope are presented in Table 3. 1. Oscilloscope will provide 16 input channels. Two channels will be reserved for self calibration purposes. 2. Oscilloscope will sample up to 10 MSPS. 3. Oscilloscope inputs can vary across ±10 V. 4. Linux drivers must be provided. Table 3: Old Specifications
5
Component ISA Bus MAX7000SLC ACEX 1K 74ACT541 AD9240 A/D converter AD408 Mux
min VIH 2.0 V 2.0 V 1.7 V 2.0 V 3.5 V 2.4 V
min VOH 2.4 V 2.4 V 2.4 V 3.8 V 2.4 V (@500 µA) 4.5 V (@50 µA) n/a
Table 4: Voltage Levels of Interfaces
2 2.1
The Original Plan: Digital Oscilloscope Theory of Operation
The digital oscilloscope provides 16 analog inputs. Each input has protection circuitry to prevent problems with input voltages that go outside the specs mention in Table 3. The signals are then fed to analog muxes. The output of the muxes are fed to a differential amplifier. The output of the differential amplifier is fed to a 10 MSPS A/D converter. An ACEX 1K FPGA from Altera is used to coordinate all the digital electronics. Some of the functions performed by the FPGA are selecting of mux channels, sending a clock to the A/D converter, reading data from the A/D converter into RAM, accepting programmed I/O commands from the ISA bus, and dumping on-board RAM via DMA. The ACEX 1K is RAM based, and thus needs to be programmed every time it is powered on. A small PLD, an Altera MAX7032, is used to allow the ISA bus to control the JTAG pins on the ACEX. The MAX7032 is based on non-volatile memory, so it only needs to be programmed once. The memory blocks of the ACEX 1k is used as on-board RAM used to stored samples from the A/D converter. This memory is very limited however, and so it cannot store a complete waveform. To solve this problem, a program was written that takes pieces of a complete waveform and figures out how to connect the pieces to reconstruct the complete waveform. This technique only works when the signal being sampled is periodic. A lot of care was put into the printed circuit layout. The PCB features a fairly solid ground plane. Any breaks in the ground plane are kept fairly short, especially when those breaks cut underneath signal wires on the top layer. This is important because it minimizes the size of inductive loops formed by signal paths and the signal return paths. The signal return paths are free to flow in the ground plane directly beneath the signal path, except when the ground plane is broken underneath a signal path. Numerous test points are located on the PCB to allow convenient testing and rewiring. Every integrated circuit was surrounded by vias that could fit
6
.100” headers. If necessary, it is possible to cut traces on the PCB and then place populate the holes with headers and do wirewrapping to rewire the cut traces. The printed circuit is organized into functional blocks. There are blocks for the power supply, input muxes, differential amplifier, A/D converter, and programmable logic chips. It is easy to comprehend, by visual inspection, the general flow of signals through the circuit board. The is one shortcoming with the printed circuit board drawing: there were too few labels. Additional labels could indicate the pin numberings on chips. Because these labels were missing, it is necessary to count pins by hand when debugging the board. The PCB does not have a card edge connector to plug directly into the ISA bus. A separate prototype perf board with a card edge connector is used. These two boards are connected using ribbon cable and a 64 pin IDC receptacle.
2.2
Conclusions
The original plan was zealous. The plan was not fulfilled in part due to poor project management, described in §4.1, and also in part due to inexperience of the team members involved. This was not a failure though: we all tested our limits and gained more experience and knowledge.
3 3.1
The Modified Plan: LED Blinker Theory of Operation
The LED blinkers is an ISA card that provides an addressable register. The output of this register is connected to a single LED. By writing a value, using Intel x86 inb and outb instructions, the LED can be switched on or off. The code for Altera chip is provided in Appendix A. The wiring information and PCB layout was borrowed from the oscilloscope project and can be viewed in Appendix B. The Linux driver (see Appendix C) makes this I/O port appear as a character device file. User space programs can open this device file and write ‘1’ or ‘0’ characters into it to turn the LED on and off. A Makefile file is provided in the Appendix. To build the drivers, type ‘make’. To load the device driver, type ‘make reload’. To create the device file, type ‘make mknod’. The device file will be /dev/blinker. To run a simple test, run ‘make runtest’, which will execute test.sh. User interface possibilities are explored by putting this device on the internet, as described in the next section.
3.2
Connecting the LED to the Internet
TCP port 5555 is setup in listen mode. Any data written to this port is piped data directly to /dev/blinker. A web CGI application accepts user input 7
through an HTML form. When the user submits a form, the CGI script connects to port 5555 to control the LED. Since the computer running the LED blinker is different from the computer running the web server, OpenSSH is used for port tunneling. To setup the TCP port, a prepackaged system called pipes is used. This package can be obtained from http://bisqwit.iki.fi/source/pipes.html. To create the TCP port, type ‘plis 5555 -i ’cat > /dev/blinker’’. The TCP port can be quickly tested using a telnet client: telnet localhost 5555 Trying 127.0.0.1... Connected to localhost. Escape character is ’^]’. 0 1 0 1 OpenSSH can be used to tunnel data by typing a command such as ‘ssh -R 5555:localhost:5555 infohost.nmt.edu’. This will forward all data from port 5555 on infohost.nmt.edu to port 5555 on the local machine.
3.3
Online GUI
The purpose of the Online Graphical User Interface proposal is to allow for easily configurable GUI using the well-documented, established web-standard format, xhtml. The user interface is an xhtml web form generated using a single python script. The page can be broken into three distinct sections: the header, the form, and the response. User interface is divided into two components: user-interface communication (the web form) and the interface-device communication system. The code for all of this can be found in Appendix D. The OGUI is a dynamically created web page, which takes advantage of the CGI capabilities of Python. The Python script used to write the different sections of web page are predefined in separate plain-text files. The different files each contain portions of w3c-compliant xhtml. However, because the files are not truly xhtml files, in-and-of themselves, they have been appended with the .txt file-type designator. The three different sections of xhtml code are described below. The file header.txt is a generic heading file for the webpage. It contains no real special information. It requires no special encoding. The data for the header is contained in the plain-text file, ”header.txt”. The header is a section of generic, preformatted xhtml, with simple arguments added for ease of customizability. The file form.txt is the most important part of the user interface. Like the header, it is a predefined selection of xhtml with %s arguments added to
8
allow customizability. In the case of the form, the default values of the form are returned from the cgi script to reflect the previous selection. The intent of data.txt is to expose the current status of the device. However, the ISA device was not designed to allow reading of its current state. Therefore, the information is simulated, using the previous input data. If communication with the actual device is correct, the board response should be identical to the last submitted values. Aside from writing the xhtml code, the purpose of form.py is to act as the communication link between the user and the device. Both the web form and the communication system are designed for simplicity and general understandability. Two methods were attempted for communication with the device. The first plan, telnet communication, failed because of the nature of the telnet program. The second attempt was to communicate directly with the device, using Sockets. The telnet communication system (the SendDataTelnet function in form.py) is quite self-explanatory. Telnet is opened and pointed to port 5555 (the arbitrarily chosen TCP port of the ssh tunnel between the webserver and the computer with the actual device). Depending on the user-requested duty cycle, either a ‘0’ or a ‘1’ is written to the telnet terminal. Unfortunately, telnet, which is designed for interactive use, does not handle communication through pipes (i.e. popen). Thus, the telnet method of communication had to be abandoned in favor of a more script-friendly communication method. The sockets communication system (the SendDataSocket function in form.py) was very straight forward. Python includes ‘socket’ as a standard library module. This reduced communication to opening a socket and sending a message (either a ‘1’ or a ‘0’) to the device. The result is a rather robust communication system that is as simple as it is effective. The Online Graphic User Interface, although quite simplistic and lacking in functionality, is a very nice example of creating a multi-level interface. Each component may be readily modified without much affecting the rest of the interface. Also, given the use of Python and xhtml, the interface can be easily expanded if needed. This system will definitely be used as the basis for the Oscilloscope UI, when that project is resumed.
3.4
Testing Procedures
1. Plug ISA card into ISA bus, without jumper to our main board. Does computer boot? If not, then there is a defect in the ISA card. 2. Before populating main board, attach it to ISA card plugged in to ISA bus? If not, then there is a defect in the PCB design or the manufacturer did not meet spec. 3. Load program into Altera 7064 chip. Have testing station apply input stimulus. Does Altera chip pass test? If not, then the chip is either fried or the firmware loaded into the chip does not provide a reset function. A reset function is imperative for testing and it must put every state element into a known state. 9
4. Insert Altera 7064 chip. Does computer boot? 5. Read/write I/O ports on the Altera chip. Does the system respond as expected? Write multiple Altera programs to assist with testing: 1. Set all I/O to high impedance. 2. Turn an LED on when reset is applied. 3. Turn an LED off when reset is applied. 4. Allow read/write of a register mapped to some I/O address.
4
Future Improvements
Some of the guidelines were written when we discovered problems as we were putting the system together. Good project management should be very helpful in future projects.
4.1
Project Management
If it isn’t written down, it didn’t happen. When managing projects in the future, this guidelines should be followed: team members need to sign statements of work. The statement of work signed by individual team members should consist of the following: 1. Statement of what work will be done 2. Date by which the work will be completed 3. Any risks that the signer is concerned about that may cause the work to be unfulfilled 4. A signature from the person doing the work Anyone assuming leadership among the team cannot tell team members what to do and how long it will take. The team members must tell the leader how much time they need in order to complete certain tasks. For example, if someone is going to draw a printed circuit board, then they must give specify a time when they will be finished. A written statement of work must then be drawn up for the printed circuit board drawing, as described above. Time management can also be improved. Here are some guidelines for planning time: 1. Be prepared for more than one iteration of a design. Plan for at least two printed circuit boards revisions. This provides time to become acquainted with the PCB vendor’s manufacturing capabilities. It also provides a chance to iron out many mistakes in the design, such as wrong footprints or incorrect hole sizes. 10
4.2
Design Practices
For the Altera code, the following requirements must be met: 1. Provide a reset. All state elements must enter a known state when reset is applied. This is necessary for testing. It is very hard to test a programmable logic device if you cannot force it into a known state and then apply stimulus to progress through other states. 2. Make it possible to route all state machine bits to pins on the chip. This is more beneficial to complex designs than it is to simple designs. Circuit design practices: 1. Connect VCC through a resistor. Thus shorts in the circuit can be detected by measuring the voltage drop across this resistor. 2. Connect control signals such as tristate enables or reset signals through resistors. This permits these signals to be manually controlled for purposes of test. PCB design practices: 1. Double check all footprints with datasheets directly from the manufacturer. 2. Ensure all hole diameters will allow easy and secure fitting of through hole components. 3. Use DRC to ensure you meet manufacturing specifications. 4. Use netlists to help ensure correct wiring of the board. 5. When routing, simplify routing by taking advantage of the generic-ness of programmable logic I/O pins and any other generic circuit blocks. Reassign pins as necessary to mitigate tracks crossing each. 6. Wire all integrated circuits (and other high pin density parts, such as connectors) to vias that can hold dual row .100” headers. This permits easier testing and rewiring of the board. 7. Provide a solid ground plane. Keep breaks short, especially when the breaks run perpendicularly beneath other signals. This minimizes inductive loops. Inductive loops increase interference and susceptibility to interference as well as increase the rise times of signals. 8. Put tick marks and/or labels next to pins and pads. This makes it easier to count them and easier to debug. 9. Place bypass capacitors near chips that require transient current supplies. Connections to bypass capacitors should be provided through short wiring.
PROCESS ( databus, dataIn, ie ) BEGIN IF ie = ’0’ THEN databus <= (OTHERS => ’Z’); dataOut <= databus; ELSE databus <= dataIn; dataOut <= (OTHERS => ’Z’); END IF; END PROCESS iep; END databus;
END Decoder; ARCHITECTURE decoder OF Decoder IS BEGIN PROCESS ( aen, address ) BEGIN w <= NOT iow; r <= NOT ior; data <= (OTHERS => ’Z’); IF aen = ’1’ THEN IF address = b"1001000000" THEN clk_counter <= ’1’; ELSE clk_counter <= ’0’; END IF; END IF; END PROCESS; END decoder;
A.4 1 2 3 4 5 6 7 8
Decoder.vhd
Encoder.vhd
LIBRARY ieee; USE ieee.std_logic_1164.all; ENTITY Encoder IS PORT ( input
:IN std_logic_vector(7 DOWNTO 0);
13
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
output END Encoder;
ARCHITECTURE encoder OF Encoder IS BEGIN PROCESS ( input ) BEGIN IF input >= x"00" AND input < x"F0" THEN output <= ’0’; ELSIF input >= x"F0" THEN output <= ’1’; END IF; END PROCESS; END encoder;
ARCHITECTURE register8 OF Register8 IS BEGIN PROCESS ( clk, en, d, reset ) BEGIN IF reset = ’1’ THEN r <= ’1’; ELSIF clk ’EVENT AND clk = ’0’ THEN IF en = ’1’ THEN IF d >= x"00" AND d < x"C3" THEN r <= ’0’; ELSE r <= ’1’; 14
28 29 30 31 32
END IF; END IF; END IF; END PROCESS; END register8;