Automatic Constraint Generation for Boundary Scan Interconnect Tests

Transcription

1 Automatic Constraint Generation for Boundary Scan Interconnect Tests Kendrick Baker Rick Borton Raytheon Company McKinney, TX ABSTRACT This paper discusses an algorithm to automate the generation of constraints files by leveraging a simple extension to the device characteristic model. This extension consists of additional pin-level restriction data that defines the test constraints. While additional constraints based on the unique features of the design may still be required, the component-based constraints can be quickly determined and the corresponding file quickly generated by this process. All required design information is gathered from files already used in the interconnect test generation process. Since the pin-level restrictions apply to each instance of that component in the design, they will be declared in the component's characteristic model. The pin restriction information in the component characteristic models is the only information that will not be present in a typical test generation process. No other modifications to any files are required, which greatly reduces the effort required in generating the constraints. 1. INTRODUCTION Many steps in the process of generating boundary scan interconnect tests are automated. The test vectors are generated by (commercial) software. Figure 1 shows some of the major components involved in the test vector generation process. The BSDL (Boundary Scan Description Language) files describe the boundary scan architecture for the boundary scan devices. The device characteristic models (one for each type of device in the design) give basic information about the device pins, as well as certain transparency and power information. The netlist defines which devices correspond to which characteristic models, as well as how the pins of those devices are connected. The test vectors are generated using this information. In addition, the software takes into account any constraint information provided. Constraints hold a signal (in this case one with a boundary scan device pin) at a constant value throughout the test. They are used either to put the board into a safe state for the test or to improve the test coverage by reducing any interference from non-boundary scan devices present during the test. Figure 1 - Current Vector Generation Flow Device Models BSDL Netlist Constraints File Automatic Interconnect Test Generation Test Vectors This constraint information pertains only to signals accessible from boundary scan devices. It consists of signals that need to be driven to certain values, to remain undriven (by boundary scan devices), or to expect a particular value. It also lists pins that, although they are output pins, are safe to drive (because the state the board is being put into during the test disables them). Sometimes these constraints are referred to as logical constraints. While much of the process is automated, typical test generation flows require the manual development of the constraints file. However, most, if not all, of the constraints for a test can be determined based on the type of components being used rather than design-specific boardlevel information. These component-based constraints will apply to all instances of the component in the design. The automatic constraint generation (ACG) algorithm proposed in this paper is designed to take advantage of the component-based constraints to automatically create a logical constraints file (quickly and effectively). The dotted 1

2 Figure 2 - Proposed Vector Generation Flow Device Models Automatic Constraint Generation Constraints File Constraints File automatically generated Device Models modified to contain additional pin restriction information BSDL Netlist Automatic Interconnect Test Generation Test Vectors lines in figure 2 show how the new process uses the same input files (although the characteristic models contain additional information) to create the constraints file automatically. In addition, the algorithm modifies the netlist to include power net information, which would normally be inserted manually. 2. ACG ALGORITHM INPUTS Characteristic Models Characteristic models contain information about the device pins, power pins, and transparencies. Each pin on the device is listed as an input, an output, or both, although pins on connectors will not be listed as either. In addition, the power pins of the device (if it has any) are listed. If the device has transparencies, such as non-inverting buffers or resistors, the model will contain data on which pins are transparently connected. See Appendix I for examples of characteristics models. The algorithm begins by analyzing each component characteristic model for pin restriction, power, and transparency information. Any such data found in the model is recorded for later use with instances of the device that are located in the netlist. Output pins for the device are also recorded. Power and transparency information is already part of the models. Pin restriction data is the only data that may need to be added for this algorithm. The power architecture of the design will be analyzed based on power pin declarations of the component characteristic models. Therefore it is important to have at least one pin in each power net declared as a power pin in the component characteristic models. Otherwise, the algorithm may misunderstand the power architecture. Transparency information is also expected in the characteristic models. This is information regarding net equivalencies (nets that are connected and can be considered one net for test purposes). For instance, a series resistor will create a net equivalence between the two nets it touches. Likewise, buffers create a unidirectional equivalence between the drive and receive nets. This equivalence may be conditional if it requires the activation of one or more enable signals. Transceivers and switches are some other examples of transparent devices (that are also usually conditional). Pin restriction data is added to the model to determine what constraints should be implemented in the constraints file. They also contain information about why the constraint should exist, which helps determine priorities when conflicts arise. There are four types of pin restrictions considered in this algorithm. Since the pin restriction data is not part of the characteristic model language, the syntax will need to be determined when the algorithm is implemented. Boundary Scan Pin Restrictions Disabled Pins Pin Restrictions Constant Input Pin Restrictions Constant Output Pin Restrictions The first type of pin restriction data consists of constraints to enable boundary scan to work properly on the device during the test. Some devices use compliance enable pins or otherwise do not allow required instructions (such as EXTEST) to be used in certain conditions. This pin restriction indicates that the input pin(s) needs to be constrained to a certain value in order for the device to use boundary scan properly during the test. Even if no compliance enable pin is present, boundary scan devices should contain the pin restriction so that the ACG algorithm knows that 2

