AUTOMATIC TEST ENVIRONMENT SETUP
A Project
Presented to the faculty of the Department of Computer Engineering
California State University, Sacramento
Submitted in partial satisfaction of the requirements for the degree of
MASTER OF SCIENCE
in
Computer Engineering
by
Trupti Deepak Naik
SPRING 2015
AUTOMATIC TEST ENVIRONMENT SETUP
A Project
by
Trupti Deepak Naik
Approved by:
______, Committee Chair Fethi Belkhouche, Ph.D.
______, Second Reader Preetham Kumar, Ph.D.
______Date
ii
Student: Trupti Deepak Naik
I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the Project.
______, Graduate Coordinator ______Nikrouz Faroughi, Ph.D. Date
Department of Computer Engineering
iii
Abstract
of
AUTOMATIC TEST ENVIRONMENT SETUP
by
Trupti Deepak Naik
Manual verification in industry testing is a very complex and tedious process.
Verification test engineers need to carefully go through various application screens, make the correct oscilloscope setups to get the expected results, try various input combinations and compare the results with the expected behavior. Furthermore, this type of testing is repetitive in nature. With the introduction of the new chips and/or new firmware releases, Automatic Test Environment (ATE) is becoming widely used to address the limitations of the traditional verification testing methods.
This project focuses on creating an automated test environment for Solid State
Devices (SSD) hardware verification testing. The project will contribute in making the tedious process of manual testing simpler and more time efficient for verification engineers. The project is implemented using Python Scripting Language and Test
Environment Suite libraries from Agilent Command Expert tool. It sends Standard
iv
Commands for Programmable Instruments (SCPI) commands to instruments like
Oscilloscope, power supplies, etc. The project automates both the test setup and the documentation of the test results.
______, Committee Chair Fethi Belkhouche, Ph.D.
______Date
v
ACKNOWLEDGEMENTS
I offer my sincere gratitude to my project advisor Dr. Fethi Belkhouche for helping me choose my project topic and for the time he spent with me during the entire project implementation. I would also like to thank him for guiding and correcting my project report. A special thanks to Dr. Preetham Kumar for reviewing my project report.
I express my thanks to the Computer Engineering department and all the faculty members without whom this project would have been a distant reality. I also extend my heartiest thanks to my family and my well wishers.
vi
TABLE OF CONTENTS
Page
Acknowledgements…………………………………………………………….……...... vi
List of Tables.....………………………………………………………………………...ix
List of Figures...……………………………………………………………………….....x
Chapter
1. INTRODUCTION………………………………………………………………..1
2. BACKGROUND…………………….……………………...………..…………..5
2.1 Overview of Manual Testing Procedure…….………………………..……5
2.2 Disadvantages of Manual Testing…………….…..…...... …...………...... 7
2.3 General Purpose Interface Bus (GPIB) History and Challenges...…...…….8
3. AUTOMATIC TEST SETUP ENVIRONMENT………..……………………..12
3.1 Architecture of Automatic Test Environment Setup…………..………….12
3.2 Agilent Command Expert Tool……………..…….……………...……….15
3.3 Advantages of Automatic Test Environment Setup…………….………...20
4. DEMONSTRATION OF AUTOMATION SETUP FOR TESTS……………...21
4.1 Power Consumption Measurement Test……….…...... ………………...... 21
4.2 Inrush Current Measurement Test…….……..……..…….…….………....30
4.3 Rail Switching Frequency Test…………..…….…..…………..……...... 40
4.4 Voltage Rail and Noise Test………….…….……………….....……….....46
4.5 Capacitor Hold Up Time Measurement Test….…….………...……....…..54
vii
5. CONCLUSION ……………………………………………………….………63
Appendix A Results…………………………………………………..……………64
Appendix B Source Code……...……………………...…...……………………....82
References…..……….…………………………………………….…………………96
viii
LIST OF TABLES Tables Page
1. Initial Expenditure in Automation Test Environment ………………………..………….2
2. Cost Benefit with Test Automation ………………………….…….………………….....2
ix
LIST OF FIGURES Figures Page
1. Manual Test Process Flowchart………...….…….…………….………………………….5
2. GPIB Measurement Setup …………………………………………………………….…..9
3. Architecture of Automatic Test Environment ………………………………………..….12
4. Instrument Communication Block Diagram ………………………………….………….14
5. Agilent Command Expert: Choose Connection Type………...………………….………15
6. Agilent Command Expert: Choose command set...………..…………………….……….16
7. Agilent Command Expert: Connect and simulate Option…..…………..….…………….17
8. Agilent Command Expert: SCPI Commands...…………………...…..………………….19
9. Power Consumption Measurement Test Setup …………………………………………..22
10. Automatic test environment (ATE) main window (GUI)………………………………..26
11. ‘Power Consumption Test’ input parameters..…………………..……………………….27
12. ‘Power Consumption Test’ default input parameters..…………………..……………….28
13. ‘Power Consumption Test’ HTML Report …………………………………..…………..29
14. Current waveform when SSD’s are powered up…………………..……………………..30
15. Inrush Current Measurement Test Setup.…………………………..…………………….32
16. ‘Inrush Current Test’ input parameters..……………………………….…….…………..34
17. ‘Inrush Current Test’ default input parameters..……………….…………..…………….35
18. ‘Inrush Current Test’ HTML Report ……………………………………...……………..37
19. ‘Rail Switching Frequency Test’ Test Setup ……………………………..……………...41
20. ‘Rail Switching Frequency Test’ input parameters..……………………….....………….43
x
21. ‘Rail Switching Frequency Test’ default input parameters..……………..…...………….44
22. ‘Rail Switching Frequency Test’ HTML Report ………………………..…..….………..45
23. ‘Voltage Rail and Noise Test’ Test Setup.………...………………….…….……...... 48
24. ‘Voltage Rail and Noise Test’ input parameters..……………….…………..…………...50
25. ‘Voltage Rail and Noise Test’ default input parameters.………..……………….………51
26. ‘Voltage Rail and Noise Test’ HTML Report …………………………..…….…………52
27. Block Diagram of SSD Power Back up System…………………….………………...….54
28. ‘Hold Up Time Test’ Test Setup.…………………...……..………..….……………..….56
29. ‘Hold Up Time Test’ input parameters..………………………….……….…..……..…..59
30. ‘Hold Up Time Test’ default input parameters.……….……………………….……...…60
31. ‘Hold Up Time’ HTML Report ………………………….…….……………………...…61
32. ATE: Power Consumption Test Result..…………………….…..…………..…………...65
33. ATE: Inrush Current Test Result: PASS.…………………………...…………..………..66
34. ATE: Inrush Current Test Result: FAIL ……………………………………….……...…69
35. ATE: Rail Switching Frequency Test Result: PASS…….……………...... …………..72
36. ATE: Rail Switching Frequency Test Result: FAIL…...……………………………...…74
37. ATE: Voltage Rail and Noise Test Result: PASS….…………………...………………..76
38. ATE: Voltage Rail and Noise Test Result: FAIL……………………………………...…78
39. ATE: Hold Up Time Test Result: PASS.……………….……………...……….………..80
40. ATE: Hold Up Time Test Result: FAIL ………………………………………………...81
xi
1
Chapter 1
INTRODUCTION
Verification and validation are the key factors that play a vital role in any hardware product lifecycle. These two techniques are required in the design, construction, operation and maintenance stages of any hardware development activity.
Verification and validation improve hardware quality and help deliver the best possible hardware to the users.
In the field of Computer Engineering, verification engineers establish validation environments and test suites. They are typically responsible for creating validation standards, developing test protocols, implementing test protocols, analyzing test results and documenting the results for further analysis. Their duties also include maintaining the equipment used for testing and optimizing test procedures.
Studies done on the benefit analysis of automation [Ref. 1], confirmed that automation benefits are substantial on the long run even when the initial expenditure is high. Table 1, illustrates cost analysis of automation during the initial setup and table 2 shows the benefits of automation. Even though the initial setup for test automation is costly, it can be observed that after the initial period, return on investment (ROI) on test automation is very high. Test engineers are not required to spend their valuable
2
time on repetitive testing. Automation will make significant amount of gain in test execution expenditure.
Table 1: Initial Expenditure in Automation Test Environment [Ref. 1]
Test Parameters Test Parameters
Test Type Automation Manual
Tool Cost $134,000 Zero
Cost of scripting/test design $30,000 $12500
Cost of executing/running test Zero $102000
Cost of maintenance $11,520 (24 weeks) Zero
Total $175,520 $114,500
Return On Investment -45.53%
Table 2: Cost Benefit with Test Automation [Ref. 1]
Test Parameters 2nd Year(2 cycles)
Test Type Automation Manual
Test Tool Cost Zero Zero
Cost of scripting/test design Zero Zero
Cost of executing/running test Zero $204,000 Cost of maintenance $23 040 Zero Total $23 040 $204,000
Return On Investment 135%
3
Automatic test environment also increases the depth and coverage of testing and helps in improving reliability by reducing human errors. It contributes in building efficient product by providing fast, repetitive and reusable test environment and hence reduces the overall cost of the product.
Typically in any hardware related testing; verification engineers spend the majority of their time on preparing test setups rather than actually executing test cases. So there is a need to go beyond automating test cases and implement automated test setup environment.
This project focuses on creating Automatic Test Environment setups for solid state drive (SSD) testing. Instruments will communicate with each other over Ethernet by making use of SCPI commands. It’s efficient to use SCPI commands to reduce the development time of the project. SCPI provides consistent environment for instrument control and data usage. This is very beneficial, as same commands can be used across all SCPI instruments for different manufacturers [Ref. 4].
For communicating with the host computers and developing the drivers, Graphical
User Interfaces (GUI) is developed using “Python” programming language. This is a user friendly language that emphasizes on the readability of code. This language
4
supports multiple programming paradigms. Python became one of the most efficient language because of its large and comprehensive standard library [Ref. 3].
5
Chapter 2
BACKGROUND
2.1 Overview of Manual Testing Procedure
Manual testing is an integral part of the testing process in industry where the test engineer examines the end product manually for any defects. This is required to ensure product reliability and make corrections before releasing the product to end users [Ref. 2]. Manual testing procedure in the typical semiconductor industry can be summarized with the following flowchart.
Figure 1: Manual Test Process Flowchart
6
The first step in the manual test process is requirement analysis. This is a process of determining the end user’s expectations for a new product or modifying the existing product. The requirements should be measurable, relevant and testable. This is also referred as “functional specifications”.
The formulation of the test procedure is the next step after the requirements have been finalized and documented. A team of engineers decides about the test strategies and the execution methods. These methods depend upon the Device under Test (DUT) specifications, set up requirements and expected test results. In this stage, design engineers and test engineers create and finalize the test methods and document them.
The test procedure document contains the set of instructions to carry out a particular test. This document also contains the expected outcomes of the test.
Environment setup for test case execution consists of creating suitable platform for executing tests. Every test has its own test setup environment. A complete setup consists of hardware setup which is referred to as the “physical setup” and software setup which includes the software required to run the test. For example, in noise test measurement, oscilloscope setup is a part of the hardware setup. Software setup is required to perform I/O operations to stress DUT by using tools like IOmeter. Tests are executed after completing the environment setup for the tests. If a test is not successful, multiple iterations of the test setups and test executions are carried out.
7
After the completion of the test, the results are documented. Test engineers also document test sightings and observations which helps in future testing of the same or other products.
Manual testing covers every aspect of the validation behavior against input provided for normal and erroneous behavior. Manual testing requires many skills. It’s mandatory for a verification Engineer to have all the required domain knowledge to perform any particular test. Testing of this type is always challenging as it requires continuous efforts from the test engineer.
2.2 Disadvantages of Manual Testing
Because of the nature of manual testing, it has several drawbacks summarized below [Ref. 2].
1. Less reliability – It’s difficult to perform the same test case execution multiple
times with the same precision.
2. Testing complexity is directly proportional to the complexity of DUT. If
testing is done manually, it increases time, resources and the total budget
devoted for testing.
3. Less accuracy – Even a skilled validation test engineer can make mistakes
during monotonous manual testing.
8
4. Running tests manually can be very time consuming. The test engineer has to
put equal amount of time to execute the same type of test again.
5. Comparing large amount of data manually is difficult. Manual testing is not
suitable for big and time critical projects.
6. It’s not feasible to use manual testing in complex scenarios like for example
running the same test on different machines with different operating systems
and DUT. Multiple test engineers may be required in that case.
7. Manual testing can become boring, the test engineer has to be patient and
creative. Lack of training is a problem for manual testing.
8. Variable efficiency is a major uncertainty in manual testing. Efficiency is
dependent upon the test engineer executing the test.
2.3 General Purpose Interface Bus (GPIB) History and Challenges
To make automatic test equipment (ATE) setup, in 1965, Hewlett-Packard (HP) designed the Hewlett-Packard Interface Bus (HP-IB). This bus was a very popular interface that connects instruments to a computer to form ATE. Today this bus is widely known as GPIB [Ref. 5].
GPIB was recognized as an IEEE standard in 1978. IEEE 488.1 was released to define GPIB hardware specifications. It defines functional, mechanical and electrical specifications and high performance protocols for the standard digital interface for
9
GPIB hardware specifications. This standard does not mention anything about communication protocols. Later in 1989, IEEE 488.2 was released to define the software specifications for GPIB. This specification states codes, commands and common formats that can be used over IEEE 488.1 specifications. GPIB is a very popular interface and is widely accepted by manufacturers [Ref. 6, 7].
Figure 2 – GPIB Measurement Setup [Ref. 5]
For measurement setup, the system controller must have a GPIB controller card. A system controller, usually Personal Computer (PC) or a workstation is connected to at least one instrument by using a cable. Connections can be stacked to connect all devices. GPIB controller card can be purchased from vendors like HP, National
Instruments and many others [Ref. 5].
GPIB is a transmission line system. To achieve an optimal data transfer rate of
GPIB, there is a limitation of physical distance between devices and also on the
10
number of devices connected to GPIB bus. IEEE 488.1 specifies following limits [Ref.
6].
1. “ Maximum separation of 4 meters between any two adjacent devices and an
average separation of 2 meters over the entire bus
2. Maximum cable length of 20 meters
3. Maximum of 15 loads/devices per bus (e.g., one board and up to 14
instruments), with at least two-thirds of the devices powered on”.
Command sets were not standardized for GPIB controlled ATEs. Manufacturers developed their own command sets for programmable instruments. This lack of standardization forced verification engineers to learn instrument specific command sets. It increased programming complexity and maintenance overhead. Over time,
Universal Serial Bus (USB) and Local Area Network (LAN) interfaces were developed and they proved faster, versatile and high speed performers. Also, GPIB bus controllers with Application-Specific Integrated Circuit (ASIC) were expensive
[Ref. 8, 9].
In 1990’s, a group of instrument manufacturers announced the SCPI specification.
This specification states common command set for programmable instruments regardless of the manufacturer. Also manufacturers came up with solution of bridge communication protocol from GPIB to USB or LAN. This gives compatibility with
11
old instruments having only GPIB interface. At the same time, all the advantages of
LAN and USB remain intact [Ref. 4, 9]
12
Chapter 3
AUTOMATIC TEST SETUP ENVIRONMENT
3.1 Architecture of Automatic Test Environment Setup
This project consists of automation of test cases and test setups that are commonly used for hardware verification testing of SSD’s. The automatic test environment architecture is shown in Figure 3.
Figure 3 - Architecture of Automatic Test Environment
13
The device under Test (DUT) for this project is a SSD manufactured by Micron inc. The DUT is connected to an oscilloscope using active or passive probes to measure the signals from the drive. Active probes are used for high speed signals with higher bandwidth while passive probes are used for higher dynamic ranges. Power supply provides required voltage and current to DUT. Data logger is used to record the electrical parameters on the SSD over a period of time. Electronic load is used for special tests on the SSD like – capacitor hold up time measurement test. Host PC communicates with the DUT to precondition the drive and run scripts to make the required test setup on instruments.
Graphical User Interface (GUI) is developed for interactive communication amongst multiple test setup components. It provides a template to gather test specifications and generates a Hyper Text Markup Language (HTML) report based on test results. The verification engineer will have to find the root cause in case of a failed test.
Instrument Driver
The instrument driver is required to control the hardware test instruments like the oscilloscope, data logger etc. According to reference 3, “An instrument driver, in the simplest definition, is a set of software routines that handle the programmatic details of controlling and communicating with a specific instrument”. This project uses
14
instrument drivers from ‘Agilent IO libraries suite’ to communicate amongst the instruments. Agilent IO library uses – “Interchangeable Virtual Instrument Universal
Serial Interface Test and Measurement Class” (IVI USBTMC) driver. Test automation scripts invoke SCPI commands which internally use IVI USBTMC driver [Ref. 10].
The block diagram of instrument communication is depicted in Figure 4.
Figure 4: Instrument Communication Block Diagram
The IVI USBTMC driver uses USBTMC protocol which allows GPIB like communications over USB. Also by maintaining IVI standards, instruments can communicate over Ethernet and PCI eXtensions for Instrumentation (PXI) interface.
This allows instruments to be interchanged in the system without modifying the calling program [Ref. 10].
15
3.2 Agilent Command Expert Tool
The agilent command expert tool provides fast and easy instrument control in integrated development environments. This is a free software application which is compatible with GPIB, RS-232, LAN and USB interfaces. It helps in creating SCPI commands and has add-ons for MATLAB, Python and Microsoft Excel.
There are two options for instrument connection in Agilent Command Expert tool.
This is shown in Figure 5. In ‘Connect to a real instrument’ mode the actual instrument has to be connected to the tool for testing. ‘Simulate an instrument connection’ option provides flexibility to try different SCPI commands without an actual hardware connection.
Figure 5: Agilent Command Expert: Choose Connection Type
16
The tool has built in command sets for supported instruments. The verification engineer selects the appropriate command sets from the list. Figure 6 shows an end user trying to connect with an Infitinium DSA 91604A oscilloscope.
Figure 6: Agilent Command Expert: Choose command set
17
After selecting the appropriate command set, the verification engineer identifies the instrument. This is mandatory as it ensures that the selected command set is compatible with the instrument. “Connect” or “simulate” option is chosen based on the mode selected in earlier step.
Figure 7: Agilent Command Expert: Connect and Simulate Option
18
The simulated active instruments are shown in orange as a dot in Figure 8. While the real active instruments are shown in green as a dot in Figure 8 under the active instruments tab. Verification engineers can send or receive SCPI commands on active instruments. SCPI commands are used for reading and writing instrument settings and for measuring data. The first three letters of the SCPI commands define the action and are written in capital letters. “Perform” is referred for sending commands to the instrument to make the setup (e.g. set trigger) while “Query” is referred for getting measurements from the instrument (e.g. current measurement, voltage measurement)
[Ref. 4].
19
Figure 8: Agilent Command Expert: SCPI Commands
20
The verification engineer can try different commands and then finalize the list of commands for the test setup of the instrument. All these SCPI commands are added in the automation script to make the required setup on different instruments.
3.3 Advantages of Automatic Test Environment Setup
Automatic test environment is balanced for its value and effort. It improves the long term development process of the product on the long run. Benefits are highlighted below.
1. Improved reliability: Test automation improves testing reliability by
eliminating human error.
2. High Performance: Tests can be repeated multiple times without much effort.
Automation runs tests significantly faster than human users.
3. Cost Reduction: Tremendous efforts for repeatable manual testing are
eliminated completely which benefits in cost reduction.
4. Reusable: Tests can be used again and again for different versions of the same
product.
5. Programmable: Verification engineers can program sophisticated tests that
bring hidden information.
21
Chapter 4
DEMONSTRATION OF AUTOMATION SETUP FOR TESTS
This chapter provides demonstration of all the tests carried out for ATE in separate sections namely power consumption measurement test, inrush current measurement test, rail switching frequency test, voltage rail noise test and capacitor hold up time measurement test. Each section briefly elaborates about the required instruments to carry out the test, test setup, manual test procedure, automatic test procedure and test results.
4.1 Power Consumption Measurement Test
Power consumption measurement is an important metric to measure the performance of SSD’s. SSD’s complete commands from host interfaces quickly. After completion of operations, SSD’s settle down into idle mode. SSD’s in laptops or personal computers spend most of their time in idle mode, as there is no heavy workload. On the other hand, for enterprise applications, like data centers, there is a heavy workflow and SSD’s are used at their full tilt for such applications. Therefore it’s necessary to measure power consumption for all modes of SSD’s [Ref. 12]. This test measures power consumption of SSD’s for idle, standby, device sleep and active mode.
22
Required Instruments
The following instruments are required to carry out this test.
Voltage Meter, or Digital Multi-Meter (DMM); Agilent Model 34410A
Data Logger: Agilent 34972A
PC
0.005 Ohm resistor 1% tolerance.
Test Setup
Figure 9: Power Consumption Measurement Test Setup
23
The setup to carry out this test is shown in Figure 9. The verification engineer needs to connect the 0.005 ohm resistor between the positive voltage supply of the
SSD which is DUT and the PC which is providing power supply to the SSD. A voltage meter or data logger is needed to measure the voltage drop across the resistor.
The average power consumption is calculated using following formula:
P = V*I (formula 1) where V = 5V (voltage supplied to the DUT)
I = current in amperes (Voltage sensed at the resistor in volts / 0.005 ohm)
Manual test procedure
A digital multimeter is user friendly and therefore preferred over data logger for manual testing. It is used to measure voltage across the resistor. Following are the steps to perform the power consumption measurement test manually.
1. Configure the DMM as follows:
a) Perform the following settings on DMM.
i. Go to “number of power line cycles” (NPLC) menu. Set NPLC =
0.006.
ii. Set Range = Auto.
iii. Set Input Z = HI-Z.
24
iv. Set Auto Zero = Once.
v. Set NULL = Off.
b) Set Stats on DMM.
c) Make the following settings for Trigger(Auto Trigger).
i. N Samples = 50,000
ii. Trig Delay = Zero
iii. Trig Slope = NEG (default)
iv. VMC Slope = NEG (default)
2. Attach the two DMM test leads together:
a. Depress the “Trigger” button.
b. View the stats count and allow the count increase up to 50,000.
c. Clear the stats.
3. Attach the voltage meter’s terminals to the 0.005 ohm resistor.
4. Energize the drive.
5. Connect the PC’s Serial Advanced Technology Attachment (SATA) link to the
DUT. Record drive-id, serial number, firmware and capacity of drive.
6. Set the DUT under power idle mode.
7. Wait approximately 2 minutes to allow the DUT to stabilize.
8. On the DMM within the Math menu, scroll until the “Count” field is visible.
9. Depress the “Trigger” key on the DMM.
a. 50,000 samples will be acquired.
25
b. Acquire 200,000 samples. This is accomplished by waiting until 50,000
samples are acquired and then depressing the “Trigger” button again.
Repeat until there are 200,000 samples.
10. Within the Math menu, scroll until the “Average” field is visible.
11. Calculate the average power consumption using formula 1.
12. Record the average power consumption and the maximum power consumption.
13. De-energize the DUT.
14. Repeat steps 4-13 for the other modes – stand by, device sleep, 128 sequential
writes, 128 sequential reads and 32Mbytes write.
The automatic test procedure is discussed below.
Automatic test process
1. Connect the PC’s SATA link to the DUT.
2. Run python script – “MainGuiCls.py” to perform – power consumption test.
After running this script GUI will pop up as shown Figure 10.
26
Figure 10: Automatic test environment (ATE) main window (GUI)
3. Click on “Power Consumption Test” button shown in Figure 10. The
verification engineer will need to enter the test parameters as shown in Figure
11.
27
Figure 11: ‘Power Consumption Test’ input parameters
4. Enter slot number and channel number of data logger to which the resistor
points are connected. Enter the resistor value as 0.005 ohm. Write serial
number, firmware version and drive id of SSD. Verification engineer can press
the “Default setup” button. This button will fill all required fields for test.
Default slot number is ‘01’; channel number is ‘1’ and resistor value in ohms
as 0.005 ohms. All the remaining parameters are related to the DUT. They are
measured from the DUT automatically and written into text fields as shown in
Figure 12.
28
Figure 12: ‘Power Consumption Test’ default input parameters
5. Click on ‘SUBMIT’ button.
6. HTML report will be generated automatically for result analysis.
Test Result
When a test is executed manually, verification engineers record all voltage values for all modes of SSD. Then calculate the power consumption using formula 1. The results are documented in table format.
29
Figure 13: ‘Power Consumption Test’ HTML Report
All these steps are automated in this project. The HTML report contains results analysis as shown in Figure 13. This test takes much less time to calculate the power consumption for all modes of SSD’s. Results are more accurate as human error is removed and data logger is used instead of digital multimeter which gives better accuracy.
30
4.2 Inrush Current Measurement Test
When SSD is turned on, large current flows through the circuit. The value of this current is higher than the normal operating current value. This current is called the inrush current. Figure 14 shows current waveform when the SSD’S are powered on.
Figure 14: Current waveform when SSD’s are powered up
Inrush currents are due to the charging of the input capacitors. High inrush currents are always a concern for SSD’s because the large current spikes may unintentionally trip a fuse on the bus or adversely affect adjacent circuitry. To avoid such disasters,
31
it’s always necessary to check that inrush current is within the specifications. This test measures inrush current of SSD at cold boot and hot plug.
Required Instruments
The following instruments are required to perform inrush current test.
Power Supply; 20A current capable - Manufacturer: Micron, Model: Sugar
Cane
Oscilloscope - Manufacturer: Agilent, Model #: DSO-X 3034A, DSO-X-
91604A or better.
Current Probe
PC
Test Setup
The oscilloscope is connected to the DUT by using current probe. Current probe will measure current through the DUT. For cold boot measurements, power supply is turned off and then turned on again. While during hot plug measurements, constant power supply is provided. The DUT is detached from PC and plugged in again to measure the current. The test setup is shown in Figure 15.
32
Figure 15: Inrush current measurement test set up
Manual test procedure
1. Power on the drive. Connect the PC’s SATA link to the DUT. Record drive-id,
serial number, firmware and capacity of drive.
2. Turn off the power supply.
3. Setup the oscilloscope as follows:
a. Voltage/Current scale: 200mA/div
33
b. Time scale: 1s/div
c. Resolution: 100kilo samples per second (or greater)
d. Add Measurement: Max current
f. Set the trigger to approximately 200mA
4. Turn on the power supply (5V and the maximum possible current).
5. Set the power supply’s output disabled.
6. Connect the power harness to the power supply and to the SSD.
7. Make sure the current probe has been degaussed.
8. Clamp the current probe to the positive lead of the power harness.
9. Depress “clear” on the oscilloscope.
10. Depress “single” on the oscilloscope.
11. Wait for the trigger on the oscilloscope to be “ready”.
12. Enable the output of the power supply.
13. Allow the oscilloscope to finish gathering the information (about 20 seconds).
14. Ensure the current peak(s) are visible on the screen.
a. If needed, adjust the voltage/current scale setting as needed and
repeat test.
15. Use the zoom feature to capture the width of the current peak.
34
Automatic Test Procedure
1. Run python script – “MainGuiCls.py” to perform inrush current measurement
test. After running this script, GUI will pop up as shown in Figure 10.
2. Click on ‘Inrush Current Test’ button. Enter test parameters as shown in Figure
16.
Figure 16: ‘Inrush Current Test’ input parameters
35
3. Enter the IP address of the oscilloscope which is used to perform the test.
Write all the details – boot type (cold boot/hot plug), maximum specifications
for inrush current in amperes and channel number (number of the channel -
1/2/3/4 to which probes are connected to DUT). Write serial number, firmware
version, board capacity and drive id of SSD.
4. User can press the Default setup button, which will fill all required fields for
test. This is shown in Figure 17.
Figure 17: ‘Inrush Current Test’ default input parameters
5. Press SUBMIT button.
36
6. Image will be captured from the oscilloscope of the inrush current test result.
Images will be saved on PC and HTML report will be generated and see
HTML report for result analysis.
Same procedure is followed for inrush current measurement for hot plug. The only difference is that during hot plug, instead of switching power supply; the DUT is detached from PC and attached again. Test results are in same fashion as for cold boot type. HTML report is shown in Figure 18.
37
Test Results
Figure 18: ‘Inrush Current Test’ HTML Report: Part 1- showing Test Result
38
Figure 18: ‘Inrush Current Test’ HTML Report: Part 2- showing Inrush Current
39
Figure 18: ‘Inrush Current Test’ HTML Report: Part 3- showing Peak Value
Automation of this test gives more accurate results as inrush current is captured on the oscilloscope over a period of 10 second after power up and automatically zooms out the image to show highest peak current for better resolution. This procedure eliminates human errors.
40
4.3 Rail Switching Frequency Test
Almost all SSD’s are manufactured on small sized printed circuit boards (PCB’s).
A space constraint is big challenge while designing SSD’s. So smaller switching regulators are generally used in SSD’s. In other words, a smaller inductor in both physical size and inductance value as well as less input and output capacitance is used.
This gives advantage in terms of space. But the penalty of using these types of regulator is the high switching frequency. The switching frequency is an operating parameter which affects every performance of SSD’s. So it’s mandatory to find out whether the switching frequency is within specified a range. This test measures switching frequency on the various voltage regulators of SSD’s.
Required Instruments
The following instruments are required to measure rail switching frequency on
SSD’s.
Power Supply
Oscilloscope - Manufacturer: Agilent, Model #: DSO-X 3034A, DSO-X-
91604A or better.
Voltage Probe
PC
41
Test Setup
Figure 19: ‘Rail Switching Frequency Test’ Test Setup
The test setup is shown in Figure 19. The SSD is connected to a PC to run the
IOmeter. The IOmeter will stress the drive to perform multiple vigorous read and
42
write operations. This is to keep the drive under maximum power consumption. A voltage probe is connected between regulator of SSD and ground.
Manual test procedure
1. Configure the oscilloscope as follows:
a. Add Measurements: frequency, period and maximum voltage
(Vmax) of the waveform.
b. Timescale = 1µS/div
c. Voltage scale = 2V/div
2. Power on the drive. Connect the PC’s SATA link to the DUT. Record drive-id,
serial number, firmware and capacity of drive.
3. Perform multiple IO operations on the drive by using the IOmeter.
4. For each rail switching frequency measured, capture an image of the waveform
on the oscilloscope.
5. Repeat steps 1 through 4 for all the rail switching frequencies to be measured.
Automatic Test Procedure
1. Run python script – “MainGuiCls” to perform Rail Switching Frequency Test.
After running this script a GUI will pop up as shown in Figure 10.
2. Click on Rail Switching Frequency Test button. Then end user will need to
enter test parameters as shown in Figure 20. Enter the IP address of the
43
oscilloscope used to perform the test. Write all the details for which voltage regulator, switching frequency is measured (e.g. – 3.3, 1.0, 1.8, 1.35 etc), maximum and minimum specifications for rail switching frequency and channel number (number of the channel - 1/2/3/4 to which probes are connected to DUT). Write board number, serial number, firmware version and capacity of SSD.
Figure 20: ‘Rail Switching Frequency Test’ input parameters
44
3. User can press Default setup button, which will fill all required fields for test
(optional). This is shown in Figure 21.
Figure 21: ‘Rail Switching Frequency Test’ default input parameters
4. Press SUBMIT button.
5. Image will be captured from the oscilloscope for the specified rail switching
frequency. HTML report will be generated which contain results analysis.
6. Repeat step 4 only in the case of multiple rail switching frequencies
measurements.
45
Test Result
A test report is shown in Figure 22. Test automation benefits the user by reducing repetition. For multiple measurements of switching frequency on the same board, verification engineer doesn’t need to configure the oscilloscope and stress drive multiple times. This will be done automatically and therefore it saves the efforts needed by the verification engineer for multiple runs of the same test.
Figure 22: ‘Rail Switching Frequency Test’ HTML report: Part 1- showing Test Result
46
Figure 22: ‘Rail Switching Frequency Test’ HTML report: Part 2- showing Waveform
4.4 Voltage Rail and Noise Test
Regulators on SSD’s come up with multiple ranges such as 5V, 3.3V, 1.8V, 0.9V etc. This is because different size transistors are placed on the PCB of the SSD. As the size of transistors shrinks, they operate on a lower voltage level. This test measures
47
voltages and signal waveforms on different regulator rails and checks whether they are within specified range [Ref. 13].
Required Instruments
The following instruments are required to measure rail switching frequency on
SSD’s.
Power Supply
Oscilloscope - Manufacturer: Agilent, Model #: DSO-X 3034A, DSO-X-
91604A or better.
Voltage Probe
PC
Test Setup
Test setup is shown in Figure 23. The SSD is connected to the PC to run the
IOmeter. The IOmeter will stress the drive to perform multiple vigorous read and write operations. This is to keep the drive under maximum power consumption. AC voltage probe is connected between the regulator rail of the SSD and the ground. The oscilloscope captures signal waveform on rail and measures the minimum, maximum, peak-to peak and average voltage of the signal.
48
Figure 23: ‘Voltage Rail and Noise Test’ Test Setup
Manual test procedure
1. Configure the oscilloscope as follows:
a. Add Measurements: maximum voltage (Vmax), average voltage
(Vavg), minimum voltage (Vmin) and peak to peak voltage (Vp-p)
of the waveform.
b. Timescale = 2µS/div
c. Voltage scale = 12mV/div
49
2. Power on the drive. Connect the PC’s SATA link to the DUT. Record drive-id,
serial number, firmware and capacity of drive.
3. Stress the drive by using IOmeter by performing multiple IO operations.
4. For each rail voltage measured, capture an image of the waveform on the
oscilloscope.
5. Repeat steps 1 through 4 for all the rail voltages to be measured.
Automatic Test Procedure
1. Run python script – “MainGuiCls” to perform Voltage Rail and Noise Test.
After running this script a GUI will pop up as shown in Figure 10.
2. Click on ‘Voltage Rail and Noise Test’ button. The end user will need to enter
the test parameters as shown in Figure 24. Enter the IP address of the
oscilloscope used to perform the test. Write voltage regulator rail being
measured (e.g. 3v3, 0v9, 1v8, 1v35 etc), maximum and minimum
specifications for rail voltage and channel number (number of the channel -
1/2/3/4 to which probes are connected DUT) .Write board number, serial
number, firmware version and capacity of SSD.
50
Figure 24: ‘Voltage Rail and Noise Test’ input parameters
3. User can press the Default setup button, which will fill all required fields for
test (optional). This is shown in Figure 25.
51
Figure 25: ‘Voltage Rail and Noise Test’ default input parameters
4. Press SUBMIT button.
5. Image will be captured from the oscilloscope for specified rail voltage. An
HTML report will be generated for result analysis.
6. Repeat step 4 only in the case of multiple rail voltage measurements.
52
Test Results
Figure 26: ‘Voltage Rail and Noise Test’ HTML report: Part 1 –showing Test Result
53
Figure 26: ‘Voltage Rail and Noise Test’ HTML report: Part 2 –showing Waveform
This test also benefits the user by reducing manual efforts in the case of multiple runs. Result analysis helps to find out whether the voltage is in the specified range.
This eliminates human efforts and the results are reliable.
54
4.5 Capacitor Hold Up Time Measurement Test
Generally, SSD’s use capacitors as back up source of energy in case of power failure. Capacitors along with buck-boost type converters are used in the backup system. This design is shown in Figure 27. Buck boost type converters provide output voltage of the same polarity with different range of magnitudes [Ref. 14].
Figure 27: Block Diagram of SSD Power Back up System
55
When power is turned off, the capacitor’s voltage starts dropping. But there is a certain amount of time required for a capacitor to discharge completely. This time is called the back up capacitor discharge time. This time should always be greater than the time required by the SSD to transfer essential data from fast DRAM memory buffer to non volatile flash memory. This test measures backup capacitors hold up time after power off – also referred as back up capacitor discharge time. This test verifies that capacitor’s hold up time is greater than the minimum specified hold up time.
Required Instruments
The following instruments are required to measure backup capacitors hold up time on SSD’s.
Power Supply
Oscilloscope - Manufacturer: Agilent, Model #: DSO-X 3034A, DSO-X-
91604A or better.
Voltage Probes- Manufacturer: Agilent, Model #: N5449A(for DSO-X-
91xxxx series only) + N2863B Passive Probes
PC
Electronic Load - Manufacturer: Chroma, Model: DC Electronic Load
03610-80-20
56
Test Setup
Figure 28: ‘Hold Up Time Test’ Test Setup
The DUT is connected to a power supply to get 5V supply voltage to energize the drive. The DUT is also connected to an oscilloscope to measure the voltage on 5V rail by using probes. The electronic load is connected to the 3V3 rail of the SSD. This electronic load constantly drains supply voltage provided by the 3V3 rail. The
Oscilloscope is connected to the 3v3 rail of the DUT to measure the voltage. The PC is
57
connected to the DUT via SATA link. The PC is connected to all other instruments via
USB or LAN interfaces. This connection is mandatory in case of automation.
Manual Test Procedure
1. Configure the oscilloscope as follows:
a. Set the voltage scale appropriately for each voltage rail.
b. Set the time scale appropriately to include all the voltage rails
waveforms.
c. Set trigger to the falling edge of the supply rail (5V) at about 90% of
the nominal voltage
2. Energize the DUT.
3. Connect the PC’s SATA link to the DUT. Record drive-id, serial number,
firmware and capacity of drive.
4. Set the load on the 3V3 as 1A.
5. With the setup complete as described above, depress the “Single Sequence”
button on the oscilloscope.
6. Power off the DUT.
7. On the oscilloscope
d. Place the first cursor on the point where the supply voltage just begins
to fall.
58
e. Place the second cursor on the point where the 3V3 rail voltage begins
to fall.
f. Take note of the time delta between the two cursors. This time, defined
as the “backup capacitor discharge time” should be greater than or
equal to the minimum required backup capacitor discharge time
specification.
g. Capture and save a screen snapshot of the oscilloscope for
documentation purpose.
h. Record the measured hold up time of the backup capacitor and place it
into the results table.
i. This procedure can be visualized by using oscilloscope screenshot
shown in Figure 31.
Automatic Test Procedure
1. Run python script – “MainGuiCls” to perform hold up time test. After running
this script, a GUI will pop up as shown in Figure 10.
2. Click on ‘Hold Up Time Test’ button. The end user will need to enter the test
parameters as shown Figure 29.
59
Figure 29: ‘Hold Up Time Test’ input parameters
Enter the IP address of the oscilloscope used to perform the test. Write all the details about the channel number of the oscilloscope (number of the channel -
1/2/3/4 to which probes are connected DUT) and the channel number of
Chroma-electronic load device. The device number is set to 1 if the agilent
60
oscilloscope is used for the test. Write the minimum required time as minimum
specified -“backup capacitor discharge time” and t-off condition. t-off
condition is the worst case voltage on the 3v3 rail, which is required to run the
circuitry of the SSD. Write the board number, serial number, firmware version
and capacity of the SSD.
3. User can press Default setup button, which will fill all required fields for test
(optional). This is shown in Figure 30.
Figure 30: ‘Hold Up Time Test’ default input parameters
61
4. Press SUBMIT button.
5. Image will be captured from oscilloscope for the specified t-off condition. An
HTML report will be generated for result analysis.
Test Results
Figure 31: ‘Hold Up Time Test’ HTML report: Part 1 showing Test Result
62
Figure 31: ‘Hold Up Time Test’ HTML report: Part 1 showing Waveform
The manual process of this test is very long and requires more time. Automation helps to achieve faster performance. Also, test results are consistent with multiple runs of the same test. This is not true for the manual process. The test performance and the consistency varied with the skill set of the verification engineer.
63
Chapter 5
CONCLUSION
Automatic test environments proved to be easier and more effective than traditional manual testing. The setups of all instruments are no longer hidden in long procedural documents nor are they dependent upon verification engineers skill set. Instead test setups become easy and controlled automatically. Verification engineers can spend their precious time in debugging new products rather than spending it on the making of the test setups. Also repetitive testing can be done within a short duration of time.
This project provides automatic test environment setup for hardware verification testing of SSDs. It covers power consumption, inrush current measurements, voltage rail and rail switching frequencies and capacitor holdup time measurement tests.
Automatic test environment achieves benefits such as increase in testing speed
(throughput), increase test coverage and the ability to start testing before actual hardware is present. Implementing this type of automated test suite in large environments will definitely improve testing process.
64
APPENDIX A
Results
Appendix A summarizes the test results for the power consumption measurement test, inrush current measurement test, rail switching frequency test, voltage rail and noise test and capacitor holdup time measurement test. It depicts passed and failed test scenarios for each test.
65
1. Power Consumption Measurement Test Result
Figure 32: ATE: Power Consumption Test Result
2. Inrush Current Measurement Test Result – Pass Scenario
66
Figure 33: ATE: Inrush Current Test Result: PASS– Part 1
67
Figure 33: ATE: Inrush Current Test Result: PASS– Part 2
68
Figure 33: ATE: Inrush Current Test Result: PASS– Part 3
3. Inrush Current Measurement Test Result – Fail Scenario
69
Figure 34: ATE: Inrush Current Test Result: FAIL – Part 1
70
Figure 34: ATE: Inrush Current Test Result: FAIL – Part 2
71
Figure 34: ATE: Inrush Current Test Result: FAIL – Part 3
4. Rail Switching Frequency Test Result – Pass Scenario
72
Figure 35: ATE: Rail Switching Frequency Test Result: PASS – Part 1
73
Figure 35: ATE: Rail Switching Frequency Test Result: PASS – Part 2
5. Rail Switching Frequency Test Result – Fail Scenario
74
Figure 36: ATE: Rail Switching Frequency Test Result: FAIL – Part 1
75
Figure 36: ATE: Rail Switching Frequency Test Result: FAIL – Part 2
6. Voltage Rail and Noise Test Result– Pass Scenario
76
Figure 37: ATE: Voltage Rail and Noise Test Result: PASS – Part 1
77
Figure 37: ATE: Voltage Rail and Noise Test Result: PASS – Part 2
7. Voltage Rail and Noise Test Result– Fail Scenario
78
Figure 38: ATE: Voltage Rail and Noise Test Result: FAIL –Part 1
79
Figure 38: ATE: Voltage Rail and Noise Test Result: FAIL –Part 2
8. Capacitor Hold Up Time Measurement Test Result– Pass Scenario
80
Figure 39: ATE: Hold Up Time Test Result: PASS
81
9. Capacitor Hold Up Time Measurement Test Result– Fail Scenario
Figure 40: ATE: Hold Up Time Test Result: FAIL
82
APPENDIX B
Source Code
#***********************MainGuiCls.py******************************************** # Main ATE window: GUI code******************************************************
from Tkinter import * import Tkinter from PIL import ImageTk import OctaneII import pywinusb import time
class ate_gui():# main ATE window GUI code def __init__(self): self.__create_gui()
def __create_gui(self): self.root = Tk() self.root.title("AUTOMATIC TEST ENVIRONMENT") self.root.configure(background="light blue") self.buttonframe = Frame(self.root) self.buttonframe.configure(background="light blue") self.buttonFg="dark green" self.w = 25 self.buttonframe2 = Frame(self.root)
self.l1 = Label(self.buttonframe, text="SELECT TEST OPTION",fg="dark blue",background="light blue",height = 2,font=("Calibri", 16)).grid(row=0, column=1,columnspan=4)
self.Inrush_button = Button (self.buttonframe, text="Inrush Current Test",width=self.w,fg=self.buttonFg,height=2,command=self.run_inrush_Test,font =("Calibri", 12)).grid(row=1, column=1,padx=5, pady=5)
self.sw_freq_button = Button (self.buttonframe, text="Rail Switching Frequency Test ",width=self.w,fg=self.buttonFg,height = 2,command= self.run_sw_freq_Test,font=("Calibri", 12)).grid(row=1, column=3,padx=5, pady=5)
self.power_button = Button (self.buttonframe, text="Power Consumption Test",width=self.w,fg=self.buttonFg,height = 2,command= self.run_powerConsumption_Test,font=("Calibri", 12)).grid(row=2, column=1,padx=5, pady=5)
self.quit_button = Button (self.buttonframe, text="Quit ",width=self.w,fg="dark green",height = 2,command= self.quit_win,font=("Calibri", 12)).grid(row=2, column=3,padx=5, pady=5)
img = ImageTk.PhotoImage(file = "ate.png") self.l5 = Label (self.buttonframe,image = img).grid(row=1,column=4,columnspan=4,rowspan = 2, padx=5, pady=5)
self.buttonframe.pack() self.root.mainloop()
83
def run_sw_freq_Test(self): #run rail switching frequency test self.buttonframe2.destroy() self.buttonframe2 = Frame(self.root) RailFreqGuiObj = OctaneII.RailSwitchFreq.RailFreqGuiCls.RailFreqGuiCls(self.root,2,self.buttonf rame2)
def run_inrush_Test(self): #run inrush current test self.buttonframe2.destroy() self.buttonframe2 = Frame(self.root) InRushObj = OctaneII.InRushAndChargeCurrent.InRushGuiCls.InRushGuiCls(self.root,2,self.but tonframe2)
def run_powerConsumption_Test(self): #run power consumption test self.buttonframe2.destroy() self.buttonframe2 = Frame(self.root) PowerConsumptionGuiObj = OctaneII.PowerConsumption.PowerConsumptionGuiCls.PowerConsumptionGuiCls(self.r oot,2,self.buttonframe2)
def quit_win(self): self.root.title(" ") self.root.destroy() ate_gui_obj = ate_gui()
# ATE image source************************************************************
#***********************Code for Inrush Current Test************************** # _init_.py******************************************************************* import InRushGuiCls, InRushTest
# InRushGuiCls.py************************************************************* # Create GUI for Inrush current measurement Test *****************************
84
from Tkinter import * import os import InRushTest import OctaneII class InRushGuiCls(): def __init__(self,root,rownum,buttonframe2): self.w = 45 self.buttonw = 25 self.rownum = rownum self.root3 = root self.buttonframe3 = buttonframe2 self.ipAddr = StringVar() self.bootType = StringVar() self.chNo = StringVar() self.maxSpec = StringVar() self.brdNo = StringVar() self.srNo = StringVar() self.fwVer = StringVar() self.brdCap = StringVar()
self.__create_railFreq_gui()
def __create_railFreq_gui(self): ### Gui execution self.root3.title("INRUSH AND CHARGE CURRENT TEST") self.root3.configure(background="light blue") self.buttonframe3.configure(background="light blue") self.buttonFg="dark green" self.l1 = Label(self.buttonframe3, text="INRUSH AND CHARGE CURRENT TEST REQUIREMENTS",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 16)).grid(row=0+self.rownum, column=1) self.l_button = Button(self.buttonframe3, text="DEFAULT SETUP",fg=self.buttonFg,width=self.buttonw, command = self.setValues, height = 2,font=("Calibri", 11)).grid(row=0+self.rownum, column=3,padx=5, pady=5) self.l1_button = Button(self.buttonframe3, text="SUBMIT",fg=self.buttonFg,width=self.buttonw, command = self.getValues, height = 2,font=("Calibri", 11)).grid(row=0+self.rownum, column=4,padx=5, pady=5)
self.ipAddr.set(" ") self.bootType.set(" ") self.chNo.set(" ") self.maxSpec.set(" ") self.brdNo.set(" ") self.srNo.set(" ") self.fwVer.set(" ") self.brdCap.set(" ")
l1 = Label(self.buttonframe3, text="IP Address Of Instrument",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=1+self.rownum, column=1) self.el2 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.ipAddr,width=self.w, font=("Calibri", 12)).grid(row=1+self.rownum, column=2,columnspan=3)
85
l2 = Label(self.buttonframe3, text="BootType[Cold Boot - 1, Hot Plug - 2]:",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=2+self.rownum, column=1) self.el3 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.bootType,width=self.w, font=("Calibri", 12)).grid(row=2+self.rownum, column=2,columnspan=3)
l3 = Label(self.buttonframe3, text="Oscilloscope Channel Number",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=3+self.rownum, column=1) self.el4 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.chNo,width=self.w, font=("Calibri", 12)).grid(row=3+self.rownum, column=2,columnspan=3)
l6 = Label(self.buttonframe3, text="Maximum Specifications(A)",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=4+self.rownum, column=1) self.el6 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.maxSpec,width=self.w, font=("Calibri", 12)).grid(row=4+self.rownum, column=2,columnspan=3)
l7 = Label(self.buttonframe3, text="Board Number",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=5+self.rownum, column=1) self.el7 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.brdNo,width=self.w, font=("Calibri", 12)).grid(row=5+self.rownum, column=2,columnspan=3)
l8 = Label(self.buttonframe3, text="Serial Number",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=6+self.rownum, column=1) self.el8 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.srNo,width=self.w, font=("Calibri", 12)).grid(row=6+self.rownum, column=2,columnspan=3)
l9 = Label(self.buttonframe3, text="Firmware Version",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=7+self.rownum, column=1) self.el9 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.fwVer,width=self.w, font=("Calibri", 12)).grid(row=7+self.rownum, column=2,columnspan=3)
l10 = Label(self.buttonframe3, text="Capacity",fg="dark blue",background="light blue",height = 2,width=self.w, font=("Calibri", 12)).grid(row=8+self.rownum, column=1) self.el10 = Entry(self.buttonframe3,fg="dark blue",textvariable = self.brdCap,width=self.w, font=("Calibri", 12)).grid(row=8+self.rownum, column=2,columnspan=3)
self.buttonframe3.pack() self.root3.mainloop()
def getValues(self): oscAddr = self.ipAddr.get() bootTypeT = int (self.bootType.get()) chNum = int (self.chNo.get()) maxSpec = float (self.maxSpec.get())
86
brdNo = self.brdNo.get() srNo = self.srNo.get() fwVer = self.fwVer.get() brdCap = self.brdCap.get() InRushTest.test (oscAddr , bootTypeT , chNum , maxSpec , fwVer , brdNo , srNo,brdCap)
def setValues(self): self.ipAddr.set("10.102.47.47") self.bootType.set("1") self.chNo.set("1") self.maxSpec.set("5") brdDetails = OctaneII.getFWDetails.getFWDetails() fwVer = "Monet Version:" + str (brdDetails['monetfw']) + "/MSP430 Version:" + str (brdDetails['msp430fw']) drCap = str (brdDetails['capacity']) + "G" serNo = str (brdDetails['serial']) self.brdNo.set("Octane II") self.srNo.set(serNo) self.fwVer.set(fwVer) self.brdCap.set(drCap)
# InRushTest.py*************************************************************** # Run Inrush Current Measurement Test***************************************** import Agilent import Power import time import webbrowser import datetime, os, sys import Tkinter import tkMessageBox def GetReportFolder(): return os.path.abspath(os.getcwd() + "\OctaneII\TestResult")
def CreateHtml(bootTypeT,MeasureVmax,maxSpec, fwver, boardName, serialNo, brdCap,scrName,scrName1,reportName): timenow = datetime.datetime.now()
reportNm = str (reportName) + ".html" imageNm = scrName + ".gif" imageNm1 = scrName1 + ".gif"
fo = open(reportNm, "wb") if (bootTypeT == 1): bootTypeS = "ColdBoot" elif(bootTypeT == 2): bootTypeS = "HotPlug" else: print "Wrong option for Boot Type" fo.write("") fo.write("
") fo.write("') fo.write("") fo.write('') fo.write("HW VERIFICATION REPORT - INRUSH AND CHARGE CURRENT TEST - %s
" % (bootTypeS)) fo.write("Board Name: %s
" % boardName) fo.write("FW Version: %s
" % fwver) fo.write("Date and Time:" + timenow.strftime('%m/%d/%Y %H:%M:%S') + "
") fo.write("Report Name:" + reportNm + "
") fo.write("TEST Result:
") fo.write("Specification -: Measured Inrush and Charge Current should be less than %f A
" % (float (maxSpec))) fo.write("Test Result -: Measured Inrush and Charge Current: %f A %s
" % (float (MeasureVmax) , "PASSED" if float (MeasureVmax) < float (maxSpec) else "FAILED")) fo.write("Inrush and Charge Current Waveform over 1 second Period
" ) fo.write("" ) fo.write("Zoomed Inrush and Charge Current Waveform showing Peak Value Details
") fo.write("") fo.close() def test(scopeIP, bootTypeT, channelNo , maxSpec, fwver, boardName, serialNo, brdCap): ### cold boot procedure if (bootTypeT == 1): Power.setPower(1) agilent = Agilent.scope(scopeIP) # make oscilloscope communication agilent.Reset() # set oscilloscope to desired values agilent.Acquire(2) ## type parameter for inrush and charge current test agilent.DisplayChannel(channelNo) agilent.DisplayVmax(channelNo) agilent.TimeScale(1) agilent.TimeDelay(2) agilent.ChanSet(channelNo,1,"5V Supply Current",0.2,None,0.2) time.sleep(5) agilent.SetTrigger(channelNo,0.15,0,1) agilent.SetSwTriggerButton() time.sleep(5) Power.setPower(0) Power.setPower(1) time.sleep(10)scrName = GetReportFolder() + "\InrushAndChargeCurWaveformColdBoot" reportName = GetReportFolder() + "\InrushAndChargeCurrentTestReport- ColdBoot" agilent.GetScreenShot(scrName + ".gif") wavef,pream = agilent.GetWaveform(channelNo)
maxArr,indexMaxArr = MeaurePeakWaveform(wavef)
88
xincrFloat = float (pream['xincr']) # x axis value for moving between two points tIdMax = indexMaxArr * xincrFloat tDelay = tIdMax + pream ['xorig'] agilent.TimeDelaySingle(float(tDelay)) agilent.TimeScale(0.0005) time.sleep(2) MeasureVmax = agilent.MeasureVmax(channelNo)
scrName1 = GetReportFolder() + "\InrushAndChargeCurPeakColdBoot" agilent.GetScreenShot(scrName1 + ".gif")
CreateHtml(bootTypeT,MeasureVmax,maxSpec, fwver, boardName, serialNo, brdCap,scrName,scrName1,reportName)
webbrowser.open(reportName + ".html")
### hot plug procedure if (bootTypeT == 2): tkMessageBox.showinfo("Disconnect the Drive", "Disconnect the Drive") Power.setPower(1) agilent = Agilent.scope(scopeIP) # make oscilloscope communication agilent.Reset() # set oscilloscope to desired values agilent.Acquire(2) ## type parameter for inrush and charge current test agilent.DisplayChannel(channelNo) agilent.DisplayVmax(channelNo) agilent.TimeScale(1) agilent.TimeDelay(2) agilent.ChanSet(channelNo,1,"5V Supply Current",0.5,None,0.44) time.sleep(5) agilent.SetTrigger(channelNo,0.15,0,1) agilent.SetSwTriggerButton() time.sleep(5) tkMessageBox.showinfo("Connect the Drive", "Connect the Drive") time.sleep(10) scrName = GetReportFolder() + "\InrushAndChargeCurWaveformHotPlug" reportName = GetReportFolder() + "\InrushAndChargeCurrent-HotPlug" agilent.GetScreenShot(scrName + ".gif") wavef,pream = agilent.GetWaveform(channelNo)
maxArr,indexMaxArr = MeaurePeakWaveform(wavef) xincrFloat = float (pream['xincr']) # x axis value for moving between two points tIdMax = indexMaxArr * xincrFloat tDelay = tIdMax + pream ['xorig'] agilent.TimeDelaySingle(float(tDelay)) agilent.TimeScale(0.0001) time.sleep(2) MeasureVmax = agilent.MeasureVmax(channelNo)
scrName1 = GetReportFolder() + "\InrushAndChargeCurPeakHotPlug" agilent.GetScreenShot(scrName1 + ".gif")
CreateHtml(bootTypeT,MeasureVmax,maxSpec, fwver, boardName, serialNo, brdCap,scrName,scrName1,reportName)
webbrowser.open(reportName + ".html")
89
def MeaurePeakWaveform(wavef): # find highest current index on waveform maxArr = wavef[0] indexMaxArr = 0 for i in range(0, len(wavef)): if maxArr < wavef[i]: maxArr = wavef[i] indexMaxArr = i return maxArr,indexMaxArr def main(argv): ## Take all required arguments for Test from the user ## pass type parameter = 1 for rail switching frequency test argv= [0] *9 argv[1] = "10.102.47.47" argv[2] = "1" argv[3] = "1" argv[6] = "20" argv[7] = "460" argv[8] = "Octane II" argv[9] = "099" argv[10] = "120G" if len(argv) < 10: print("Inrush and Charge Current Test Error: [ipaddr] [channelNo] [boottype] [maxSpec] [fwver] [boardName] [serialNo]") return scopeIP = argv[1] bootTypeT = int (argv[2]) channelNo = int (argv[3]) powerCh5V = int (argv[4]) powerCh3V = int (argv[5]) maxSpec = float (argv[6]) fwver = str (argv[7]) boardName = str (argv[8]) serialNo = str (argv[9]) brdCap = str (argv[10]) print("Inrush and Charge Current Test Started : [ipaddr] [channelNo] [boottype] [maxSpec] [fwver] [boardName] [serialNo]") test(scopeIP, bootTypeT, channelNo , maxSpec, fwver, boardName, serialNo, brdCap)
if __name__ == "__main__": main(sys.argv)
#*********************** Instrument Driver Codes****************************** #*********************** Oscilloscope Instrument Driver*********************** #Agilent.py import socket import time import struct import urllib,urllib2 import datetime, os, sys from bs4 import BeautifulSoup
### type 0 - Noise Test Setup
90
### type 1 - Rail Switching Frequency Setup class scope: PORT = 5025 def __init__(self, host, port=PORT, device=0): #device =0 DSA-X 91604A, device=1 DSO-X 3034A self.host = host self.s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.s.connect((host, port)) self.s.settimeout(2) self.device = device
def Reset(self): # reset and clear device self.s.send("*RST\n") self.s.send("*CLS\n")
def Autoscale(self): self.s.send(":AUToscale:CHANnels ALL\n")
def AutoscaleChannel(self): self.s.send(":AUToscale\n")
def MeasurePkPk(self, channel): self.s.send(":MEASure:VPP CHANNEL%d\n" % channel) self.s.send(":MEASure:VPP? CHANNEL%d\n" % channel) buf = self.s.recv(1024) return float(buf)
def MeasureVmax(self, channel): self.s.send(":MEASure:VMAX CHANNEL%d\n" % channel) self.s.send(":MEASure:VMAX? CHANNEL%d\n" % channel) buf = self.s.recv(1024) return float(buf)
def DisplayVmax(self, channel): self.s.send(":MEASure:VMAX CHANNEL%d\n" % channel)
def DisplayFreq(self, channel): self.s.send(":MEASure:FREQuency CHANnel%d,RISing\n" % channel)
def DisplayPersistanceInf(self): self.s.send(":DISPlay:PERSistence INFinite\n")
def MeasureFreq(self, channel): self.s.send(":MEASure:FREQuency CHANnel%d,RISing\n" % channel) self.s.send(":MEASure:FREQuency? CHANnel%d,RISing\n" % channel) buf = self.s.recv(1024) return float(buf)
def MeasurePeriod(self, channel): self.s.send(":MEASure:PERiod CHANnel%d,RISing\n" % channel) self.s.send(":MEASure:PERiod? CHANnel%d,RISing\n" % channel) buf = self.s.recv(1024) return float(buf)
def MeasureVmin(self, channel): self.s.send(":MEASure:VMIN CHANNEL%d\n" % channel) self.s.send(":MEASure:VMIN? CHANNEL%d\n" % channel)
91
buf = self.s.recv(1024) return float(buf)
def MeasureVavg(self, channel): self.s.send(":MEASure:VAVerage DISPlay,CHANnel%d\n" % channel) self.s.send(":MEASure:VAVerage? DISPlay,CHANnel%d\n" % channel) buf = self.s.recv(1024) return float(buf)
#slope : 0 = rise edge, 1 = fall edge, 2 = either, 3 alternate def SetTrigger(self, channel, level, slope=0, dev=0): if slope == 0: self.s.send("TRIGger:EDGE:SLOPe POS\n") elif slope == 1: self.s.send("TRIGger:EDGE:SLOPe NEG\n") elif slope == 2: self.s.send("TRIGger:EDGE:SLOPe EITH\n") elif slope == 3: self.s.send("TRIGger:EDGE:SLOPe ALT\n") self.s.send(":TRIGger:MODE EDGE\n")
if dev==0: self.s.send(":TRIGger:LTHReshold CHANNEL%d,%f\n" % (channel, level)) self.s.send(":TRIGger:SWEep TRIGgered\n") else: self.s.send(":TRIGger:LEVel CHANNEL%d,%f\n" % (channel,level)) self.s.send(":SINGle\n")
def SetSwTriggerButton(self): self.s.send(":TRIGger:SWEep TRIGgered\n")
def TimeScale(self, time): self.s.send(":TIMebase:SCALe %f\n" % time)
def TimeDelay(self, delay): self.s.send(":TIMebase:MAIN:POSition %f\n" % delay)
def TimeDelaySingle(self,delay): self.s.send(":TIMebase:POSition %f\n" % delay)
def Acquire(self, type): if type == 0: # rail voltage and noise self.s.send(":ACQuire:MODE HRESolution\n") self.s.send(":ACQuire:SRATe 100000000\n") self.s.send(":ACQuire:AVERage 1\n") self.s.send(":ACQuire:AVERage:COUNt 2\n") if type == 1: # rail switching frequency self.s.send(":ACQuire:POINts 1600000\n") if type == 2: # inrush and charge current self.s.send(":ACQuire:SRATe 100000\n") self.s.send(":TRIGger:HYSTeresis HSENsitivity\n") self.s.send(":ACQuire:POINts:AUTO 1\n") else: return -1
def Srate(self, srat): print("SRATE %f" %srat) self.s.send(":ACQuire:SRATe %f\n" % srat)
92
def DisplayChannel(self,channelNo): ### Deprecated if (channelNo == 1): self.s.send(":CHANnel3:DISPlay 0\n") self.s.send(":CHANnel1:DISPlay 1\n") self.s.send(":CHANnel2:DISPlay 0\n") self.s.send(":CHANnel4:DISPlay 0\n") elif (channelNo == 2): self.s.send(":CHANnel3:DISPlay 0\n") self.s.send(":CHANnel1:DISPlay 0\n") self.s.send(":CHANnel2:DISPlay 1\n") self.s.send(":CHANnel4:DISPlay 0\n") elif (channelNo == 3): self.s.send(":CHANnel3:DISPlay 1\n") self.s.send(":CHANnel1:DISPlay 0\n") self.s.send(":CHANnel2:DISPlay 0\n") self.s.send(":CHANnel4:DISPlay 0\n") elif (channelNo == 4): self.s.send(":CHANnel3:DISPlay 0\n") self.s.send(":CHANnel1:DISPlay 0\n") self.s.send(":CHANnel2:DISPlay 0\n") self.s.send(":CHANnel4:DISPlay 1\n") else: return -1
def Persistence(self,val): if val == 1: self.s.send(":DISPlay:PERSistence INFinite\n")
def ChanSet(self, channel,label = None, labelNm = None, scale=None, typeC=None, volt=None, bw=None): self.s.send(":CHANnel%d:DISPlay 1\n" % channel) if label!= None: self.s.send(":DISPlay:LABel %f\n" %(label)) if labelNm != None: self.s.send(":CHANnel%d:LABel \"%s\"\n" % (channel, labelNm)) if scale!= None: self.s.send(":CHANnel%d:SCALe %f\n" % (channel, scale)) if typeC!= None: self.s.send(":CHANnel%d:COUPling %s\n" % (channel, type)) if volt!= None: self.s.send(":CHANnel%d:OFFSet %f\n" % (channel, volt)) if bw!=None: self.s.send(":CHANnel%d:BWLimit %d\n" % (channel, bw))
def SetWaveSource(self, channel): self.s.send("WAVeform:SOURce CHANnel%d\n" % channel)
def GetPreamble(self): self.s.send("WAVeform:PREamble?\n") buf = self.s.recv(1024) buf = buf.split(',') return {'format': int(buf[0]), 'type': int(buf[1]), 'points': int(buf[2]), 'count': int(buf[3]), 'xincr': float(buf[4]), \ 'xorig' : float(buf[5]), 'xref' : float(buf[6]), 'yincr' : float(buf[7]), 'yorig': float(buf[8]), 'yref' : float(buf[9]) }
def GetData(self):
93
self.s.send(":WAVeform:POINts:MODE NORMal\n") if self.device == 1: self.s.send(":WAVeform:FORMat WORD\n") else: self.s.send(":WAVeform:FORMat ASCII\n") self.s.send(":WAVeform:DATA?\n") buf = '' while(True): try: buf += self.s.recv(1024) except: break return buf def GetWaveform(self, channel): self.SetWaveSource(channel) preamb = self.GetPreamble() #print preamb yref = preamb['yref'] yinc = preamb['yincr'] yor = preamb['yorig'] num = preamb['points'] raw = self.GetData() wavef = [0] * num
j=0 if self.device==1: for i in range(10,len(raw)-10,2): word = ord(raw[i])<<8 | ord(raw[i+1]) wavef[j] = (float(word) - yref)*yinc + yor j=j+1 else: buf = raw.split(",") for i in range(0, len(buf) -1 ): wavef[i] = float(buf[i]) return wavef, preamb def SetMarker(self, type): if type == 0: self.s.send(":MARKer:MODE OFF\n") elif type == 1: self.s.send(":MARKer:MODE MANual\n") elif type == 2: self.s.send(":MARKer:MODE MEASurement\n") elif type == 3: self.s.send(":MARKer:MODE WAVeform\n") def SetXMarkPos(self, Chan, MarkN, Pos): self.s.send(":MARKer:X%dY%dsource CHANNEL%d\n" %(MarkN, MarkN, Chan)) self.s.send(":MARKer:X%dPosition %f\n" % (MarkN, Pos)) def GetScreenShot(self, imageName): print imageName ipAddr = str(self.host).replace(" ", "") if self.device ==0: url = "http://" + ipAddr + "/screencapture.asp" else: url = "http://" + ipAddr + "/getImage.asp?inv=false" #print url
94
soup = BeautifulSoup(urllib2.urlopen(url).read()) #print soup.html mystr = str(soup.html.img) #print mystr image = str(mystr).split("src")[1].split('"')[1] #print image urlimage = "http://"+ ipAddr + "/" + image #print urlimage opener = urllib2.build_opener() opener.addheaders = [('User-agent', 'Mozilla/5.0')] fo = open(imageName, "wb") fo.write(opener.open(urlimage).read()) fo.close() #urllib.urlretrieve(urlimage, imageName)
#*********************** Data Logger Instrument Driver************************ #AgilentDataLogger.py import visa def GetInstr(devName): rm = visa.ResourceManager() mylist = rm.list_resources() for i in range (0, len(mylist)): instr = rm.open_resource(mylist[i]) newdev = instr.query("*IDN?") if devName in newdev: return instr def getVoltage(chan): dataLog = GetInstr("34972A") return float(dataLog.query(":MEASure:VOLTage:DC? MIN,MAX,(@%d) " % chan))
#*********************** Power Supply Instrument Driver*********************** #AgilentPower.py import visa def GetInstr(devName): rm = visa.ResourceManager() mylist = rm.list_resources() for i in range (0, len(mylist)): instr = rm.open_resource(mylist[i]) newdev = instr.query("*IDN?") if devName in newdev: return instr def setVoltage(chan, voltage): powSup = GetInstr("HEWLETT") if (chan == 1): powSup.write(":INSTrument:SELect P25V\n") else: powSup.write(":INSTrument:SELect P6V\n") powSup.write("SOURce:VOLTage:LEVel:IMMediate:AMPLitude %f\n" % voltage) def setCurrent(chan, current=-1): powSup = GetInstr("HEWLETT")
95
if (chan == 1): powSup.write(":INSTrument:SELect P25V\n") else: powSup.write(":INSTrument:SELect P6V\n")
if current ==-1: powSup.write(":SOURce:CURRent:LEVel:IMMediate:AMPLitude MAXimum\n") else: powSup.write(":SOURce:CURRent:LEVel:IMMediate:AMPLitude %f\n", current) def setOutputState(): powSup = GetInstr("HEWLETT") powSup.write(":OUTPut:STATe 1\n") def clrOutputState(): powSup = GetInstr("HEWLETT") powSup.write(":OUTPut:STATe 0\n") def setReset(): powSup = GetInstr("HEWLETT") powSup.write("*RST")
#*********************** Electronic Load Instrument Driver******************** #Chroma.py import visa def GetInstr(devName): rm = visa.ResourceManager() mylist = rm.list_resources() for i in range (0, len(mylist)): instr = rm.open_resource(mylist[i]) newdev = instr.query("*IDN?") if devName in newdev: return instr def setCurrent(chan, current): chroma = GetInstr("CHROMA") chroma.write("CHAN %d" % chan) chroma.write("CURR:STAT:L1 %f" % current) chroma.write("LOAD ON")
96
REFERENCES
1. Test Automation: “Test Automation” white paper by Adtiya Jain Publisher: AgreeYa Solutions Inc, 2015 Date Accessed: February 6th 2015.
2. Manual Testing: “How to increase the efficiency of manual testing”, Business White Paper by Hewlett-Packard Development Company, November 2010 Date Accessed: January 26th 2015.
3. Python Programming: “Programming Python: Edition 3” book by - Mark Lutz, August 23, 2006. “O'Reilly Media, Inc.” Publications Date Accessed: September 5th 2015.
3. Instrument Driver: “1MA170: Introduction to Attribute Based Instrument Drivers” white paper by Jiri Kominek and Juergen Engelbrecht, January 12 2012 Publisher – Rohde and Schwarz Wireless Communication Testers and System Date Accessed: February 10th 2015.
4. SCPI Commands: IVI specifications, May 1999, Version 1999.0, “Standard Commands for Programmable instruments (SCPI)” Date Accessed: October 27th 2015.
5. GPIB: “Gpib Programming Tutorial” by Electronics Group, Free University Amsterdam, Faculty of Sciences, 11 January 2000 Date Accessed: February 1st 2015.
97
6. GPIB: IEEE Standard for Higher Performance Protocol for the Standard Digital Interface for Programmable Instrumentation (488.1-2003) Date Accessed: February 22nd 2015.
7. GPIB:IEEE-488.2-"Standard Digital Interface for Programmable Instrumentation- Part 2: Codes, Formats, Protocols and Common Commands”,1992 Date Accessed: February 22rd 2015.
8. GPIB: “GPIB and the battle of incompatible languages” by Mussmann, S.M. Dec. 1988, Vol.37(4), pp.488-492 Date Accessed: February 23rd 2015.
9. GPIB: “GPIB: Challenges and Potentials” white paper by Amplicon, May 22, 2014 Date Accessed: February 23rd 2015.
10. Keysight Agilent IO Libraries suite 16: IO libraries suite 16 Datasheet, Keysight technologies Date accessed: December 1st 2015.
11. Keysight Agilent Command Expert: Keysight Agilent Command Expert Datasheet, Keysight technologies Date accessed: December 5st 2015.
98
12. Solid State Drives: “Inside Solid State Drives (SSDs)” book by - Rino Micheloni , Alessia Marelli , Kam Eshghi, October 15, 2012 . Springer Publications Date Accessed: September 10th 2015.
13. Solid State Drives: “Power Quality in Electrical Systems”, book by - Alexander Kusko, Marc Thompsoni, May 31, 2007. McGraw Hill Publications Date Accessed: January 10th 2015.
14. Solid State Drives: “High-Efficiency Backup Power Supply”, Application Report by Michael Helmlinger, Published by Texas Instruments Date Accessed: January 1st 2015.