Author: alobo

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. 

Amelia’s Status Report for 2/15

This week I mostly worked on designing our finite state machines for the rotor settings and for the keyboard (see below). I also redesigned the top layer view (see below) of our schematic (with potentiometers) after getting feedback from course instructors who advised that we should include a turning rotor mechanism (we decided in the form of potentiometers) to help mimic the look and feel of the original Enigma machine. I also redesigned our system block diagram (see below) by removing the Arduino after receiving feedback from our proposal. Now our design only consists of the FPGA, custom PCB, and keyboard peripheral. I also researched the Altera DE0 Nano board as a replacement for the Altera DE10 due to the increased number of pins we’ll need since removing the Arduino from the system. Lastly, I worked on the design presentation slides. 

Due to our redesign, I did not research UART like I had mentioned last week because UART is no longer needed since removing the Arduino. Next week I’ll work on finalizing the signals and modules for RTL encoding. Next week I will also likely spend quite a bit of time on the Design Report — this is because Nancy and Tanisha are working hard to finish the custom PCB to send to the fab before spring break.