Category: Team Status Reports

This week, we have made good progress on both the embedded and Verilog side. One significant risk is that our peripheral components will not be compatible with the FPGA, which will be difficult to fix once they are solidified on the PCB. We are managing this by testing and researching these components beforehand, such as the microSD card reader. This way, we can change or find new components before we get the PCB fabricated. This has led to a possible change, since we have ordered two different microSD card readers out of concern that the original one won’t be compatible with the FPGA’s 3.3V logic. Once the microSD cards come in, we can verify if we can move forward with this option. Other than that, no changes to the existing design have been made this week.

Another risk is that the individual RTL components will not integrate properly. We are mitigating this by testing the integration of individual modules after they are individually validated. This is the current phase we are in for the RTL, since Amelia has validated that the PS/2 works in simulation and synthesis, the encryption in simulation, and the PS/2 and encryption together in simulation. However, we have not yet succeeded in integration the PS/2 and encryption in synthesis, and is what we will be working towards this week.

This week the Embedded team worked on updated power considerations for the PCB, redesigned the layout to be much cleaner, ordered all relevant parts, replanned the layout over the FPGA, and continued working on the layout of the PCB.

Embedded team is currently in progress for unit testing individual parts (e.g. SD card reader, MAX7219) to confirm power considerations. The datasheet specifies a range but the FPGA GPIO pins is only able to supply 3V3 so further testing is needed to determine if output signals of these components are sending properly with a lower voltage than typical (5V). We also looked into alternate methods of powering such devices – for testing purposes – and finalized our testing plan.

For the upcoming week, Embedded team plans to complete unit testing, update layout accordingly, finish tracing the layout, and order the PCB.

This week the Verilog team worked on writing the protocol for the PS/2 keyboard. After implementing it and trying to test it, we found multiple online implementations for the same protocol to use as a guide. However, all 3 had more depth in implementation (extra acknowledges and error checks), so tried to simulate with their code (an university group from Toronto as the other two implementations were unfinished). This did not work initially because of power constraints with our PS/2 keyboard, and after some research we determined this may be because of the specific Perixx manufacturer who tied their power to 5V whereas our FPGA GPIO pins only supported 3.3V. Tanisha and Amelia sourced another PS/2 keyboard (HP manufactured) from facebook marketplace which worked with our implementation (and sustainable!).

Currently, the Verilog team is working on the encryption modules and successfully got them to simulate! The goal for this week is to synthesize and start working on the SD Card reader as that is the other component that has potential for integration issues.

As a team we received feedback on our Design Report and had a meeting to discuss improvements that need to be implemented for our final report.

This past week we completed our entire design report and updated our system design.

The system overhaul came about as we switched using a ribbon cable external keyboard for a PS/2 keyboard. This decision led to us switching our FPGA back to the Altera DE10 Standard as opposed to the DE0 Nano. We had initially switched to the DE0 as it had many more GPIO pins which would have been useful if we were doing a custom onboard keyboard. However, since we scrapped that in favor of the more user friendly (and optimized GPIO pin friendly) PS/2 keyboard we no longer needed those pins but rather needed the PS/2 port available on the Altera DE10 Standard FPGA. This meant we added an additional RTL module (PS/2 protocol interface) for our Verilog team and changed our PCB design for the Embedded team.

Another design change we made was using rotary encoders instead of potentiometers for our user input. We decided upon this as since we were no longer using the DE0 Nano, there weren’t any dedicated ADC pins to use and hence wasn’t any benefit to using a specifically analog input. By using a rotary encoder, it had much more user friendly interface as they are meant for comfortable user input. A big improvement was the digital pulses associated with the rotary encoder with specific pulse amounts (e.g. 24/36) as opposed to the potentiometer that had an analog continuous variable resistance change. Since our application cares more about the precise readings (e.g. which letter user is inputting), we don’t care as much about range of motion that the potentiometer offers.

This week the Embedded team will work on laying out the PCB and ordering parts and the Verilog team will work on writing the PS/2 keyboard protocol code as well as starting to synthesize it when the keyboard arrives.

 

Part A: Global factors

Worldwide factors that our product specification meets includes the education of a broad audience on the historical and technical significance of the Enigma machine. By providing a hands-on learning experience that is accessible by individuals of different backgrounds, contexts and levels of technological understanding. Since our solution is open source and built for educational purposes, it removes barriers to access of this knowledge and contributes to the global effort for greater STEM education efforts. By making this technology accessible beyond academic institutions, we enable individuals without access to specialized education a look into foundational cryptographic principles.

 

Part B: Cultural factors

We are creating this product with deep awareness of the cultural and historical significance of the Enigma machine. While the focus is an appreciation for groundbreaking technological achievement, it is also closely linked to World War II, a conflict that had profound impact on societies worldwide. Our focus is to highlight the engineering and cryptographic innovation rather than its wartime application, and ensure we approach the subject with appropriate sensitivity. To ensure a respectful and responsible presentation, we plan to include educational materials that provide a well-rounded historical perspective, recognizing both the machine’s technological advancements and the broader impact of the war. By making this accessible on a global scale, we aim to create an inclusive learning experience that allows individuals from different backgrounds to engage with the material in a meaningful and thoughtful way.

 

