Project Plan of Simultaneous Co-Test of high performance DAC ADC Pairs

Transcription

1 Project Plan of Simultaneous Co-Test of high performance DAC ADC Pairs Iowa State University Senior Design Project May13-28 Adviser Dr. Degang Chen Members Luke Goetzke Tao Chen Ben Magstadt

2 Table of Contents Problem Statement... 1 Concept Sketch... 1 System Block Diagram... 1 System Description... 3 Operating environment... 3 User Interface... 4 Functional requirements... 4 Non-functional requirements... 4 Deliverables... 4 Work plan... 5 Project schedule... 5 Work breakdown structure... 5 Resource requirements... 5 Risk... 5

3 Problem Statement There are increasingly more systems on a chip that have multiple embedded Analog to Digital Converters and Digital to Analog Converters. The performance of a system generally comes down to the performance of these ADCs and DACs. This gives rise for the need of accurate testing methods of these two components. Currently the ADCs and DACs are tested separately. This is time consuming and requires already confirmed reliable and costly equipment to characterize the performance of the ADCs and DACs. Recently, it has been theoretically shown through simulations that by using proper Digital Signal Processing based test algorithms, it is possible to simultaneous co-test both an ADC and DAC that are in a DAC-ADC pair. This is made possible by several different hardware and algorithmic processes that help to determine the imperfections of both the ADC and DAC separately. This project will put this theoretical process to test by creating a PCB operating environment for a 16-bit DAC-ADC pair. Ultimately this will verify that the testing method will work with similar accuracy, and can replace the current slow and costly testing methods. Concept sketch To start the project, we defined the general approach to be taken; Figure 1 illustrates how the general flow of the PCB, starting and ending with computer controls. This illustration does not include the counters, multiplexers, and general control lines that are on the board, and does not include the Labview code flow, or Matlab code flow. Filter 1 16-bit DAC Swicth Switch 16-bit ADC Filter 2 Memory Memory PC control-labview PC analysis-matlab Figure 1: Concept sketch of the system to be designed. System block diagram The system block diagram can be broken down into three separate components; the board layout design, the Labview controls, and the Matlab interface. To start, the board layout is shown in Figure 2. This is a more elaborate design then that shown in Figure 1; this includes much more of the required control systems to interface all parts together. For clarity, all computer control lines and general components (resistors, capacitors, inductors, etc) have been removed, with exception for the required filters. The control system will be done in Labview, as shown in Figure 3. This figure shows the front panel view of the Labview code; this includes the input signal setup, the controls for board operation, as well as the input and output waveforms. Finally the data analysis will be done in Matlab, which is described thoroughly in a later section. 1

4 24-bit ADC Audio Generator +5V -5V AGND DGND Parallel /Serial 16-bit DAC Switch Switch 16-bit ADC Serial/ Parallel Toggle Filters Filter switch Compare 128M Memory 2x1 MUX Up Counter 128M Memory # of Data Compare Parallel/Serial 8-bit register 2x1 MUX -- Board Data In -- Board Data Out Parallel port plug Figure 2: Preliminary Board Design. Control lines removed for clarity. Figure 3: Labview control's as of TL - Input wave setup, TR - Board Mode Setup and Control, BL - overlapped Input & output waveform (binary), BR - Voltage output. 2

5 System description A printed circuit board (PCB) will be used to characterize the DAC - ADC pair simultaneously. The DAC will be used as a signal generator into the ADC, and data will be recorded at the output for analysis. A crucial step to the project includes two separate filters in between the DAC and ADC signal; one an attenuator, and the other a low pass filter. Having these two different filters, and thus two different output signals, is what makes the test algorithm possible. The board will be operated through 8-bit data paths that lead to large memory chips. On the board will be various control lines operated from the setup techniques controlled by Labview. Among these will be counter registers used to synchronously toggle between different board schemes (filters), and indicate when all data has been collected. Labview will be used to control the entire system through a bidirectional USB to Parallel port interface to the board. This will be used to communicate, setup, and control the board operations. This interface will be used to setup all multiplexers and registers allowing for various setup techniques, including switching between filters and inputs. This will also serve as the means for sending and receiving the system data. All data will then be sent to an external file from Labview, and imported into Matlab for post processing and analysis. The Matlab program will take this file and examine several different things. First, by obtaining parameters of the simulation, Matlab will set up the analysis using the number of data points, frequency, and sampling frequency. It will then decipher between the two different signals and throw away any data that it deems as unreliable due to any instability at the beginning or end, or during any switching between the different filters. Once it has the two different signals, it will compute the Fast Fourier Transform of the two different signals. Once it has these two different signals in the frequency domain, it will use several different mathematical equations and comparisons to be able to decipher which imperfections of the signals came from the DAC and which ones came from the ADC. There are also several different checks in the Matlab algorithm to ensure any hardware imperfections will be corrected for. It has already been verified by simulation that up to a 5% error in filter components can be corrected by the algorithm by looking at the amplitude and phase shifts of the two different outputs in the frequency domain. Operating environment The developed system will operate in a few different environments including our board, Labview controls, and Matlab analysis. The DAC-ADC pair will operate on the board we develop, design and eventually will have fabricated. This environment will include memory chips to story all input and output data, all control and feed lines, proper filters, and all necessary components to allow the parts to interface and operate properly. The board will be controlled and operated through the Labview environment on the computer. This environment will be responsible for all input and output storage and communication. This includes controlling all setup schemes, uploading the DAC signal for signal generation into the ADC, and then downloading the converted ADC signals. Finally the converted data will be analyzed in Matlab. 3