3 this is a boundary scan device. In this case, the pin restriction would exist, but not list any compliance enable pins. Figure 3 shows a boundary scan device with a compliance enable pin that needs to have a constraint met. This is the only pin restriction a boundary scan device will have, as any others can be handled by the test vector generation software. Likewise, only boundary scan devices have this restriction. The third type of pin restriction is to declare that an input pin will need to receive a certain value throughout the test. For example, a reset input may need to be kept inactive during the test so that the device remains in a particular state. Figure 5 shows an example of a watchdog timer that should have its input reset pin held constant throughout the test. Figure 6 - Constant Output Pin Restriction Figure 3 - Boundary Scan Pin Restriction Compliance Enable Pin(s) (PROGRAM) Boundary Scan Device (FPGA) Non- Boundary Scan Device (Timer) Output Pin (TIMEOUT) Figure 4 - Disabled Pins Pin Restriction Output Enable Pin(s) (CHIP SELECT) The second type of pin restriction exists to disable outputs. For instance, often a part will not drive its outputs if the chip select pin is deasserted. Figure 4 shows an example of a memory device with an output enable pin that prevents the memory from driving the data bus. This constraint requires information on which input pin(s) to hold at what value, as well as which output pins are then safe to be driven externally (from boundary scan devices). Figure 5 - Constant Input Pin Restriction Input Pin (RESET) The devices used and the nets present in the design are obtained from the netlist. As the netlist is read to determine what devices are present, any boundary scan device located will be associ- Non- Boundary Scan Device (Memory) Non- Boundary Scan Device (Timer) Disabled Pins (DATA) The final type of pin restriction is to declare that an output pin will always drive a certain value during the test. For instance, a reset output may be active through the test. By noting it in the constraints, the test vectors can at least check that the correct value is being driven from the device. Figure 6 again shows a timer whose reset output will remain inactive throughout the test. BSDL A mapping of boundary scan pins is needed, so that the ACG algorithm knows which nets have boundary scan inputs or outputs. This can be gleaned from the individual BSDL files, from a design file containing cell data for the boundary scan chain (position file), or even from a device characteristic model. While the pin information could be gathered from the device characteristic model, this would not let the algorithm know anything about the cell positions for those pins. Since the algorithm presented does not generate any vectors, no data on cell positions is required. However, future enhancements may generate vectors (such as initialization vectors), and therefore it would be prudent to have the necessary structures in place to support that. Netlist 3