Part C: Environmental factors

With our design, we are creating a single PCB as our only custom piece of hardware, hence reducing excess electronic components and unnecessary manufacturing overhead. Additionally, our decision to use PS/2 keyboards aligns with our environmentally conscious approach as these are widely available and can be repurposed from old offices/schools/labs that have since transitioned to newer models. Finally, by emphasizing digital resources in our open-source documentation, we reduce the need for printed materials hence reducing our environmental footprint.

 

Part A was written by Amelia, B was written by Nancy and C was written by Tanisha.

This week we worked on finishing up the Design Presentation slides and finalizing our quantitative use case requirements, trade offs, and testing and verification plan. We also picked up our new FPGA (moved from DE10 to DE0). Due to our design changes from last week, we updated the schedule, see below. 

The most significant risk that our project could face is the custom PCB not being completed in time. However, since we have decided to use a local supplier instead of one from China, the lead time is significantly reduced and we can afford to take all the necessary steps and time to ensure that our custom PCB will hopefully be successful. Since a big design change from last week, this week we worked on fleshing out the design of our peripherals. One big change was deciding on using a microSD card reader on the PCB rather than using the reader on the FPGA. This had been our original plan when we were still using an Arduino.

This week we faced larger design changes based on the feedback from our Proposal presentation. This led to an updated design where we decided to adjust the number of modules in order to stick to our primary use case of historical accuracy. Taking the advice and criticisms of our peers and faculty, we incorporated it into our iterative design. This was the determining factor in us deciding to move the functionality from our Arduino to the FPGA. For example, moving the rotor functionality to the FPGA board and by connecting all our external peripherals directly to the FPGA I/O pins. This also included switching our FPGA from the Altera DE10 Standard to the Altera DE0 Nano as the number of pins jumped exponentially from 40 to 80.

Part A: Public Health, Safety, and Welfare Considerations

Our FPGA-based Enigma machine replica is designed to be a safe and historically accurate educational tool for classrooms and museums. By using an FPGA instead of fragile electromechanical components, we eliminate risks associated with mechanical wear, electrical faults, and high-voltage circuits, ensuring safe hands-on use. The modular, lightweight design simplifies transportation and setup, making it easy for educators to integrate into various learning environments without specialized technical expertise. The product will be built with durable, non-conductive materials to prevent electrical hazards, with all components carefully selected to comply with safety regulations.

To ensure quality and reliability, we are sourcing PCBs domestically, maintaining high manufacturing standards and supply chain consistency. The result is a durable and practical tool that enhances historical education while prioritizing safety and ease of use.

Part B: Social Considerations

Our project is a historically accurate yet modernized Enigma machine designed to serve as an interactive educational tool. By offering a hands-on learning experience, it fosters an appreciation for cryptography, wartime history, and the evolution of computing. Its open-source design encourages collaboration among educators, students, and enthusiasts from diverse backgrounds.

With a focus on modularity and ease of assembly, the device is practical for use in museums, classrooms, and historical institutions. By making history interactive, we connect historical cryptography with modern cybersecurity discussions, providing value to both history enthusiasts and technology professionals. This project contributes to the broader effort of preserving and communicating historical knowledge in an engaging and meaningful way.

Part C: Economic Considerations

Our project is designed to be cost-effective and sustainable. By remaining open-source, we eliminate licensing and proprietary hardware costs, making it more feasible for institutions with limited budgets. Using an FPGA preserves the logic of the original Enigma machine while reducing maintenance needs compared to mechanical alternatives. The modular design further extends the product’s lifespan by allowing individual components to be replaced as needed.

Sourcing PCBs domestically ensures consistent quality, minimizes supply chain risks, and supports U.S. manufacturing. These choices balance historical accuracy with economic feasibility, ensuring that our Enigma machine replica remains a practical and valuable tool for education and historical preservation.

Part A was written by Nancy, B was written by Amelia and C was written by Tanisha.

Up till now, we’ve decided on a basic PCB layout, designed the pipeline from custom PCB to arduino to FPGA and selected various appropriate transmission protocols. We decided on which modules would handle which tasks; PCB handling I/O, Arduino handles protocol translation and FPGA handles encryption and computation. We selected the Altera DE10 Standard Development board because we are most familiar with the board and its environment. We also worked on and submitted our proposal presentation. We finalised the existing system and pipeline with all major components researched (Arduino, FPGA, PCB).  

A risk we were faced with was the uncertainty of ordering components / our PCB from China due to the current trade and economic landscape. The uncertainty stems from lead time, increased costs due to tariffs and potential halts to postal services from China. To mitigate this, we plan to look into risk/cost tradeoffs with local suppliers. 

On Tuesday, we went on a field trip to see CMU’s very own Enigma machine. After asking a librarian at Hunt where the machine was located and coming up empty handed, we contacted Sam Lemley, the Curator of Special Collections at CMU Libraries. He informed us that both of CMU’s Enigma machines were currently on loan to the Heinz History Center, but one of the machines (the 3 rotor one) would be back at CMU this week. We met up with Sam this past Tuesday (2/4) and he gave us a hands-on demo and brief history on how CMU came to get possession of the machine. It was very exciting to see a real Enigma machine up close!