CMOS Gate Array Design Exercise 1999-2000
You have been allocated 9 hours of laboratory time in which to test your ULA designs. As a design team, the organization of your time is for the most part up to you. This document gives an outline of the tasks to be performed during this exercise and the available resources.
Before describing the tasks in more detail it is necessary to introduce the wafer testing equiptment.
Wafer Probe Station.
There are five Wafer Probe Stations in the electronics laboratory. These stations allow testing of chips prior to dicing and bonding. In this way we avoid wasting effort in packaging faulty chips.
Each station should be fitted with a 36 pin probe card for making connections to ULA devices on a four inch silicon wafer. The probe card should be connected via ribbon cable to a 40 pin DIL header. The 40 pin DIL header is pin compatible with a bonded die.
The bonding diagram for 36 pin ULA devices in 40 pin DIL packages is shown below:
SPARC Board Computer.
The SPARC Board (or RISC Experimenter Board) acts as the main processor for this exercise. It is interfaced to the device under test via its on-board Peripheral Interface & Timer (PIT) chips and a dedicated ULA Experimenter Board. It communicates with you, the user, via an RS232 connection to a PC.
Each SPARC Board can run any of four EPROM based programs. By selecting EPROM image 4 and pressing Reset you can select the I.C. test software required for this exercise.
The SPARC Board should be connected via two ribbon cables to a ULA Experimenter Board. The 40 pin Zero Insertion Force socket on this board is designed to accept a ULA device in a 40 pin DIL package. It will also accept the 40 pin DIL header from the Wafer Probe Station.
Power is supplied to the device under test by an external power supply via the power connections on the ULA Experimenter Board. Connections are also supplied on this board for the monitoring of current drawn by the device under test.
PC.
The networked PC next to your SPARC Board acts as a terminal and file store. The machines should be linked via an RS232 cable from the COM2 port of the PC to SERA port of the SPARC Board.
The SPARC Board is accessed using the Windows Terminal Program set up for communication via COM2. Other parameters are; 19200 baud, 8 data bits, 1 stop bit, no parity and hardware flow control. This set-up is stored in a file called ULA.TRM.
Test vectors can be stored on the PC and transfered between the PC and the SPARC Board using the Receive Text File and Send Text File facilities of the terminal program, or using windows Cut and Paste facilities.
This circuit should use standard components and customized PLDs to mimic the behaviour of your ULA based Frame Synchronization Unit.
The circuit can be built on one or a number of Experimentor breadboards. For connection to other circuits, you should be supplied with a ribbon cable with 40 pin DIL headers at each end. The circuit should be pin compatible with the ULA version, including all testability inputs and outputs. Thus any system developed to test the ULA can be verified using the clone circuit.
hint - the most common mistake made by clone builders in the past has been to re-connect the testable blocks on the clone circuit boards - the result is a clone which no longer behaves like the ULA - a proper clone matches the functionality of the ULA exactly, including taking power from pins 14 and 34 and supporting a single RS flip-flop - think always is this exactly how the ULA version would behave?
The SPARC Board computer allows you to create complex test vectors to check your circuit.
Test vectors are specified using a format statement followed by a number of vector specifications. The following test vectors might be used to check the RS flip-flop present on all chips:
"Test vectors for RS flip-flop"
"TESTnS TESTnR TESTQ"
f 26 27 24
v 0 0 H
v 1 0 L
v 1 1 L
v 0 1 H
v 1 1 H
v 1 0 L
v 1 1 L
The "......" indicates a comment that is ignored by the software.
The f command specifies the format of the test vectors in terms of pin numbers.
Each v command specifies a set of inputs {0,1,C,X} to apply to the inputs and a set of results {L,H,X} to expect on the outputs.
Using C as an input results in a 010 clock sequence on the pin. It is often useful to specify a number of clock pulses explicitly before using the C macro.
Using X as an expected output allows you to ignore the value of one output while you are testing another output. Although X is supported as an input, there is little benefit in using it since it is always interpreted as a 0.
You should aim to build up your test vectors until you have included tests for all parts of the circuit. The following vectors test an XOR gate as well as the RS flip-flop. The XOR gate has inputs at pins 32 and 33 and an output at pin 37.
"Combined test vectors"
f 26 27 24 32 33 37
"Test vectors for RS flip-flop"
V001 0 0 H 0 0 X
V002 1 0 L 0 0 X
V003 1 1 L 0 0 X
V004 0 1 H 0 0 X
V005 1 1 H 0 0 X
V006 1 0 L 0 0 X
"Test vectors for XOR gate"
V007 0 0 X 0 0 L
V008 0 0 X 0 1 H
V009 0 0 X 1 0 H
V010 0 0 X 1 1 L
Vectors V001-V006 test for the RS flip-flop as before and vectors V007-V010 test for the XOR gate.
Note that the use of more formal, consecutively numbered, vectors helps to isolate errors while making it harder to insert vectors into the sequence.
A number of vector manipulation commands are available while using the chip test software. Useful commands include:
Type help at the command prompt in order to see a summary of these and other commands.
Note the importance of parallel development; the vectors can be used to debug the clone while the clone can be used to debug the vectors.
Each wafer has over 450 ULA sites, of which approximately 20 are yours. Having located your ULA sites, identified by the team letter below and to the right of each ULA site, you should test each site for random process failures and systematic design faults.
Where a systematic failure is observed (such as an output which never changes on any of your ULA sites or one which consistently exhibits strange behaviour), you should attempt to identify its cause. Most systematic failures are caused by errors at the design or implementation stages. In order to spot design errors, you will have to study your team's interim report and any netlist, icebox file or hard copy you have available for your design. Of course the most useful way to spot a design error is through simulation of your design.
In the event of a design error you may wish to modify your test vectors to test for the circuit as it was implemented, as distinct from as you had hoped it was implemented.
Where random process failures are observed, such as an output which works on one site but not on another, you should use your test vectors to isolate particular circuits which are in error. It is then possible to build up a map of these process failures for the whole wafer, showing where failures are more frequent and indicating where correct chips can be found. This map should contain as much information as time allows. It is usual to record static current consumption on such a map as it provides an extra indication of the health of a circuit.
The outline circuit shown in outline below includes:
The circuit should expect a 40 pin DIL package containing the ULA Frame Synchronization Unit that you have designed (this is the DUT). During the design and implementation stages of this exercise you should have separated your Frame Synchronization Unit into a number of testable sub-circuits. These sub-circuits are re-connected here in order to create a fully functional Frame Data Decoder.
This circuit can be fully debugged using the Frame Synchronization Unit clone in place of the ULA version.
Protocol
The protocol for incoming data is shown below:
All fields are transmitted LSB first.
The six bit frame alignment word is transmitted at the head of the frame. For teams who opted for 5 (or 4) bit frame alignment words, F5 (and F4) can be ignored.
The seven bit frame data will usually contain a single ASCII character allowing for easy display on a character based terminal.
The station address tells us the intended destination of the frame. Each team should select only frames which are addressed to that team:
The frame number tells us which frame within a message is being transmitted. The maximum size of a message is 16 frames. The frame number can be used to spot errors such as missing frames within a message.
The 9 bit parity field provides 2 dimensional parity check for the frame data, station address and frame number. This 2D parity can be used to correct isolated errors and to detect multiple errors.
P0-P7 provide odd parity for the rows and columns of a 4×4 array of the bits to be checked:
D0 + D1 + D2 + D3 + 1 = P0
+ + + +
D4 + D5 + D6 + A0 + 1 = P1
+ + + +
A1 + A2 + A3 + A4 + 1 = P2
+ + + +
N0 + N1 + N2 + N3 + 1 = P3
+ + + +
1 1 1 1
= = = =
P4 P5 P6 P7
each "+" indicates modulo two addition (XOR function).
Single errors in the checked bits will result in observed errors in two of the parity bits.
e.g.
The last parity bit provides even parity for the other bits:
P0 + P1 + P2 + P3 + P4 + P5 + P6 + P7 = P8
With this parity for the parity bits, we can correct all single bit errors and detect the majority of multiple bit errors within the checked bits and within the parity bits.
The last bit of the frame is not allocated, although a slight improvement in error detection can be gained by using it as an inverted copy of P8.
For the two teams that opted for a 16 bit frame length, the protocol is shown below.
In this case no frame number or parity information is transmitted. The station address is reduced to just 3 bits which is sufficient for the teams affected.
Xilinx Based Decode Unit
The Xilinx based decode unit should perform the task of selecting frame data from frames addressed to the station (and of course broadcast frames) and formatting it for transmission over an RS232 link. Simple status information is displayed via seven segment display on the Xilinx board.
To help you with the task of programming the Xilinx chip a number of useful files are provided:
This VHDL file contains a simple implementation of the Xilinx based decode unit which copes only with error free 32 bit broadcast frames.
This VHDL file contains a test bench for the simple decode unit provided.
This file is a Xilinx constraints file to specify the pin allocation for the decode unit:
#PINLOCK_BEGIN
NET "ramDISABLE" LOC = "P65";
NET "ucRESET" LOC = "P36";
NET "CLOCK" LOC = "P78";
NET "nRESET" LOC = "P79";
NET "DATA" LOC = "P82";
NET "STROBE" LOC = "P83";
NET "SERIAL_OUT" LOC = "P3";
NET "segA" LOC = "P19";
NET "segB" LOC = "P23";
NET "segC" LOC = "P26";
NET "segD" LOC = "P25";
NET "segE" LOC = "P24";
NET "segF" LOC = "P18";
NET "segG" LOC = "P20";
#PINLOCK_END
This file must be specified to the Xilinx Design Manager when you specify
New Version information via the dialogue box of the same name;
simply set the constraints file to custom and then browse for the
decode.ucf file.
Note that previously you have specified constraints via Synplify. Unfortunately Synplify doesn't allow us to constrain the location of the CLOCK input.
The sort of adaptions that you should be considering are:
hint - the tap positions (for parallel output) on the frame buffer will change where the default frame parameters aren't used - from the point of view of a frame synchronization unit expecting a 4 bit FAW, bits F4 and F5 will be treated as the first data bits with the strobe arriving coincident with F4.
If you wish to use additional pins on the Xilinx chip, pins P4, P5 and P84 can be used without danger of upsetting other devices on the Xilinx board. For more details on the board see manuals/tutorials on the Xess website at www.xess.com - our boards are XS40 version 1.2 although the 1.3 version is similar and much better documented.
Data Generation
Data generation is performed by a program running on a second SPARC board.
A suitable program is available as a compiled program image, gen1.txt. This provides the CLOCK, the DATA input and sometimes the STROBE input for the system:
The operation of the program is controlled by the eight toggle switches on the SPARC board:
| Switch settings | Operation | Comments |
|---|---|---|
| 0XXXXXXX | 32 bit operation | each frame consists of; 6 bits FAW, 7 bits frame data, 5 bits station address, 4 bits frame number, 9 bits 2D parity, 1 bit unused. |
| 1XXXXXXX | 16 bit operation | each frame consists of; 6 bits FAW, 7 bits frame data, 3 bits station address. |
| XXXXX000 | Full Test | includes broadcast and addressed packets for all stations |
| XXXXX001 | Broadcast Test | all messages are of type "broadcast" |
| XXXXX011 | Simple debug operation | again all messages are of type "broadcast", a STROBE signal is provided in addition to DATA and CLOCK, allowing testing of the decoder without a frame synchronization unit |
In all cases, the frame alignment word used by this program is 13. This value is suitable for frame synchronization units supporting 4, 5 or 6 bit FAWs.
It is anticipated that new versions of this program will become available as the exercise progresses to provide more stringent test conditions.
If you would prefer to generate your own test data, a skeleton 'C' program, generate.c, can be used as a start point.
Observation
The output from the ICL232 can be connected to the COM2 input of a PC to observe the output of the system. The terminal program should be configured for 1200 baud, 7 data bits, 2 stop bits, no parity and no flow control. This setup is stored in the decode.trm file.
It is likely that you will have to use a single PC for both controlling the SPARC board and viewing the data. This should not be a problem since the data generation program will run quite happily without a serial connection to the host.
As with the test vectors you should use the clone to help in the debugging of your test circuit. A demonstration of the full system based on the clone is one of the deliverables for this exercise.
Having found a perfect ULA site (or one which is as near perfect as design and process failures allow) you should attempt to complete the exercise by connecting the ULA Frame Synchronization Unit to the full test circuit. You may need to bypass some ULA circuitry to make up for a less than perfect ULA sample.
In addition to the Wafer Probe Station, PCs and SPARC boards, you will need a number of items detailed below:
As used in CX laboratory.
The laboratory time is divided into two:
You should plan your work for the laboratory sessions and between laboratory sessions in order to make best use of the available resources.
In order to make most effective use of the wafers, you should attempt to get as much information as possible out of the wafer during the introductory session. Do not fall into the trap of performing simple tests over all of the sites on a wafer, having found one functional RS flip-flop you have demonstrated an absence of systematic faults in the flip-flop and checked your test vectors for the flip-flop. Move quickly on to tests for other simple sub-circuits.
This allows you to build clone and test circuits outside of the scheduled sessions.
In order to facilitate further testing, you may borrow these kits outside of your scheduled lab sessions provided that they are not required for other scheduled sessions and provided that you return them on the same morning/afternoon that you borrow them.
A small number of clone cables may also be available for you to borrow when interconnect kits are in use.
Iain McNally
23-2-2000