4 ated with its pin map. When the pins are later read in, this pin map will be used to determine which pins are inputs and which are outputs. Once the devices have all been located, the nets are examined. As each net is being read in from the netlist, each pin in the net is examined for pin restrictions, power pins, or possible transparencies (all from the characteristic model data for that device). If any such information is found, the net is included for later analysis. If not, the net is ignored, even if it has a boundary scan input or output. The net is ignored because there is no pin restriction to meet and no transparency to another net that might have one. 3. ACG ALGORITHM After each net has been reviewed, all nets that were included for analysis have any transparencies resolved. If the net has a transparent device pin (if the net is equivalent to another net), the algorithm determines all possible driver and receiver equivalent nets. For instance, a buffer can only drive on one pin and only read on the other. However, if a net has a resistor, it marks each net as being able to both read from and drive the other net as long as one of the nets is not a power net. Nets that enable a conditional transparency will also be noted. Once the transparencies are determined, the nets are sorted by pin restriction type into separate lists. If a net contains multiple pin restrictions, it may be sorted into multiple lists. There is an additional list for all nets with power pins and nets without any pin restrictions. The latter are only included for analysis because they contain potential transparencies. After the nets have been sorted, they are then analyzed. Each list of nets is analyzed separately in the following order: Power Analysis Power nets and nets with no pin restrictions Driven Pin Analysis Constant Output Pin Restrictions Requested Drive Net Analysis Boundary Scan Pin Restrictions Disabled Pins Pin Restrictions Constant Input Pin Restrictions Power Analysis The first set of nets to be analyzed are the power (and transparent) nets. If a net is a power net, then any "downstream net" (with exceptions) is marked as a power net. A "downstream net" is any net that is connected to the current net by one or more transparencies and can be driven by the current net. All nets with power pins, as defined in the device characteristic models, will be considered power nets regardless of the characteristics of the net. However, certain downstream nets will not be considered power nets. Any downstream net that is connected to the power net by a resistive transparency (resistor) is considered a pull-up or pull-down, and will not automatically be marked as a power net. Only if the downstream pull-up or pull-down net has only one resistive transparency and no outputs will the downstream net be marked as a power net. Vcc Power_1 Net Figure 7 - Power Net Analysis Example Pull-up (inherits Power_1) Device 1 Device 2 Inherits Power_0, enables buffer Active buffer forces net to inherit Power 1 Voltage Dividing Net Power_0 Net Pull-down (doesn't inherit Power_0 due to Device 1's output) 4

5 Any downstream pull-up or pull-down net with more than two resistors is not considered a power net (nor capable of being one). This is because of the possibility of a voltage divider circuit, where the net is not driven to a logic-1 or a logic-0. The logic level of that net cannot be guaranteed to match that of the power net. Likewise, any downstream pull-up or pulldown net with an output will not be a power net. Since there are outputs present, the power net will not always drive the downstream net. It will only be considered a power net in the absence of a driven value from the output pins on the net. A net that is driven by a power net through a transparency other than a resistor, such as a buffer, is considered a power net regardless of the number of resistors present. This is because the buffer will be able to drive the net to the given power level. If a net is marked as both a POWER_0 and POWER_1 net, a conflict exists. If there is a conflict of power, the algorithm assumes that the net is a POWER_0 net. This conflict is noted in the log, however, as this violation is indicative of a design flaw or inaccurate input information. Note that the voltage dividing net in figure 7 will not be in this category. Since it contains more than one resistor, it will not inherit power from any other nets (POWER_0 or POWER_1). The marking of downstream nets is a recursive process. For each marked net immediately downstream of the current net (meaning the two are directly connected by one transparent device), the process reiterates. Figure 7 shows a sample circuit and how the algorithm would handle the different situations. Each net that is marked as a power net must also be analyzed for enabling other equivalencies. If the net has been marked as an enable net, the algorithm must determine if the transparency has been forced on (or off). For instance, if a buffer's output enable were connected to the proper power net, it would need to be marked as active (creating a transparency between the drive and receive nets). Since the enable pin is connected to a power net, it is assumed that nothing else can disable this gate, so it is locked from being modified in the future. In the case of multiple enable pins for a conditional transparency, all pins must have the correct value before the transparency will be activated. Driven Net Analysis Some nets are constrained because there is a pin on that net that will always be driving a certain value throughout the test. Once all power nets have been marked, nets with these constraints are examined. If the net is also a power net, and if the power net is a different value than that driven by the constrained pin on the net, a violation occurs. This is another problem that should not occur in a good design, but may occur if the design is flawed or if the input information was inaccurate. A violation will also occur if the net is constrained to drive conflicting values by different pin restrictions. Figure 8 - Driven Net Analysis Example Constraint unmet (no boundary scan inputs to detect driven value) Both output pins drive logic-1 Device 1 Device 2 Non-Boundary Scan Device Device 3 (BS) Boundary Scan Device Constraint met (boundary scan input can detect driven value) 5

