Day 4 (7/18)

• Yesterday I decided that the current state of the code couldn't handle all the interwoven decision making we wanted to do. The code base is separated into two distinct scripts that don't really interact well together, and it didn't make sense to keep passing variables back and forth between them when they should be shared. Also, there was a lot of repeated functions and methods and it didn't really make sense to have so many duplicate lines of code in the code base.
• So today was a refactoring day! I am proud to say that I successfully merged the two files and improved a lot of the methods. I also reduced almost 100 lines of code out, while adding a lot of clarity to the flow and preparing for some new feautres.
• I've only gotten up to picking implications based on activation probability and the high fault count of the implicand node. I still need to integrate some gauge of low fault count of implicant node, which requires running a new set of fault analysis and is a pretty frustrating thing to work in. I'm leaving that for tomorrow.
• I also think it might be useful to just hand-produce some different test circuit designs prioritizing different aspects of implication selection to see which results work best. Another task for tomorrow.

Day 3 (7/17)

• Had a meeting with Marco and Dr. Bahar and we discussed my current results and progress. I think the changes I've made are going over well, but in our discussion we decided that the order of priorities for the implications I choose should be switched up a little. The way the code is structured doesn't give much room to weigh activation probability as much as we'd like to, so I need to rework the flow slightly to reprioritize things.
• After the meeting Marco showed me how to run a spice simulation on Oscar, my first time! It was not super exciting. But then I got my results and I was able to look at the simulations in SmartView. Unfortunately, the results were not good. It didn't look like there was a lot of noise reduction at all, even with 8 schmitt gates added. But I've outlined a bunch of different tests I can run to see what things are effective, and I still have a lot of reworking to do with the tools so hopefully these results can be improved a little.

Day 2 (7/16)

• Busy day today. Stayed very late because simulations were taking a while and I wanted to have everything prepped for my meeting tomorrow.
• Marco pointed me towards the tool used for drawing schematic block diagrams. I figure I'm going to need these circuits for my eventual poster and paper, so it wasn't lost time I spent painfully drawing these circuits, but it was very tedious. I did draw all of rd53 and rd73, which is good because now I can use these diagrams for when I show my results tomorrow at the meeting.
• I added the code to remove duplicate implications, so now it does a check for implications that share an implicand and chooses the one with the higher probability of activation. I now see that I'll have to do this on a larger scale with my coverage code also, but it was pretty easy so that's good.
• I also finished the coverage code! There's now a parameter that controls how many nodes we want reinforced, and if, after the outputs are initially covered, there is area left to be reinforced, it goes through and does a proportional insertion of more implications to high-fault nodes in each of the output. It's still slightly twitchy: sometimes two outputs have a shared high-fault node and an implication is output twice, and gates too close to the input just mess up fastscan, which is fine, but not nice programming. Also, I noticed that the script can sometimes miss an implication - I think I know where that's happening, but not why. Will need to investigate further.

Day 1 (7/15)

• Last week right before I left I discovered that fastscan was choking on the pattern files for fault simulation. That was like a big hairy mess I didn't want to look at, so I tabled it for this week, and today I got started. I discovered that the pattern files being generated for testing had some syntax errors and were weirdly missing some lines. So first I dug around until I found where the lines were supposed to be written. Then I tested it again on rd53 to see if this was a circuit-specific problem or if some code accidentally was removed. It turned out that the script for parsing pattern files was very hard-coded and could not cope with the larger circuit pattern files. I made the script more flexible, and then it generated faults for rd73! Very exciting.
• My next task was to generate the spice files for testing. Marco told me I needed a grey code for the input values, and since the rd73 circuit has 7 inputs, I needed a 7-bit grey code. Grey codes are a little confusing and scale in a really overwhelming way, so I spent a little while writing a script that generates the grey code, so I can add that to the automation also.
• Then I realized that I'd have to manually remove the duplicate implications (not really duplicates, but they both cover the same gate) so I set to work automating that. I figure holding up my progress a little now is better than doing it on my own a few times and then having to automate it anyway. For some reason fastscan is running very slowly and it's having a negative effect on my productivity, but Marco and I troubleshot it for a while and couldn't figure out the source. Until then I'll just multitask a bit more with a few different problems.