Serial Data Frame Generator for Testing Telecommunications Circuits

The disclosed invention relates generally to the field of circuit board testing and more specifically to the art of testing telecommunications circuit boards. Generally, a given circuit board consists of numerous semiconductor chips, such as a microprocessor, memory chips, counter chips, control chips, etc., laid out according to some interactive design. Following design and layout of the circuit board, it is necessary to test the board to ensure that all the chips, as laid out, perform as expected. Testing will involve application of test-vectors to pins of a given chip (or cluster of chips) on the board. A test-vector for a given chip (or cluster of chips) generally consists of a binary word having an "input" portion and an "output" portion. The goal in testing is to determine if the application of the input portion of a test-vector produces an output matching the output portion of the test-vector. If there is a match, the test is successful (pass). Unsuccessful tests (failure) indicate defective board design, defective layout or defective chips. Test-vectors will be supplied by the designer of the circuit board (usually with the aid of a computer-aided-design (CAD) system). The test-vectors will be chosen so as to pinpoint problems on the board, if they exist.

Actual circuit board testing is performed with the aid of a circuit board testing machine. Circuit board testing machines are well known in the prior art. For example, a well known circuit board testing machine is the Hewlett-Packard Company model HP-3065 circuit board tester. The HP-3065, for instance, has 264 pins which can be simultaneously selectively connected to various pins of a given circuit board for application of test-vectors to the board and the monitoring of board output generated in response. The HP-3065 is fully described in the October 1984 issue of the Hewlett-Packard Journal. With the aid of a circuit board tester, whole sequences of test-vectors are applied to the board under test. In fact, it is not uncommon for test-vector listings to be thousands of test-vectors long where each test-vector is dozens of bits in width. Typically, such test-vectors are applied, sequentially one test vector at a time, in parallel to the circuit board under test.

Telecommunication circuit boards, however, present a special problem in circuit board testing: serial data protocols. Essentially all modern telecommunication schemes obey some sort of serial data protocol, such as the X.25 (HDLC) protocol for wide area networks, the Integrated Services Digital Network ISDN S-Bus protocol (CCITT I.430), the 24-channel U.S. T1 telephone protocol, and so forth. Common to all such protocols is the organization of information in the form of serial frames. The protocol defines the structure of the frame. Consider, for instance, the 24-channel U.S. T1 telephone protocol: analog voice signals are sampled and the samples are digitized; each digitized sample consists of one byte of information; samples are grouped in a 24-channel serial frame; each frame is 193 bits long consisting of a lead framing bit followed by 24 bytes, where each byte is a single sample from a given channel. Communication over the T1 systems occurs via transmission of T1 frames.

A typical T1 circuit which may require testing is a T1 coder-decoder (Codec), such as the National Semiconductor Company model TP 3064 Codec. A Codec is a T1 circuit which interfaces between the network and a telephone and serves to convert analog signals to digital (A/D) and digital signals to analog (D/A). In the digitizing process, the Codec samples the analog signal at the rate of 8 KHz. Thus, for instance, eight samples would be required to digitize a 1 KHz analog signal. These eight samples would be inserted in the same channel position of eight consecutive T1 frames. The general procedure for digitizing a given analog signal with a Codec is as follows: (1) generate the voltage sample of the sine wave for each sampling interval of time; (2) convert the voltage sample to the appropriate pulse code modulated (PCM) eight bit code, that is, digitize the sample; (3) insert the eight bit digitized sample value into the proper channel position of a 24-channel T1 frame; (4) repeat steps 1 through 3 for the next sample value. This procedure, however, becomes exceedingly tedious and time consuming, even for relatively "simple" signals like a sinusoidal frequency. For instance, sampling a 1010 Hz signal at a sampling rate of 8 KHz would require 800 samples before the samples would begin to repeat themselves. These 800 samples would be inserted in the same channel position of 800 consecutive T1 frames. This amounts to 800.times.193=154,400 bits of information which would be necessary to test a Codec to determine if it properly digitized a 1010 Hz signal. In addition, the PCM analog-to-digital conversion process may require application of a complex transfer function. (See the International Telegraph and Telephone Consultative Committee (CCITT) Red Book, Vol. III, Fascicle III.3, Tables 1a/G.711 & 1b/G.711 (A-law) and 2a/G.711 & 2b/G.711 (Mu-law).) Finally, this information must be converted (one bit at a time) to the corresponding test pattern language which the given circuit board tester requires.