6 If there is a constraint on the net that has not been violated by power nets, it is then evaluated in the same manner as power nets. Downstream nets are marked as also needing to meet the constraint and are checked for boundary scan inputs. If no boundary scan inputs can be found (in the constrained net or any downstream nets), then the constraint is considered "unmet", and will be commented out in the constraints file. However, this does not mean that the value will not still be driven during the test. It only means that it cannot be detected by a boundary scan device during the interconnect test. If boundary scan inputs are found, the constraint is marked as met, and will be added to the constraints file. Figure 8 is a sample circuit to demonstrate how these types of pin restrictions are handled. This list of nets is similar to the power net list in that there is nothing the test can do to prevent these nets from having driven values. For this reason, these two classes of nets are analyzed before the others, since both may be considered as unchangeable. Therefore, if an enable net is driven by this type of constraint, it will also be marked as forced active or inactive. It will then modify conditional equivalencies as required, using the same procedure that the power nets used. Requested Drive Net Analysis The remaining constraints all require some value to be driven from somewhere else on the net (either by power nets or by boundary scan outputs). Since there are different reasons these pin restrictions may have been specified, they are checked in order of importance. These constraints are grouped into three different lists (in the earlier sorting process), each corresponding to the reason for the constraint. The most important of the three constraint types is the one to get the boundary scan devices working correctly. Therefore, this is the first list of the three to be analyzed. The next most important type of constraint is the one that disables non-boundary scan outputs because it can improve coverage with a good return (one pin held constant may enable many pins to be driven). For this reason, the disabled pins pin restriction list is the second list to be analyzed. If there are any other reasons why a device needs its input pin driven to a certain value for the duration of the test, it is considered less important than the other two reasons. Therefore, the constant input pin restrictions list is the third (and final) list to be analyzed. Although the three lists are analyzed one at a time, the process for each list is the same. Figure 9 demonstrates how the pin restrictions are analyzed. Each constraint in the list is checked to see if it is already driving some value. This could be done by a power net or by a previously evaluated (and met) constraint. If there is a value being driven already, it will either meet or violate the constraint. The constraint will be met if the value driven is the same as that desired by the pin restriction, and violated if it is different. At this point, if the net has met or violated all constraints, the next net in the list will be evaluated. Figure 9 - Requested Drive Net Analysis Example Net inherits requested drive constraint from Man_Rst Constraint met by boundary scan output Boundary Scan Device Device 1 (BS) Device 2 Man_Rst Non-Boundary Scan Devices Constraint met by power DATA CE CS Device 3 DATA Outputs disabled by met constraint (can be driven by Device 1) Constraint met (boundary scan output can drive the requested value) 6

