Journal

Week of May 23 - 27

During my first week of work I had a lot to learn about and become oriented with. I arrived in Pittsburgh last Thursday, which gave me a chance to get settled in my room for the summer. I'm subletting one of five bedrooms in townhouse within walking distance of CMU's campus. This is convenient since I find driving and parking in the city a challenge.

Once I started work, there was a lot of reading to be done. I am working with my mentor Prof. Diana Marculescu and one of her grad students, Natasa Miskov- Zivanov. The current project, Symbolic Analysis of Circuit Reliability, is focused on using Binary Decision Diagrams (BDDs) and Algebraic Decision Diagrams (ADDs) to analyze circuit reliability with respect to transient faults due to such things as cosmic rays or alpha particles.

My first task (aside from learning how to use and configure my linux box) was to read a draft of Natasa's Masters Thesis and become familiar with her project overall. This meant that I first needed to learn what BDDs and ADDs are as well as learn how to read them and know the process to create them.

In the next week I plan to become familiar with all of the software Natasa has used or written that is associated with this project. She has created a model written in C++ which analyzes a given circuit and produces a measure of its reliability given that a transient fault has occurred. She has also worked some with SPICE modeling to compare that with her own model.



Week of May 30 - June 3

Happy Memorial Day. Not much work got done on Monday for obvious reasons. I did, however, spend sometime developing this website and submitting the address to DMP for approval. The site is still underconstruction, but the major pieces are in place.

I was a little apprehensive about actually digging in to work this week. My task for this week was to become familiar with all the code. This was and still is a very daunting task. First of all, all the code is in C++. Now, I don't know C++ nor do I have any experience with it. In fact my coding experience is fairly limited. I do have some experience with Java; which, fortunately is similar to C++ in syntax and structure. Therefore, I spent most of Tuesday working though a short online tutorial of C++ to refresh my memory on coding in general as well as the specific syntax of C++.

I tried looking at the code that has already been written for the project, of which there are a few thousand lines. I still didn't know where to begin so I started with the header files and figuring out where the main method was. After a bit of searching I found them and a few moments later my eyes glazed over. In order to simplify things I've found the specific portion of the code related to delay.

This project implements the CUDD: CU Decision Diagram Package. This package provides functions to manipulate Binary Decision Diagrams (BDDs), and Algebraic Decision Diagrams (ADDs) which are structures needed for computations in this project.



Week of June 6 - 10

This week I began a more indepth look into the specific part of the code I am to work on. Much of my time this week was spent learning how to navigate to the code (since it is not located on my own workstation) as well as figuring out hot to edit and run it. It took a long time to go through the code and remove unimportant print statements as well as putting in logical print statements for myself.

One of the major problems is that the runtime of the program is not necessarily proportional to the number of logic gates in the input circuit. Therefore, the program will spend a lot of time in complex computation. In order to make sure that the program is still running I placed a print statement that adds a "." approximately every two seconds as it performs its many recursive calls. This satisfies my need to see that the program is making progress.

So far I haven't witnessed the program crashing or stopping because it ran out of memory. Different test cases have radically different effects on run time. Some of the smaller test benches will use almost 100% of the cache but still finish quickly where as some other test benches will reach 70% of the cache filled and seem to get bogged down in computation.

A couple things I want to look into include why the program seems to spend a lot of time after it has reached the end of the Main method. Also, determine the source of the segmentation fault. In addition, I want to investigate if the program is performing the same computation twice in a row as is suggested by the run times of the recursive calls. Lastly, I want to determine and attempt to fix the error about "unexpected non-zero reference counts"

Wow, this week's entry seems pretty technical. Next week will be different. I am flying out to Anaheim, California to attend the Design Automation Conference (DAC) where I will attend several seminars and events.



Week of June 13 - 17

I spent this week in Anaheim, California at the 42nd Design Automation Conference. For a summary of what I did please see my page on DAC. It was a full week which included seeing many technical papers presented and a few keynote speeches. However, now it is time to get back to work.



Week of June 20 - 24

This week I began to take care of tasks associated with my trip to DAC including my event summary and reimbursement process. I also began to work with the code more deeply. I ran each of the test-benches on both the original and delay version of the program and noted the runtime and the maximum memory usage. Some of the test-benches did not finish and would cause the computer to start thrashing. From those results its been determined that there is probably a memory (either stack or heap) problem due to the recursive function calls. One solution would be to rewrite the computeDelay method as an iterative method rather than a recursive one. Then I began focusing on some SPICE modeling. I am working with inverter chains and looking at the duration and amplitude of the input signal required to attain certain characteristic output signals. I only began writing and testing the spice files and therefore, have no results to report.

In the next week I will give a mid-project status report to my mentor and associated graduate students. I will also finish up my submission for reimbursement from the trip to DAC. In addition, my focus will be on continuing the SPICE modeling in 180nm to verify my procedure in order to use my method to obtain results for the 100nm and 70nm processes.



Week of June 27 - July 1

I submitted my budget and receipts for reimbursement from my time at DAC. I also put together a mid-project presentation about what I've done so far as well as what there is to do for the rest of the summer. The mid-project outline is located in the links to the left. I also began taking data from my spice modeling. I found this to be very hard/tedious/frustrating since it is mostly a matter of guess and check. And, since I found that a matter of accuracy is needed in order to obtain reasonable/usable results, it requires a lot of guessing and checking. I began working on a way to automate the process using OPTIMIZE in the .TRAN statement to find the glitch amplitude which causes the output I'm looking for. However, I have found this to be a little troublesome because the result is either not accurate enough or I get warning messages and no result. Sometimes I feel that I might just be better off using guess and check as before. It has been decided that I will look at inverters in the 180nm, 100nm, and 70nm processes and see if there is any change in the characteristics I'm looking at. I will also investigate different types of gates within the same process to see if there are any trends there too.



Week of July 4 - 8

Happy 4th of July!
I continued running the spice simulations and compiling data. I have preliminary results for the inverter test which seems to show little change across the three different processes. There is slight variation, but no distinct trend.



Week of July 11 - 15

I again continued working on spice simulations. I worked on characterizing 2 input nand, nor, and xor gates which can be seen in the graph below. There is a noticeable difference from curve to curve. The next step will be to integrate these new coefficients into the code to see if it improves the correlation between the symbolic analysis and hspice analysis of test-bench circuits.



Weeks of July 18 - August 5

I spent my last few weeks updating the graduate student of my progress, testing my new curve coefficients, and writing my final report. In my analysis I determined a trend in the error of the calculated propagation delay. I derived some factors to help correct for this error. Both the new curve coefficients for attenuation and the propagation delay factors were ineffective at increasing the accuracy of the program as compared with SPICE modeling. The only change was in damping out certain propagations entirely while leaving others untouched. Further investigation is obviously needed to track down the discrepancies between this symbolic model and SPICE analysis.