Author: alobo

Team Status Report for 4/26

This week we started and finished the final presentation slides and Nancy gave an amazing presentation on Monday!

Tanisha also fixed the issue with the “i” on the lampboard by desoldering it and moving to another pin on the shift register.

Nancy and Amelia worked to fix the issues with the MAX 7-Segment glitching when trying to adjust the rotor settings. We realized this issue was due to lack of resistors on the buttons which left the input pin floating — giving us unpredictable and random signals, which caused the glitches. Nancy and Amelia fixed this by updating our RTL to change the rotor settings while the button was pressed rather than using a press and release FSM for the buttons.

In the next week, we need to finish the poster, make our video, and update our report.

Tests Run:

  • Design rule check, verified design meets manufacturing requirements with 0 errors (PCB design)
  • Electrical rule check, verified power and ground connections with 0 errors (PCB design)
  • Continuity test on multimeter, ensure proper fabrication with 0 open circuits throughout board(PCB fab)
  • Verified voltage levels at every connection for all LEDs, resistors and GPIO (rotary encoder, FPGA header, shift registers) (PCB fab)
  • Validated 100% of traces by powering PCB and validating output voltage levels against schematic (e.g. LED on, logical high) (PCB fab)
  • Peripheral unit tests: lamboard, light up random sequence of 50 letters (100% success)
  • Peripheral unit tests: keyboard, continuously type for 2 min and ensure keyboard functionality (100% success) and lampboard functionality (100% success)
  • Integrated user tests: test fully integrated product on 5 people, test and check encryption with online simulator (100% success on all 5 people for all encryptions)

Updates to Design:

  • Moving from button press and release FSM to only changing settings on button press itself
  • Remove microSD card functionality due to power constraints

Amelia’s Status Report for 4/26

Last Sunday, Tanisha and I started and finished the slides for the final presentation. 

This week Nancy and I continued to work on trying to figure out the issue with the glitches when integrating the rotary encoder and the MAX 7-Segment display. We rewrote the code and FMSs multiple times when trying to figure out this issue. We had believed that the issue was with the MAX itself. However, one test we did isolated the PCB buttons and compared them to the functionality of the DE10 buttons. We realized that the PCB buttons were the issue and not the MAX. We realized that we had forgotten to add resistors to the buttons to prevent the input from floating which was exactly the behavior we were observing. Nancy and I realized that the only way the buttons could be functional was if they were continuously pressed because that is the only way to ensure the buttons are asserted low (buttons active low) and not at a weird floating value. To fix this, I changed the RTL so that you have to press the button for whatever setting you want to change while you rotate the rotary encoder. This ensures that we know what setting is being changed. Once I implemented this all the glitches on the MAX were gone. The glitches definitely were caused by the buttons being in a weird state. On Friday, I added a feature that blanked the MAX display when one setting was being changed in order to make it more readable. I also cleaned up some of the code. The RTL is pretty much complete now and we have implemented everything we had hoped to, excluding the button FSM which we fixed by holding down on the button when changing the rotors. I also started working on the poster due on Monday. 

In the next week, we need to finish the poster, make our video, and update our report.

Amelia’s Status Report for 4/19

This was a very productive week! On Monday, Nancy and I fixed the bug we were facing last week with the rotary encoder not wrapping around from Z to A. We also added the RTL for the enigma rotor starting, rotor number, and ring position to display on the MAX seven segment display. We then implemented the rotary encoder modules with the rest of our integrated RTL. We are currently facing a few issues/glitches with the integration between how values are displayed on the MAX seven segment when the rotary encoder is turned. 

On Wednesday, Tanisha had finished running tests on the completed PCB and Nancy and I worked on integrating the current code and started working on the lampboard shift register logic. On Friday, Nancy and I started working on the shift register logic — we started with a single shift register with 8 LEDs hooked up on a breadboard. By Friday afternoon, we finished expanding this to the full PCB lampboard, here is a video of the lamboard integrated with the FPGA + PS2 keyboard. 

Also, on Wednesday, I also created a CAD model of the wood housing for the PCB and FPGA and laser cut it on Saturday. Below is a picture of the wood housing with the FPGA inside and the PCB mounted on top!