7 If the constraint has not yet been met or violated, then the net is checked for non-boundary scan digital outputs. If any exist, they may be driving at the same time we try to drive any boundary scan outputs to meet the constraint. Therefore, unless those non-boundary scan outputs are known to be off (disabled from a pin restriction) the algorithm will consider the net constraint violated. If the non-boundary scan digital output pin can be disabled by a constraint, the control net for that output pin is immediately checked to see if it can meet the disabled pin constraint (by following the requested drive analysis procedure being outlined). If the disabled pin constraint is met, then analysis of the current constraint will continue. Otherwise, it will be marked as violated and the next constraint in the list will be analyzed. If the constraint for the net has still not been met or violated, it can only be met if there is a boundary scan output pin that can drive the net. Since upstream nets are also capable of driving the net, a boundary scan output on the net itself or an upstream net will meet the constraint. The algorithm tries to drive from the net furthest upstream, if possible. Therefore, in a manner analogous to the previously discussed lists, upstream nets are marked as needing to meet the constraint. These upstream nets are recursively checked for meeting or violating the constraint with previously analyzed constraints. Beginning with the furthest upstream net, if the constraint has not yet been met or violated, it is checked for the presence of boundary scan output pins. If these outputs are not found, the constraint (for this upstream net only) is marked as unmet. Otherwise, a check is made to see if the net (the current upstream net and all of its downstream nets) is an enable net that might activate any conditional transparencies. If meeting the constraint would activate any conditional transparencies, some additional analysis is required. If activating the transparency will violate any previously met constraints, the transparency may not be enabled. Instead the constraint is marked as violated (on the net with the pin restriction and all upstream nets), and the net is not allowed to activate the transparency. If activating the transparency will not violate any previously met constraints or if no transparencies would be enabled by meeting the constraint, all conditions for meeting the constraint have been met. Boundary scan outputs have been found to drive the net, so the constraint is marked as met for this upstream net, the net with the pin restriction, and all nets in between. If the constraint is not met by the furthest upstream net, other upstream nets and eventually the originally constrained net itself will be recursively checked for boundary scan output pins. If no boundary scan outputs are found on any of these nets, then the constraint cannot be met (with the possible exception of activating conditional equivalencies), and is marked as "unmet". A comment will be made in the constraints file to signify that the constraint was requested by the pin restriction but cannot be met. Otherwise, the constraint will be added to the constraints file. If the constraint is met and is a pin restriction that disables output pins, then the output nets are marked as disabled. If more than one enable pin must be constrained in order to disable the outputs, then all enable pins must have their constraints met for the outputs to be marked as disabled. It is also possible that there are multiple enable pins available but only one is required to be constrained in order to disable the outputs. An example of this is a memory that can have the data lines disabled by either the chip select pin or the output enable pin. If this is the case, then once one of those constraints is met the others will be removed from the disabled pins pin restriction list. This will prevent the test from being over-constrained (constraining nets unnecessarily). 4. ACG ALGORITHM OUTPUTS Constraints File Generation The output of the algorithm is the constraints file. In addition, there can be a log. For test generation flows that require the power nets to be declared in the netlist, these nets can also be added by the algorithm. Only the originally declared power nets will be claimed in the netlist. Nets that inherited power (such as pulled-up nets) will not be listed. Since each constraint existed in one or more lists, each of the four constraint lists is now examined to determine what has and what has not been met. The power and transparency list is not considered at this point, since those were only used to help determine which constraints could be met. Each constraint in each list is checked to see if it has been met, violated, or is "unmet". Any net that could meet a constraint is marked in the constraints file as either expecting 7