It has been prior art practice to generate such data "manually", that is, a test programmer has had to calculate the necessary serial frame test data and transform it into test pattern language information which the given circuit board tester can accept. Thus, for a given serial device, the test programmer must generate the sample data, generate the serial frames from the sample data, and then generate the test data from the serial frames. Obviously, generating such large amounts of complex telecommunication serial frame test data is tedious and time consuming. (Generating such test data "manually" could very well consume weeks of an individual's time.) Moreover, ensuring the accuracy of the test data is very difficult and to the extent that there are doubts about the accuracy of the test data, the test results are suspect. The result has been that prior art testing of complex telecommunications circuits has been limited by the difficulty of generating sufficient amounts of accurate serial frame test data.

The present invention provides for quick and accurate generation of serial frame test data for telecommunications circuit boards. Through software, the present invention performs the major steps of (1) generating the data; (2) generating the serial frames from the data; and (3) generating the test data from the serial frames. Although the present invention could be easily adapted to work with essentially any modern circuit board tester, it has been implemented on the HP-3065 circuit board tester machine and it will therefore be described in connection with the HP-3065. The invention is implemented using a form of the BASIC programming language which has been adapted for use on board test machines and dubbed BT-BASIC. BT-BASIC is well known in the prior art and is fully explained in connection with the HP-3065 instruction manual.

The first major step of generating digital data is performed by a so-called Serial Frame Generator. The Serial Frame Generator includes: a Data Generator; a collection of Data Generation/Conversion (DG/C) routines and user-written Data Files; and a Frame Generator. The Data Generator produces the digital data which is representative of a given analog signal by either reading data from a user-written Data File or generating data by executing a given DG/C routine. The DG/C routines produce the digital data representative of single or multi-tone sine waves, pseudo-random bit sequences (such as a 511 bit error rate (BER) signal), CCITT G.711 reference and noise signals, and CCITT PCM A-law and Mu-law conversions. In addition, the Data Generator and DG/C routines are written in an open systems manner so that the user can customize an original DG/C to produce a particular kind of data.

The second major step of generating the serial frames from the digital data is also performed by the Serial Frame Generator. In addition to the Data Generator and DG/C routines, the Serial Frame Generator includes a Frame Generator. The Frame Generator converts the data produced by the Data Generator into serial frames which obey a user-selected telecommunications protocol. Among the framing options available to the user are 1-channel, 24-channel and 32-channel T1 frames, X.25 (HDLC) frames, ISDN frames, and various Siemens frames. (See the 1987 Siemens Telecommunications Data Book.) In addition, the Frame Generator is also written in an open systems manner so that the user can add framing options. Output from the Frame Generator is stored in a so-called Frame Data File.

The third and final major step of generating the circuit board test data from the serial frames is performed by a Pattern Capture Format (PCF) Generator. (PCF is explained in Chapter 7 of the HP-3065 X/L user's manual, Vol. III: Advanced Technologies Testing--Reference and Syntax) The PCF Generator has two input files: the Frame Data File and a so-called Format File. As noted, the Frame Data File is the output of the Frame Generator. The Format File is a user-written file containing executable VCL code together with instructions for merging the data in the Frame Data File with the executable VCL code to produce an executable PCF Output File. "VCL" stands for "Vector Control Language". VCL is a feature of the HP-3065 circuit board tester. VCL is a high-level language which is compiled, linked and executed by the HP-3065 computer. VCL allows a programmer to operate the HP-3065 with source-code-like programming instructions. (VCL is fully explained in chapter 23 of the HP-3065 X/L user's manual, Vol. I: System Reference.) The PCF Generator includes a Parser and a PCF Source Code Generator which generates VCL-compatible source code. The Format File is the input file to the Parser. The Frame Data File is the input file to the PCF Source Code Generator. The Parser processes the syntax information in the Format File and issues commands to the PCF Source Code Generator. The PCF Source Code Generator processes the Frame Data File together with the output of the Parser to produce the PCF Output File containing VCL-compatible PCF source code.

The VCL-compatible PCF source code, that is, the PCF Output File, may be compiled, linked and executed by the HP-3065. Thus, the present invention allows the HP-3065 user to quickly specify and generate serial data frames for the testing of telecommunications circuits. The invention allows for high programmer productivity as well as providing adaptability so that the programmer can write applications for his/her individualized needs. The prior art alternative to the present invention is "manual" coding, which would require significant programmer time in calculating complex serial frames and checking them for accuracy. The present invention, therefore, enables the circuit board testing programmer to produce large amounts of comprehensive and accurate serial frame test data which would simply be too tedious and/or time consuming to reasonably produce with prior art alternatives.

FIG. 1 shows a schematic diagram of a circuit board testing machine such as would be used with the present invention.

FIG. 2 shows a step-wise flow diagram of the present invention.

FIG. 3 shows a schematic diagram of the present invention.

FIG. 4 shows a schematic diagram of Serial Frame Generator 125 of FIG. 3.

FIG. 4A shows a blow-up of Data Generator 200 of FIG. 4.

FIG. 4B is a blow-up of box 267 of FIG. 4A.

FIG. 5 shows a schematic diagram of PCF Generator 150 of FIG. 3.

FIG. 6 shows an example of Format File 140.

FIG. 6A shows the contents of the d a data file of FIG. 6.

FIG. 6B shows an example of a PCF Output File 175 which has been derived from the Format File 140 of FIG. 6 and the Frame Data File 130 of FIG. 6A.

FIG. 7 shows pseudo code which shows how Parser 300 and PCF Source Code Generator of 350 process Format File 140 and Frame Data File 130, respectively, to produce PCF Output File 175.

FIG. 1 shows a schematic diagram of a circuit board testing machine such as would be used with the present invention. Computer 5, Test Station 10 and Test Fixture 15 comprise the circuit board testing machine, such as the HP-3065 circuit board tester. The object of testing is the Device Under test (DUT) 20. DUT 20 is a circuit board, and in particular a telecommunications circuit board. Computer 5 controls the interaction of Test Station 10 and test Fixture 15 in the testing of the DUT 20.

FIG. 2 shows a step-wise flow diagram of the present invention. Box 50 shows an analog signal which has been sampled at regular intervals Box 53 shows digital data conversions of such samples. Box 56 shows a serial frame protocol. The digitized samples from box 53 would be inserted into the serial frame format of box 56. The serial frame(s) of box 56 are then converted into VCL-compatible PCF source code, as shown in box 59. The code in box 59 would be directly executable by an HP-3065 circuit board tester. Note in box 59 that the serial frame data (which would be used as stimulus input to a telecommunications circuit board under test) is included directly within the PCF code. It should be noted that FIG. 2 is in fact schematic: the present invention does not actually sample and digitize an analog signal. Rather, the digital information, which is representative of digitized analog samples (as shown in box 53), is either read from a file or generated directly by the present invention. This digital data is then inserted into a user-selected serial frame protocol format, as shown in box 56. As shown in box 56, a given serial frame protocol format will have defined fields. Box 56 shows a 24-channel T1 frame having a lead framing bit followed by 24 8-bit data channel fields. (Typically, when testing a telecommunications circuit with serial frames, certain frame fields will remain constant from frame to frame while other fields, such as a given channel in a T1 frame such as channel.sub.0, will vary with each frame. Thus, the generated digital data (as represented by box 53) will typically be inserted in the variable frame fields while the constant fields will simply be repeated from frame to frame.) The serial frames are then converted into VCL-compatible PCF source code as shown in box 59. The PCF source code, like VCL, can be compiled, linked and executed by the HP-3065.

FIG. 3 shows a schematic diagram of the present invention. The user will input a request on an HP-3065 for serial frame data with which to test a given telecommunications circuit board. User Input 75 is processed by Serial Frame Generator 125. User Input 75 will specify the type of data for which serial framing is required and the protocol to which the serial frame data must conform. Serial Frame Generator 125 generates the actual serial frames which conform to User Input 75. These serial frames will then be stored in Frame Data File 130. User Input 75 will also include a user-written Format File 140. The Format File 140 is a user-written file containing executable VCL code together with instructions for merging the data in the Frame Data File 130 with the executable VCL code to produce an executable PCF Output File 175. Frame Data File 130 and Format File 140 are input files to Pattern Capture Format (PCF) Generator 150. Obeying the merge instructions in Format File 140, PCF Generator 150 merges the serial frame data from Frame Data File 130 with the executable VCL code in Format File 140 to produce PCF Output File 175 containing VCL-compatible PCF source code which is executable by the HP-3065. An example of such a PCF Output File 175 is shown in box 59 of FIG. 2.

FIG. 4 shows a schematic diagram of Serial Frame Generator 125 of FIG. 3. Serial Frame generator 125 includes Data Generator 200, memory structure 210 containing DG/C routines and Data Files, and Frame Generator 250. As noted above, User Input 75 will specify the particular telecommunications protocol to which the desired serial frame data must conform. In the preferred embodiment of the present invention, eight widely followed protocol options are available as well as a general template option with which the user can tailor a protocol that is not among the eight options. Depending upon the protocol chosen (or tailored) by the user, serial frame data will either be generated with a given DG/C routine or read from a given Data File. The eight framing protocol options available in the preferred embodiment of the present invention are as follows: 1-channel, 24-channel and 30-channel T1 frames, Siemens IOM and SLD frames, serial RS232 frames and X.25 (HDLC) frames, and the ISDN S-Bus protocol conforming to the CCITT I.430 standard. Typically, data for the RS232, the X.25 and the ISDN S-Bus (CCITT I.430) protocols will reside in memory structure 210 in user written Data Files. Typically, data for the remaining protocols will be generated with a given DG/C routine. Given the user selected protocol and the appropriate data (either generated with a DG/C or read from a user-written Data File), Frame Generator 250 formats the data into serial frames conforming to the selected protocol. The serial frames are then stored in Frame Data File 130. As noted above, the present invention is implemented in software in the BT-BASIC programming language. The BT-BASIC implementation of Serial Frame Generator 125 is listed in Appendices A and B. Appendix A contains the BT-BASIC code for Data Generator 200 and Frame Generator 250. Appendix B contains the BT-BASIC code for the DG/C routines.

FIG. 4A shows a blow-up of Data Generator 200 of FIG. 4. As shown in box 255, Data Generator 200 receives input requesting "N" number of serial frames conforming to a given protocol. ("N" is an integer.) Depending upon the protocol, Data Generator 200 will obtain framing data either by reading data from the appropriate user-written Data File(s) and/or by executing the appropriate DG/C routine(s). (Recall that the user-written Data File(s) and the DG/C routine(s) reside in memory structure 210 of FIG. 4.) Typically, the protocols which will require user written Data Files are the following: X.25 (HDLC), RS232 and the ISDN S-Bus (CCITT I.430). Typically, the protocols which will have one or more DG/C routine are the following: 1-channel, 24-channel and 30-channel T1 protocols; and the Siemens IOM and SLD protocols. There is also a ninth option: the preferred embodiment of the present invention provides a template whereby the user can write his/her own protocol framing subroutine. Given "N", the user-requested number of serial frames, and the o user's choice of protocol for the frames, data is generated by Data Generator 200 and an appropriate protocol implementation program of Data Generator 200 and Frame Generator 250 is called. In the preferred embodiment of the present invention, the implementation programs are written in the BT-BASIC programming language, although essentially any programming language could be used. The BT-BASIC code implementation of Data Generator 200 and Frame Generator 250 for each protocol (including a user definable template) is listed in Appendix A. The implementations as listed in Appendix A are shown in Table 1. The implementations are quite self-explanatory. Note also that for each protocol, Frame Generator 250 will call a given Frame Generation Subroutine, as shown in box 267. Each Frame Generation Subroutine in turn will call the subroutines GetBitsMSB (box 269), GetBitsLSB (box 271), OpenFile (box 273), PrintBits (box 275) and possibly FGen.sub.13 Error (box 277). The Frame Generation Subroutines corresponding to each protocol are listed Table 2 below. The subroutines called by the Frame Generation Subroutine of box 267 are also explained and defined in Appendix A as listed in Table 2.

FIG. 4B is a blow-up of box 267 of FIG. 4A. A given Frame Generation Subroutine, such as Generate.sub.-- 24ch, is called in box 280. In box 282 a counter variable is initialized to zero. Frame Data File 130 is then created in box 284. The data to be formatted into a frame will have been produced by Data Generator 200, either by invocation of a DG/C and/or reading from a user-written Data File. In the preferred embodiment of the present invention, the data produced by Data Generator 200 will reside in a "temp-file" in main memory in computer 5. In box 286, the first line of such data is inserted into a given frame format as dictated by the user-chosen protocol. The frame information generated in box 286 is then written to Frame Data File 130. The counter variable is then incremented in box 290. A check is made in diamond 292 to see if the number of frames (N) requested by the user have been written. If not, the process loops back to box 286 and the next line of data in the "temp-file" is formatted into a frame. On the other hand, when the "N" frames requested by the user have been generated and written to Frame Data File 130, then Frame Data File 130 is closed.

As noted above, Data Generator 200 either reads data from a user written Data File or produces data by invoking DG/C routines. In the preferred embodiment of the present invention, the DG/C routines are also implemented in the BT-BASIC programming language. The DG/C routine BT-BASIC implementations are listed in Appendix B. The DG/C, routines are also described and explained in Chapter 9 of HP-3065 X/L user's Manual, Vol. III, Rev. C, sections 9.4.3 through 9.4.12.

FIG. 5 shows a schematic diagram of PCF Generator 150 of FIG. 3. PCF Generator 150, merges data with a programming language to produce a file which is directly executable by computer 5. In the preferred embodiment of the present invention, PCF Generator 150 has two input files: data is contained in Frame Data File 130 and a programmable language is contained in Format File 140. The data in Frame Data File 130 may be supplied by the user or it can be generated by Serial Frame Generator 125. Format File 140 is written by the user. Format File 140 will contain executable VCL code together with instructions for merging the data in Frame Data File 130 with the executable VCL code to produce an executable PCF Output File 175. As noted above, "VCL" stands for "Vector Control Language". VCL is a feature of the HP-3065 circuit board tester. VCL is a high-level language which is compiled, linked and executed by the HP-3065 computer. VCL allows a programmer to operate the HP-3065 with source-code-like programming instructions. (VCL is fully explained in chaper 23 of the HP- 3065 X/L user's manual, Vol. I: System Reference). The PCF Generator includes a Parser 300 and a PCF Source Code Generator 350 which generates VCL-compatible source code. User-written Format File 140 is the input file to the Parser 300. Frame Data File 130 is the input file to the PCF Source Code Generator 350. Parser 300 processes the syntax information in the Format Dile 140 and issues commands to PCF Source Code Generator 350. PCF Source Code Generator 350 processes Frame Data File 130 together with the output of Parser 300 to produce the PCF Output File 175 containing VCL-compatible PCF source code. A complete explanation of the operation of PCF Source Code Generator 350 together with, prescriptions of Format File 140 syntax is contained in Chapter 1 of HP-3065 X/L user's Manual, Vol. III, Rev. C pages 9-62 through 9-70. An implementation of PCF Source Code Generator 350 in the BT-BASIC programming language is listed in Appendix D.

FIG. 6 shows an example of Format File 140. Format File 140 is written by the user. Instructions for writing the Format File are listed in Chapter 9 of HP-3065 X/L user's Manual, Vol. III, Rev C. As shown in FIG. 6, the Format File has two sections: a header section and a program section. The header section lines are indicated by leading "!" characters. The program section is the remaining part of the Format File and contains VCL and PCF statements. (Recall that PCF is explained in chapter 7 of the 3065 X/L user's manual, Vol. III, and VCL is explained in chapter 23 of the 3065 X/L user's manual, Vol. I.). The lines beginning with the character "!" are comment lines in VCL. However, a line beginning with "!##" is a replacement command to the PCF Generator. The "!##" command will specify a replacement character and the name of a Frame Data File 130. In FIG. 6, the PCF command line is: !##M "*" "d.sub.13 a.sub.-- data". The asterisk (*) is the replacement character and d.sub.-- a.sub.-- data is the name of the Frame Data File 130. The command tells the PCF Generator to replace the asterisk with data from the d.sub.-- a.sub.-- data file wherever the asterisk occurs in the PCF code in the program section of the Format File. The PCF code is bounded by the statements pcf and end pcf in the program section.

FIG. 6A shows the contents of the d.sub.-- a.sub.-- data file of FIG. 6. The d.sub.-- a.sub.-- data file is the Frame Data File 140.

FIG. 6B shows an example of a PCF Output File 175 which has been derived from the Format File 140 of FIG. 6 and the Frame Data File 130 of FIG. 6A.

FIG. 7 shows pseudo-code which shows how Parser 300 and PCF Source Code Generator of 350 process Format File 140 and Frame Data File 130, respectively, to produce PCF Output File 175. Parser 300 detects the "!##" line in Format File 140, reads the name of the Frame Data File 130, and associates that name with the replacement character (the "*" in FIG. 6).

FRAME.sub.-- 1CH

sub Generate.sub.-- 1ch

FRAME.sub.-- 24CH

sub Generate.sub.-- 24ch

FRAME.sub.-- 30CH

sub Generate.sub.-- 30ch

FRAME.sub.-- HDLC

sub Generate.sub.-- hdlc

FRAME.sub.-- IOM

FRAME.sub.-- RS232

FRAME.sub.-- SLD

FRAME.sub.-- TEMPLATE

sub Generate.sub.-- frame

FRAME.sub.-- SBUS.sub.-- TE

sub Generate.sub.-- Sbus.sub.-- TE ##SPC1##

Tone

A.sub.-- LAW

MU.sub.-- LAW

G.sub.-- noise

Idle.sub.-- Code

PRBS

U.sub.-- noise

A.sub.-- to.sub.-- D

Digital.sub.-- mW ##SPC2##

PCFEN

PARSE.sub.-- FFILE

SCAN.sub.-- FFILE.sub.-- LINE

PCFCOM.sub.-- SCAN

PCF.sub.-- SCAN

COMM.sub.-- PROC

ASSIGN.sub.-- DFILE

Code.sub.-- gen

PCF.sub.-- REPL.sub.-- FRAME

GET.sub.-- CHAR

READ.sub.-- LINE

ABORT

Warning

CLOSE.sub.-- FILES ##SPC3##