file: $hw4/chiptest.txt

                       CHIP TESTING SOFTWARE

In this project you will build and exercise a program that turns the
SAPC into a machine to test chips. 

The part of the code that's the same for all chips lives in
chiptest.c.  Chip specific code is in _chip.c files, one for each kind
of chip you wish to test.  The makefile compiles the chiptest.c and
whatever_chip.c file(s) and links them to produce a .lnx file to download
to the SAPC. When that program is run it first tells the technician how to
connect the chip to be tested to the SAPC parallel port, then loops on
all possible combinations of 0's and 1's on the input pins.  For each
combination it asserts the proper voltages via LPT1's PDR, reads the chip
output via its PSR and compares those values with what the _chip.c file
says they should be. It reports any errors in a useful way.

I could write formal specifications for the _chip.c file, but haven't.
Instead I've provided a commented sample, ls00_chip.c, specifying what
chiptest needs to know to test (part of) an LS00 quad nand gate chip.
I'm not claiming my setup is the best possible way to do it--you can
suggest other ways in your discussion.  Note the basic idea that all
chip information/functionality necessary for chiptest is in struct chip.
Note also that the TT array is not in struct chip, because it is just
subordinate to the softchip function.  

There's also a stub chiptest.c, and a Makefile.  The command

make chiptest.lnx

produces chiptest.lnx for downloading. If you had the real chiptest.c
running chiptest.lnx on the SAPC (before you add another chip, see part
3 below) would produce this output:

-----------------------------------------------------------------------
Chip tester for chip(s):
0-- LS00/2

Enter chip to test: 0

Testing LS00/2 chip (gates 1 and 2 of LS00)

Connection instructions:

VCC to chip pins: 14 

GND to chip pins: 7 

LPT1 pin:	chip pin:
2		1
3		2
4		4
5		5
15		3
13		6

<CR> when ready: 

... report any chip errors ...

-----------------------------------------------------------------------


Development hint: Even though you can test a chip only with code
running on an SAPC, you can do a lot of your chiptest.c development on
UNIX -- all the loop construction and much of the debugging -- just
about everything but asserting voltages to LPT1 and reading them
from there.  The Makefile provides for

make chiptest

to produce code that runs on UNIX.

Pin numbering conventions

Note that the program needs to know the LPT1 pin layout, for example,
that pin2 is the first output pin, and pin 10 is the first input pin.
It also needs to know what inputs to complement.  Your challenge in
programming is to express this knowledge in a robust and clear way.
For simplicity, implement the case of using up to 8 output pins
and 5 input pins via PDR and PSR respectively.  Discuss any other
possibilities in your written report.

Let us standardize our handling of pins, so we can share experimental
setups.  The data register has bits 0, 1, 2, ..., 7, and these naturally
connect to the chip input pins in their natural order.  The status
register has only 5 usable bits, bits 3 to 7, and we use them in
increasing order as well.

 Data
 Reg	DB25	LS00	LS138
 bit	 pin	 pin	Input
  0	  2	  1	 A-0  <---logical 0th in pin: inpins[0]
  1	  3	  2	 A-1  <---logical 1st in pin: inpins[1]
  2	  4	  4	 A-2     ...
  3	  5	  5	 E-1
  4	  6	 (9)	 E-2
  5	  7	(10)	 E-3
  6	  8	(12)
  7	  9	(13)

Status
 Reg	DB25	LS00	LS138
 bit	 pin	 pin	Output
  3	 15	  3	 O-0   <---logical 0th out pin: outpins[0]
  4	 13	  6	 O-1   <---logical 1st out pin: outpins[1]
  5	 12	 (8)	 O-2     ...
  6	 10	(11)	 O-3
  7	 11		 O-4 


Thus data bit 0 connects via DB25 pin 2 to LS00 pin 1 or LS138 pin A0,
and data bit 3 connects via DB25 pin 5 to LS138 pin E1, etc.

Your assignment:

1. Write chiptest.c.  Note that chiptest's function "get_int_in_range()"
needs some fixing.  In general, do *not* use special-case code to do one
thing for ls00, another for ls138.  Instead use the info available in 
the struct chips to guide your code so it would work for *any* chip
that can be described by a struct chip.  In particular, determine all
the bit patterns needed for all the tests in a generic way based 
on the number of input pins.

2. Use chiptest.c to test some LS00 chips. If you find a bad one,
treasure it. If you don't, figure out a way to prove that your
chiptest.lnx program is capable of finding a bad chip. You might test some
other chip with the same pattern of input and output pins (expect lots
of errors!) or diliberately miswire the chip.  You may even mangle
one ls00 chip in the lab by bending pins out, etc.--they cost only
about 20 cents--throw it away when you're done or pass it to another
experimenter.

3. Write ls138_chip.c or ls148_chip.c, specifying the 3-to-8 decoder or
the 8-to-3 encoder respectively. You'll want to use C logic rather
than truth table lookup in function softchip().  Test some of those
chips. If you get carried away, write both, and _chip.c files for other
chips too.  Add the chip(s) to the array in chiptest.c and give the
user choice of chips to test by name, then test that chip.

4. Write chip_discussion.txt, in which you discuss the design problems you
encountered and solved, how you tested your program, and the chips you
tested and what happened.

Here are several more questions to think about.  Our chip
specifications allow for a maximum of 8 input and 5 output pins. Why?
Could we accommodate 6 input and 7 output pins?  10 input and 3 output
pins?  10 input and 5 outputs?  What are the options we have in
stretching these numbers of pins?

Your chiptest program works only for chips implementing combinatorial
logic. Testing sequential logic chips (memory chips, LS175's with
flipflops) is more subtle. Discuss why. Suggest extensions to the
contents of the _chip.c file and to the algorithms you would need to
build such a program.

Files I will collect:

README--special notes, late days being taken, which project you're
    submitting (chiptest/scope) and who your partner is for the 
    other project.
chiptest.c
*_chip.c
chip_discussion.txt