Weekly Accomplishments:

• Officially automated the fault reinforcement tool!
• Moved on to adding more features and testing on more circuits

Week 6 TODOs:

• complete testing on rd73 and maybe some more circuits on the list, add features and robustness as needed
• finish writing tool for adjusting fault coverage in implication selection

Day 5 (7/12)

• Today I set out to reformat the rd73 circuit verilog file so that I could test it. It turns out that the tool used to convert the circuits to verilog was written by Dr. Bahar herself a while ago so there may be some syntax errors. So, armed with some handy vim find-and-replace and column-selection magic, I reformatted and corrected the verilog file. Then, I ran the circuit again and realized I needed to replace all the 3+ input gates with 2 input gates. This was all a tedious and complicated process because of naming conventions for the circuits, remembering to add new wires, etc, etc. Finally, when I had a working gate, the tool started hanging during both chain selection and the fault simulation. Upon investigation, I saw that iterating through a circuit graph to find chains scales very badly: the place where the code was hanging had two nested for loops set to iterate a combined total of 60,000,000. The size of the circuit may also be the reason fastscan crashes when doing fault analysis on the circuit I'm not sure if running on a faster computer will help, but I will investigate this next week.

Day 4 (7/11)

• I made the (personal) discovery that in the current fault observability workflow, all the resulting implications will be self-implications. This helped me fill in all the blanks in my discrepancies with the hand-picked implications from Lauren's thesis. I can now reproduce all the implications after adding lots of conditions to the implication selection to ensure it chooses only ideal implications. The fault observability script now checks to ensure the high-fault node is not a primary input or output or too close to a primary input, and that the implicants chosen in the implication are not primary inputs.
• I worked on running a few new circuits through the tool, but all of them worked in various places. I think the c-label circuits are all too large right now to be handled by the tool, and there may have been some problems with the slightly larger rd73 circuit.

Day 3 (7/10)

• I was still not able to produce implications for all outputs, so my task was to fix that. At our team meeting, Dr. Bahar pointed out that even though Lauren didn't include a specific list of implications in her thesis, I could parse them out by looking at her included diagrams and the spice netlists, which I now have access to. If I'm able to modify the script so it can effectively pick out all of Lauren's hand-picked implications, I can be confident that it's functional to a good degree and then move on to improving the script and testing it on other circuits.
• I thought I could easily reinforce a high-fault node by just picking any implication that matches the node, but I had overlooked the critical criteria of the nodes probability of being the implication value, and I also didn't ensure that the high-fault node would only qualify as the implicand. It was also confusing to choose nodes that were before the chosen node, but not necessarily in the fan-in cone (it's easy to pick out in a picture, but takes some fancy graph manipulation). So I had to table that "improvement" until I have more time to approach it.
• There was a strange thing that Lauren included in her code about "type switching" where she would switch the type of the high fault node and the implication's type, and neither of us could figure out why that happened (but luckily, left it in there). When we were discussing a different problem, though, we figured out that the types are probably switched so that later, when figuring out what type of CMOS gate to place in the spice netlist, it has to use the opposite of the high-fault type. Thus, type switching in advance. I put in some useful comments that explain the reasoning briefly.
• I spent the rest of my day carefully collecting a list of the hand-picked high-fault nodes, their gates, positions in the graph, and other relevant information from Lauren's thesis and the SPICE netlists so I could later carefully figure out how to parse them out.

Day 2 (7/9)

• In the morning I sat down and really concentrated on figuring out why one output in the rd53 circuit, v5_0, was giving wrong outputs. I've been using stickies to keep track of all the problems I'm encountering, which is helping my workflow a lot. Back to v5_0, the script was making an implication file for the output node, but not writing any implications to it. Upon deep investigation, I found that it was choosing as v5_0's high fault node a node that only had inputs as its node to reinforce, and the script did not like that. To solve this, I stuck a few checks in to reject inputs and nodes that didn't have a sufficient distance from the output or input to provide an interesting circuit. That solved the problem for v5_0!
• There was a weird confirmation in the "choose high-fault nodes" function that ensured that all high-fault nodes were a distance of 5, exactly, away from the output. We're not sure why that's there (as it was resulting in undesirable choices and did not seem like a logical step) but Marco thinks it might be residual from the line of thinking that tried to make implication chains with a length of 5 or 6. Since chains and fault-reinforcement implications have different rules, I could eliminate that check, and things worked better.

Day 1 (7/8)

• My email things are almost set up! The ccv system is down today, but as of tomorrow I will finally have access to Oscar. Of course, we've now decided I won't be focusing on spice simulations so it's not critical for me anymore. But I still need to learn how to run simulations so I can validate my generated circuits, so I'm glad I have it. Hopefully I will be able to test my own circuits with it soon!
• First I sat down with Marco and we discussed my adventures of this past week and what I would do in the upcoming future. We discussed how my goal for the next few weeks should be to figure out and maybe improve the metrics used for chain evaluation in find-chains, figure out and maybe improve the metrics used for fault-implication insertion, and see if there's a way of deciding which is more optimal, and see if there's a way of doing a mixture of the two for an optimal approach. This is all in addition to the hopeful task of doing spice simulations once I get system access.
• Then Dr. Bahar stopped by and we did some catch up on the project, and I met a masters student who will be looking over more of the Spice simulations side of the project. We decided that my priorities were to get the tool going and add some more automation to it. We picked out a list of circuits that I should also test on, and prioritized which ones were more important (mostly conditional on how big they were) to get working.
• I spent most of the day stepping through the fault simulation script to figure out why the methods were picking out the nodes they were picking as "high-fault nodes" and pouring over fault reports to understand the text parsing used to pick out nodes for implications.