I have learned so much over the course of this semester. One of the first challenges was hooking up the FPGA with all of the peripherals which required learning how to decipher several protocols (PS2, SPI). To do this I looked through old git repos and read lots of documentation and datasheets. The RTL we wrote for this project was much different than in any of the other hardware classes I’ve taken so far because of all the integration we had to do. This RTL also had to be synthesized on real hardware (which I haven’t done since 240) which had its own share of issues and required lots of heavy debugging and time spent on Reddit forums. I also learned how to CAD and use the laser cut software (CoralDraw) this semester for laser cutting the housing. I watched videos online to figure out how to CAD using onShape. I also asked some of my mechanical engineering friends for tips on how to make box joints. For laser cutting in TechSpark, I asked TechSpark employees for help and other students for help using the machine. 

Amelia’s Status Report for 4/12

Last week (carnival week), I worked with Nancy to synthesize the RTL she had written for the rotary encoder. We debugged and synthesized that code and hooked it up on a breadboard to the GPIO pins of the DE10. After working through a few issues regarding the notches on the rotary encoder skipping to many letters when turning, we were able to successfully synthesize the rotary encoder logic on the DE10. We do, however, have one issue with the rotary encoder not wrapping around from Z to A, which we plan to fix next week — it works fine going from A to Z and backwards through the alphabet from Z to A, however, we have a skipping issue when jumping from Z to A directly. 

Last Thursday (carnival Thursday), Nancy and I spent the entire day in 1305 working on the RTL for the MAX Seven-Segment Display. This involved writing a SPI protocol handler to replicate the Arduino code that the MAX7219 chip was designed to handle. However, we were unsuccessful. We tried again Monday of this week, and in a couple hours of debugging we were able to display “DEADBEEF” on the MAX Seven Segment!

Yesterday (Friday), Nancy and I reconfigured our encryption to take in user input from the FPGA for ring setting and rotor number (previously we only had this capability for rotor starting position which we demonstrated during our interim demo). By Friday night, we were able to configure each setting (rotor number, rotor starting, and ring position) on the FPGA and have these values displayed on the MAX Seven Segment. We tested our encryption for different configurations against the online Enigma simulator and everything worked great. 

For verification, we tested the RTL for different ring positions, ring starting positions and rotor number – we verified this against the online Enigma simulator. We plan to user test this with team B4 – Connexus and have them try different configurations and verify with the online simulator that it performs as expected. For the rotary encoder we plan to test its functionality with users trying to use it at varying speeds and intensities to ensure it will hold up in a museum / classroom setting. Nancy and I have already verified for all edge cases (end of alphabet, highest and lowest rotor numbers, etc.) and the encryption worked as expected.

We accomplished our goal this week of writing the SPI handler for the MAX7219 chip and adding configurable for the rest of the encryption settings. Nancy and I only have a few more tasks left on the RTL side — integrating the rotary encoder with the rest of our RTL, writing the RTL for the lampboard shift registers, and finally, the microSD card. We are on track to complete all the RTL and hopefully will be done with everything by the end of next week. This should leave ample time for us to design nice housing for our PCB and finish up all the documentation. 

Amelia’s Status Report for 3/29

As mentioned last week, I had some challenges integrating the PS2 protocol with the encryption modules. I spent a considerable amount of time at the beginning of the week fixing these issues and getting the code to synthesize on the DE10. The goal of this integration was to have a key pressed on the PS2 keyboard be encrypted through the Enigma encryption algorithm and to display both the plaintext letter and ciphertext letter on seven segment displays on the FPGA. I faced numerous challenges, the majority dealing with the press and release of the PS2 key. 

After debugging, I realized that each letter was being double encrypted, so when a single button was pressed, it was encrypted twice. However, on Friday, Nancy and I spent 12 hours in 1305 figuring out the issue. The main culprit was the letter was being sent twice via PS2 through the “make” and “break” codes. While we had been suspicious the break code might be the issue, we didn’t realize it was the root cause of our issues until we took a slo mo video of the seven segment display and figured out that “F0” was being flashed after release. We wrote another FSM to track the history of a key press and release and use that value in encryption. By Friday night, we had successfully integrated the PS2 keyboard with the Enigma encryption. 

On Saturday (today), we spent the day in 1305 variable rotor starting settings via switches to allow the user to change the rotor starting settings. Nancy explains the issues we faced with this in her status report. By Saturday night, we had successfully added variable rotor starting settings to our integrated PS2 and Enigma encryption system and we are demo ready! Here is a video of us encrypting “Hello” from plaintext to ciphertext and back to plaintext — demonstrating how symmetric cryptography works! 