6 User Interface The user interface will happen through Labview. Labview by natural is user friendly, and will be easily descriptive for the user to set up the board and send and receive data. The Labview environment will have a one page cover with the top left consisting of the signal setup, and the top right consisting of the board setup. The bottom left will display the input signal, and the bottom right will display the received output signal. There will also be a small user interface for the Matlab program that will include being able to select the file that needs to be analyzed along with a couple different options to compare with other results and what data out is going to be requested. Functional requirements The functional requirements of our project are that it can run several different tests and compute several different values: THD, INL, and DNL. It will be able to calculate these values by cotesting the ADC & DAC, testing the DAC with a high-precision 24-bit ADC, and testing the ADC with a highly pure audio signal generator. These different tests will be used to prove the validity of the other tests if they match up respectively. The control of these different tests will be directed and collected by Labview via a parallel port. The analysis of the data will then be done by Matlab. Non-functional requirements One non-functional requirement of this project is that it needs to be relatively cheap. This is one of the aims of the project to replace the current method which is a much higher cost with this cheaper alternative. Another requirement for this project is that it needs to meet or exceed the reliability of current testing procedures. The reliability of the tests is very important as it becomes useless if the results are occasionally wrong and a part could be labeled incorrectly in testing resulting in a defective part in a customer's hand. Lastly, the testing should become quicker than previous methods. This is due to less data being needed to be collected. Deliverables There are three expected deliverables for this project. The first is the Matlab code for processing of the data. This code will accept a data file from Labview containing the simulation setup and results. It will then use all of the data to be able to decipher the desired specifications of the ADC and DAC. This is fairly complete at the moment, being confirmed through randomly generated computer simulations. It will be modified further to accept more varied amount of data as well as being more user friendly to accept data from Labview. Second, the Labview code needs to be generated. This is responsible for loading all of the data into the memory on the board and controlling the different aspects of the simulation. It will then also get the data back from the ADC's memory and then package it into a file that can be delivered into Matlab. The last component will be the PCB that is being designed. This board will contain the 16-bit ADC & 16- bit DAC. The DAC will read from a memory bank to generate a signal. This will then run through a series of different filters and be digitized by the ADC. The ADC will then store the results into memory. The board will also need to include ports to interact with the PC through Labview. There will be other circuitry on the PCB that needs to be designed as well to ensure the correct clocking and timing of all of the components as well as counters to help with the control of the test as well as switching through different filters during a test. 4

7 Work plan This project has a very strict schedule with project start in September of 2012, board completion by December of 2012, and spring of 2013 used for post simulation, verification, data collection, and publication of results. To accomplish this, all tasks were divided from the start. Luke will be in charge of board control and design interfaced with Labview. Ben will be in charge of all Matlab analysis, filter design and clocking sequences. Tao will be in charge of the board layout and functional verification. The board design will be a collaborative effort, as all parts need to function properly together. After completing the board design, the timeline will re-evaluated for data collection and analysis. The resources needed to accomplish this will be a computer to design the hardware and software with the programs Labview, Matlab and Altium, a bidirectional USB-parallel cable, and the end fabricated PCB board. A confirmed accurate 24-bit ADC and an audio signal generator will also be needed to compare the results of current method algorithms with the results that are achieved with the simultaneous co-testing method. Any risk of this project can be attributed to functional lab verification, and the error associated with breaking parts. To reduce the risks of breaking parts, we will make sure that parts that are expected likely to break or burn out will be able to be removed and replaced from the board. The ADC and DAC will be already designed to be easily replaced so that different samples can be taken, so this takes care of the risk of the ADC and DAC breaking. Another risk that needs to be taken into consideration is coherent sampling. Coherent sampling is needed to make sure that the data that is being collected and analyzed by the algorithm in Matlab is accurate to the best degree. If it is found that coherent sampling is difficult to maintain in this system, then a noncoherent Fourier transform will need to be analyzed and substituted into the algorithm in Matlab to correct for non-coherence. Lastly, the timeline of the project could also be considered a risk as it is pushed very quickly. It has been scheduled very tightly; therefore there is some backup room for extra time if an unforeseen error would come to light. 5