Progress:

• Fabrication Iteration: the first template NMOS fabrication run did not yield a working batch, so the team is restarting the fab process for the next iteration.
• Schedule Status: the restart and updated projected finish time is still within our original timeline/buffer set in the 2/7 team status report. The team expects the fab to complete within this week and subject to bring-up and characterization.
• Parallel Work Continues: While fab restarts, we are (1) finalizing the oscillator schematic direction and (2) preparing the test/measurement workflow so the final oscillator can be characterized quickly when we bring-up.

Risk Management:

The primary risk for this week is the schedule uncertainty from the fab restart. Given we have already exhausted our buffer time period in the conservative timeline set in the 2/7 team status report, if the next run slips or encounters another failure, it would compress the remaining time for bring-up and characterization as well as our goal of going through and documenting the entire first iteration. We are mitigating this risk by keeping the design, characterization, and testing planning in parallel so no time is wasted once the hardware is fabricated and functional. This could compensate for the time lost if the next few fab runs also experience failures. 

Upcoming Schedule: 

Despite the fab process restart, we are still in a good position to meet the original timeline and remain on track relative to the buffer that we established in the 2/7 team status report. Once the fab is successfully completed, we must move fast to begin the characterization and measurement process in order to meet our original goal of finishing and documenting the first iteration before spring break. In the meantime, the team, in addition to the characterization and design planning work in parallel, has begun working on the design presentation slides for next week.

Week-Specific Design Impact Considerations.

With regards to this week’s specific design impact considerations questions, part A is written by Jim, part B is written by Charlie, and part C is written by Ethan.

Part A: Our fabbed oscillator and documented, repeatable bring-up workflow improve safety by greatly reducing wiring/probing and trial-and-error during lab testing and measuring. This lowers the likelihood of miswiring, improper loading, and accidental device/equipment damage during power-up and characterization. By providing a repeatable testing infrastructure (defined interfaces, checklists, and measurement access points), we reduce ad-hoc setups and make safe bring-up the default. The workflow also standardizes safe sequencing and measurement steps so new teams can follow a known process instead of improvising on the spot. Overall, it creates a safer and more predictable lab environment while improving the reliability of our measurements.

Part B: Our fabbed oscillator and documented workflow strengthen the HackerFab community as an extended student/instructor group by providing shared infrastructure that teams can organize around. By pairing the design with a repeatable bring-up and measurement workflow, future projects can adopt a common baseline instead of each team developing isolated processes. This improves collaboration across teams and mentors because everyone can align on the same interfaces, expectations, and validation steps. Overall, it supports continuity and collaboration within the HackerFab and ECE community by making our process and lessons learned accessible to future students.

Part C: Our fabbed oscillator and documented workflow improve economic efficiency and saves cost in HackerFab by creating an established, reusable baseline that future teams can use instead of repeatedly spending time and exhausting fabrication resources reinventing basic oscillator bring-up. This benefits not only teams building future oscillators, but also teams building more complex systems that depend on an oscillator (mixed-signal components) as they can start from a validated reference. Through our documentation, we reduce recurring setup/debug labor and increase the likelihood that fabrication runs and lab time yield actionable results. Overall, this also increases the return and availability of shared HackerFab resources (fab slots, equipment time, and staff/TA support) by making downstream projects faster and cheaper to execute.