8 Figure 10 - Current Limitations Example Devices 2, 3, and 4 all have disable constraints on their input pins. Device 1 (BS) CS CS Device 2 Device 3 Only one of these two devices can have their constraint met since they require opposite values on the constrained net. Which constraint should be met? CS Device 4 This constraint can only be met if the buffer is enabled. The algorithm does not currently enable the buffer since the enable line has no other constraints or power. or driving a certain value. It is possible that the net's constraint could meet multiple pin restrictions, but it only needs to be printed once. In this case, there should still be a separate comment for each pin restriction met. Likewise, any constraint that could not be met should be listed, but commented out. In addition, the file should contain a comment as to why the constraint was not met, such as being violated or being a constraint that cannot be met by power nets or boundary scan devices. Finally, any of the disabled outputs are printed. 5. LIMITATIONS / ENHANCEMENTS Currently, the algorithm does not attempt to enable any transparencies, except those enabled by a power net or as a side effect of a constraint being met. It would be useful to expand the algorithm to determine when to activate conditional equivalencies from a boundary scan device, as alluded to previously in the analysis algorithm. There are some cases in which constraints are not considered met, but could be if a transparency was enabled. Figure 10 shows an example of this situation. This enhancement would allow the tool to make decisions about which buffers to enable or disable in order to meet the most (or else the most important) constraints. However, even if the constraints are not marked as met, the constraint is present in the constraints file as a comment. It is easy to uncomment the constraint, allowing for a reasonable workaround until the enhancement is made. To implement this enhancement, the algorithm would be modified at the point after checking all upstream nets for meeting or violating a drive constraint. If the constraint is unmet after all checks have been made, any conditionally equivalent upstream nets can then be checked to see if they can meet the constraint without violating other constraints. For this enhancement to be more effective, a second enhancement would be useful. The algorithm would have to know how to decide which gates to enable and disable to achieve the best results. What "best results" means is the term that would have to be defined. A more complex priority system would need to be developed for determining which constraints are most important to meet. Currently, the priority is simply determined by which class (or list) the constraint is in, and within a class there is no priority. Another decision-making benefit for this expanded priority system would be to determine which constraint to meet in the presence of conflicting constraints. For instance, perhaps driving a net high will enable disable outputs on one device but enable them on another, as in figure 10. If both were constrained to be disabled, one or more constraints will be violated (or at least unmet) regardless of which device's outputs are disabled. The new prioritization scheme would need to be able to determine which is the most useful constraint to meet. 6. RESULTS This algorithm has significant advantages over manual constraint generation. The primary goal of the tool was to reduce test development time. There are several factors to consider in determining whether this goal has been met. Some steps required by this process are not required in manual constraints file generation. This additional effort includes modifying the characteristics model to include the pin restriction data. Since this generally consists of one or two additional lines of data in the model (see 8

9 Appendix I for examples), this does not require much effort. The time required is on the order of minutes per pin restriction. This small effort can be reduced even more by using a repository of characteristic models that include the pin restriction data. In a practical sense, there will be a learning curve for using the tool, also. This is the time it will take the user to learn the syntax for the pin restrictions and how to interpret the log data (particularly for error messages). This will take around one to four hours, depending on how formal the training is and how familiar the user is with constraints. As mentioned in the previous section, there may be special cases where the tool does not consider the constraint met, although it could safely do so. In these cases, the test developer may also need to comment or uncomment certain lines in the constraints file. This additional time is spent to verify the constraints and then uncomment or comment some lines. However, verifying the constraints is important (and relatively quick), so it should be done even in manual generation. Commenting and uncommenting some lines does not require much time. The additional time spent is more than offset by the time saved from automating the process. Except to verify the constraints generated by the tool, there is no time required for the test developer to study the schematic and netlist to determine what constraints should exist. Constraints that are not met have an explanation as to why they were commented out, allowing quick verification of the generated file. Conflicts in desired constraints are found automatically, rather than by manual analysis of the design. Net names automatically match the netlist and do not have to be translated from the schematic's net names or traced through several equivalent nets to find the correct name for the portion of the net touching the boundary scan device. Typing is not required for the generation of the file, so typos and incorrect net or lead names will not be a problem (assuming the lead names were entered correctly into the models). Several variables affect the amount of time reduction in generating the constraints file. As discussed earlier, certain designs may require some manual corrections (consisting of commenting and uncommenting). The more corrections that are required, the longer it will take to make a completed file. The more pin restrictions that need to be made, the more time it will take to enter them into the models. Within Raytheon, the test developers who have used this tool have reduced the constraints file generation time by 65-80%. Inexperienced users saved more actual hours, since they take longer to generate the file manually. Board designs with many constraints tend to yield greater savings, as well, since the additional work required is much less than the work that no longer needs to be done by the test developer. 7. CONCLUSION We have proposed an automated process for generating constraints files. This process has significant advantages over manual constraint generation. The primary goal of the algorithm was to reduce test development time. An implementation of this algorithm has been demonstrated to achieve this reduced test development time on actual designs within Raytheon. Automating the process of generating constraints files is made possible by taking advantage of component-based constraints, which allows software to analyze the design for constraints rather than the test developer. These pin restrictions can be easily defined in files already used in the vector generation process. The technique has proved beneficial and has allowed greater automation of our boundary scan interconnect test development process. 8. REFERENCES [1] IEEE Std , "IEEE Standard Test Access Port and Boundary-Scan Architecture" [2] B. Eklow, R. Sedmak, D. Singletary, and T. Vo, "Unsafe Board States During PC-Based Boundary-Scan Testing", Proceedings of International Test Conference 2001, pp [3] G. Robinson and J. DeShayes, "Interconnect Testing of Boards with Partial Scan", Proceedings of International Test Conference 1990, pp APPENDIX I - Sample CHR models This appendix contains four characteristic models. They are in the Victory format, but the format is not required for the algorithm to work as long as the information is present in the characteristic models. The samples demonstrate how little extra effort is involved in adding the pin restriction information to the models. The added lines use syntax consistent with our implementation of the algorithm. 9