Next week, Nancy and I plan on testing and integrating the rotary encoder and MAX 7-segment display with the rest of our system so we are ready to hit the ground running when our custom PCB comes in!

Amelia’s Status Report for 3/22

This week I exhaustively tested the Enigma encryption that I had simulated last week and verified against the online Enigma emulator. I tested using different rotors, different rotor orders, different rotor starting positions, and different ring settings and everything worked as expected. After completely verifying the encryption I started working on integrating the encryption with the working PS2 protocol handler from last week.

My goal this week had been to integrate the keyboard inputs with the encryption algorithm and synthesize, however this turned out to be a little ambitious since I had work for other classes I needed to catch up on first. I started by writing a testbench to simulate the integration. It took quite a long time to integrate  since both components had signals on different clocks however I got it working and simulated it by Wednesday. I wrote a chip interface and synthesized later Wednesday, however I had a ton of latches in the new encryption code that I had overlooked. I had to focus on my other classes and midterms at the end of the week so my goal for next week is to fix all of these latches and synthesize the integrated PS2 and encryption logic.

Amelia’s Status Report for 3/15

This week I finished my main goal of getting the PS2 protocol working and synthesized on the DE10! At the beginning of the week I debugged my own implementation of PS2, wrote and testbench and got the simulation working. However, I decided to pivot to modifying an existing PS2 protocol that I found online after realizing I was missing some of the handshaking signals in my current implementation.

 I spent Tuesday debugging the online implementation and updating it to run on a DE10 (the old version was for DE2). On Wednesday, I was able to synthesize with only a few minor bugs! However, when testing with the Perixx PS2 keyboard we had ordered from Amazon, only the scan code “AA” was sent which means that the keyboard’s “Self Test Passed”. After looking at the user manual I realized that the PS2 port on DE10 was only providing 3.3V and the keyboard required 5V (oops). After looking at some PS2 reddit forums, it seemed like most people online agreed that old PS2 keyboards were compatible with PS2 ports of various FPGAs and the newer Perixx PS2 keyboards seemed to just not work.

We decided to go hunting on Facebook Marketplace for some old PS2 keyboards and Tanisha found someone selling 2 keyboards close to campus. Tanisha and I met the seller outside the CMU Police station on Friday and got two old HP PS2 keyboards for $15. The seller actually ended up refunding the cost as good luck for our capstone so it ended up being free! I went straight to lab and the FB Marketplace keyboard worked immediately! In the video below I just press a few keys on the keyboard and the scan code corresponding to that key is displayed on the FPGA’s seven segment display. 

I spent Friday and today working on the actual enigma encryption. I based my code on some of the logic in this FPGA enigma machine and hardcored the rotor settings based on the 1930 ‘Enigma I’ model  and the reflector on “Reflector B” from spring 1942. I got the encryption working in simulation today and verified my outputs with this online enigma emulator. Next week I hope to get this code synthesized with keyboard inputs and the rest of the inputs (rotor, ring, reflector) hardcoded.

This week I accomplished more than I had hoped and the RTL is coming along well! After synthesizing the encryption with the keyboard I’ll start looking into the microSD card RTL and rotary encoder FSMs. 

ps2 demo

Amelia’s Status Report for 3/8

Last week I worked on finishing up the design report. I wrote the system implementation for all of the RTL modules, designed new FSMs for the SPI and PS2 protocol, worked on design trade studies with Nancy, transcribed everything to LaTeX and created a testing plan for the RTL. I also created new block diagrams based on our updated system architecture. This week I wrote all of the RTL for the PS2 protocol, simulated it and am currently in the process of debugging.

Team Status Report for 2/22

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.

Amelia’s Status Report for 2/22

This week I spent most of my time working on the design report. I wrote the Abstract, Introduction, Use-case Requirements, Architecture and/or Principle of Operation, Design Requirements, Design Trade Studies, and some of the Test and Validation and Project Management sections. We just need to finish the System Implementation and Test and Validation sections once our custom PCB is finalized. I carried most of the writing for the design report because Tanisha and Nancy are occupied with making the schematic and layout for the custom PCB. I also iterated on the FMSs for the rotors and Enigma keypress from last week to removed some unnecessary reset states. — see updated FSMs below. Next week, I will finish up the design report and start planning out my Enigma modules before spring break.