CMOS Gate Array Design Exercise 2000-2001
You have been allocated 9 hours of laboratory time in which to test your CMOS Gate Array (CGA) 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 CGA 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 CGA 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 CGA 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 C:\WINNT\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 CGA based Controller.
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 CGA version, including all testability inputs and outputs. Thus any system developed to test the CGA 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 CGA - a proper clone matches the functionality of the CGA exactly, including taking power from pins 14 and 34 and supporting a single RS flip-flop - think always is this exactly how the CGA 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 CGA sites, of which approximately 20 are yours. Having located your CGA sites, identified by the team letter below and to the right of each CGA 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 CGA 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 schematic diagram below shows the interface and datapath submodules in the xilinx based multiply unit and their connection to the controller.
The circuit should expect a 40 pin DIL package containing the CGA Controller that you have designed. This is the device under test (DUT). During the design and implementation stages of this exercise you should have separated your Controller into a number of testable sub-circuits. These sub-circuits are re-connected here in order to create a fully functional Versatile Multiply Unit.
This circuit can be fully debugged using the Controller clone in place of the CGA version.
Xilinx Based Versatile Multiply Unit
The Xilinx based multiply unit includes an interface module that you should not change and a datapath module that you will need to modify. A number of simple tasks are performed ouside of these modules such as the control of a seven segment display for status information.
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 multiply unit which copes only with unsigned 8 bit multiplication.
This VHDL file contains a model of a simple controller. It is used to create a realistic simulation.
This VHDL file contains a test bench for the simple multiply unit and controller provided.
This file is a Xilinx constraints file to specify the pin allocation for the multiply unit:
# Global Clock & Reset NET "CLOCK" LOC = "P57"; NET "nRESET" LOC = "P58"; # Signals to/from controller NET "Start" LOC = "P59"; NET "LsbB" LOC = "P60"; NET "EmptyB" LOC = "P61"; NET "FullB" LOC = "P62"; NET "UpdateA" LOC = "P27"; NET "UpdateB" LOC = "P28"; NET "UpdateP" LOC = "P29"; NET "Shift" LOC = "P35"; NET "ZeroP" LOC = "P37"; NET "Subtract" LOC = "P38"; NET "EnableP" LOC = "P39"; # Signals to/from SPARC PAR2 NET "C2" LOC = "P79"; NET "H2" LOC = "P80"; NET "H1" LOC = "P81"; NET "H3" LOC = "P82"; NET "C3" LOC = "P84"; NET "portB(0)" LOC = "P3"; NET "portB(1)" LOC = "P4"; NET "portB(2)" LOC = "P5"; NET "portB(3)" LOC = "P6"; NET "portB(4)" LOC = "P7"; NET "portB(5)" LOC = "P8"; NET "portB(6)" LOC = "P9"; NET "portB(7)" LOC = "P10"; # Location of these pins is fixed: NET "clock12MHz" LOC = "P13"; NET "ucRESET" LOC = "P36"; NET "ramDISABLE" LOC = "P65"; 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";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 mult.ucf file.
Note that previously you have specified constraints via Synplify. Unfortunately Synplify has various restrictions including not allowing us to constrain the location of CLOCK pins.
Since you may not have a fully working clone available during the initial stages of development, some more files have been added:
This PLPL file can be used to program an 18CV8 to mimic the behaviour of the simple VHDL controller model.
This allows a complete system to be built without a working clone and without any VHDL having been written. You should aim to complete this task within your first 3 hour lab session. A fully working system will be available in the lab so that you know what is expected of you.
This VHDL file supports the demonstration of a Xilinx based Multiply Unit in the absence of external clock and external controller. The clock is provided by dividing the 12 MHz on board clock down to a more sedate 12 Hz while the controller is the simple VHDL controller used for simulation. A corresponding mult_plus.ucf constraints file with various pins omitted is provided to support this file.
Using this system may help to debug both VHDL and clone systems.
The sort of adaptions that you should be considering are:
Currently the controls for the registers in the interface are derived from the standard controls thus:
EnableOperand1 <= UpdateA and not Shift; EnableOperand2 <= UpdateB and not Shift; UpdateResult <= EnableP;If for your controller this will result in a single cycle of activity on each of these control lines you are probably OK. If not you may have to generate these signals with more complex VHDL (in particular if your EnableP signal remains high after the end of the multiplication then the multiplication will appear not to finish since it is the falling edge of UpdateResult which indicates the termination of the multiplication).
Currently the datapath supports the multiplication of two 8 bit values to produce a 16 bit result. The widths of the various buses can be seen on the schematic diagram above. (note that the A register is 16 bits wide in order to accommodate the shifted operand). If your controller can cope with 16 bit multiplication you should write a version of the datapath the multiplies two 16 bit numbers to create a 32 bit result.
It should also be possible to modify the system to perform multiplication of 32 bit values. Since the Result register is constrained to 32 bits there is a possibility of overflow. Your system should flag such an overflow on the 7 segment status display.
Various changes must be made to the datapath to cope with signed numbers. In particular the you should ensure that the sign bit is always preserved as data is shifted or moved to a register of different length.
Eventually you might aim to design a datapath that copes with all the different data lengths and modes of operation, indicating a variety of status and error information to the user. This task is considered to be hard given your limited experience with VHDL and digital design. It is expected that fewer than half of the teams will complete this goal. You should remember that more marks will be awarded for a simple working system than a complex system that isn't quite complete and plan your work accordingly.
If you wish to use additional pins on the Xilinx chip, such as to provide the Signed input to the datapath, pins P40, P50, P67, & P68 can be used without danger of upsetting other devices on the Xilinx boad. 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.
User Interface
The user interface is provided by a program running on a second SPARC board. The SPARC board is connected to the Xilinx board via a special cable which connects to the PAR2 connector on the SPARC board and to the keyed header on the Xilinx board.
A suitable program is available as a compiled program image, mult.txt. The program prompts the user to input values for multiplicand and multiplier. These values are then transferred via the PIT2 chip which provides 8 bit parallel I/O to the 32 bit Operand registers within the interface module of the Xilinx based versatile multiply unit. A Start pulse is also generated in order to initiate the multiplication. When the multiplication is complete the Result is transferred back to the SPARC board and passed to the user.
This program uses the basic input handling facilities available on the SPARC and can be upset by strange behaviour like pressing the backspace key. If you don't like the results you can always reset the SPARC board and call the program again.
It is anticipated that new versions of this program will become available as the exercise progresses to provide more stringent test conditions.
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 CGA site (or one which is as near perfect as design and process failures allow) you should attempt to complete the exercise by connecting the CGA Controller to the full test circuit. You may need to bypass some CGA circuitry to make up for a less than perfect CGA sample.
In addition to the Wafer Probe Station, PCs and SPARC boards, you will need a number of items detailed below:
Included with the XS40 board you should find a couple of extra cables:
The XS40 board should be fitted with a couple of headers to accommodate these cables.
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
21-4-2001