10 The first model is for a fictitious sample device called SAMPLE_DEV. This device has an output enable pin. When the output enable pin (pin 1) is low, the outputs are disabled. We want to disable these pins so that the vector generation software will drive those signals using boundary scan device output pins. %NAME SAMPLE_DEV %CHAR char SAMPLE_DEV, leads=11, type=digital; lead 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9, 10=10, 11=11; port input_leads = 1,3,4; port output_leads = 2,5,6,7,8,9,10,11; output output_leads input input_leads; power_0 3; power_1 4;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The following lines are not valid in the CHR! model language. They are commands used by! our implementation of the ACG algorithm! These lines will be stripped from the model! before it is used by the test vector generation! software.! These are the only two lines added to the model! to make it work with the algorithm. DISABLE: 1 = 0 2,5,6,7,8,9,10,11!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! %COMP SAMPLE_DEV The next model is of a boundary scan device. The IEEE instructions on this device will only work correctly when its compliance enable pin (pin 2) is high. We want to set this pin high so that our interconnect test will use this boundary scan device. %NAME SAMPLE_DEV2 %CHAR char SAMPLE_DEV2, leads=12, type=digital; lead 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9, 10=10, 11=11, 12=12; port input_leads = 2,3,4,12; port output_leads = 1,5,6,7,8,9,10,11; output output_leads input input_leads; power_0 3; power_1 4;! software.! This is the only line added to the model! to make it work with the algorithm. BS_MODE: 2 = 1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! %COMP SAMPLE_DEV2 The following model is of a sample buffer. This buffer has an enable pin (pin 2), which activates the buffer when low. This example has no extra lines added for use with the algorithm, and is only shown as an example of how transparency information would be presented in the model. %NAME SAMPLE_BUF %CHAR char SAMPLE_BUF, leads=5, type=digital, VICTORY_TRANSPARENT; lead 1=1, 2=2, 3=3,4=4,5=5; port input_leads = 2,3,4,5; port output_leads = 1; bool off1= H 2;!off when pin 2 high bool on1 = L 2;!active when pin 2 low power_0 3; power_1 4;!tristate when 'off1', send when 'on1' STATESET state1:t=off1, S=on1 TRISTATE 1;! pin 1 is a 3-state output ENABLE 2;! pin 2 enables a transparency output 1 (SET=state1) input 2,5; %COMP SAMPLE_BUF The following model is a resistor. It is included to show how resistive transparencies would look %NAME RES %CHAR char RES, leads=2, type=analog; lead 1=1, 2=2; output 1 input 2; output 2 input 1;!POS and NEG not used by software or ACG algorithm r RESISTIVE POS=1 NEG=2; %COMP SAMPLE_BUF!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The following lines are not valid in the CHR! model language. They are commands used by! our implementation of the ACG algorithm! These lines will be stripped from the model! before it is used by the test vector generation 10