Category: Nancy’s Status Reports

The past two weeks, Amelia and I have made good progress on the RTL. We currently have a working implementation of the rotary encoder, which can change the number displayed on the on-board 7 segment displays, but we do have some strange jumping issues when we try to implement it by scrolling through the alphabet, since there is some unexpected behavior on reset.  Additionally, we spent the majority of our time working on the external seven segment display that uses the MAX7219 chip. We had a lot of trial and error trying to adapt Arduino library code and existing RTL code (that was in VHDL, not Verilog) to work in Verilog. We used an Arduino to verify that the display itself worked, but after a lot of debugging, we successfully displayed a message early this week!

Later this week, Amelia and I worked on expanding our implementation of the variable rotor settings. For our demo, we only had users change the rotor starting setting (A-Z), but still hardcoded the rotor type (1-5) and ring starting setting (A-Z). On Friday, we spent most of the day implementing this and got all of the settings to display on the external 7 segment display! These settings could all be changed using the switches and buttons on the DE-10 and we verified that changing these settings reflected in accurate encryptions using an online Enigma simulator.

Now that the PCB has arrived, Amelia and I need to start wrapping up our RTL. This week, we will work on the shift registers for the lampboard, which should be pretty simple, and we will debug the rotary encoder implementation too. This will keep us on schedule.

As Amelia and I have been working on the RTL, it was very helpful to verify the individual components along the way. This made integrating them much easier. For example, we first got the rotor settings to display on the on-board DE-10. Using the on-board I/O (buttons and switches), we verified that the rotor settings could be changed and that they were correct when compared to the original Enigma machine using an online simulator. This included focusing on edge cases like the wrap-arounds from Z-A and the transitions at the knockpoints, which cause the other rotors to rotate as well. We also individually tested that the 7 segment display worked, and then incorporated that with displaying the actual settings. We will continue to run these targeted tests around edge cases and plan on conducting user testing to see how people who are not familiar with the design will interact with it. We want to ensure that the encryption is always 100% correct.

 

In the beginning of the week, Tanisha and I worked on routing the PCB, especially figuring out the routing around the shift registers and how best to organize the many LEDs/resistors to minimize trace complexity. Once she had finished the rest of the routing, we also worked to fix an issue with the 3.3V/GND pours on Fusion and I reviewed the layout one more time before Tanisha placed the order.

In the later half of the week, Amelia & I spent a lot of time in 1305 debugging the integration of the encryption modules with some basic GPIO using the buttons, switches, and 7-segment displays that already exist on the DE-10. This is a good stepping stone towards incorporating the GPIO from our PCB and also gives us a good way of demonstrating our progress in our interim demo.

More specifically, we initially had issues with the encryption itself being incorrect. One issue is that our 3rd rotor needed to be “rotated” once before encryption, so it was as if the first rotor started on Z when we expected it to be on A. While this was a quick fix, we also realized that we were overlooking the break code component of the PS/2 protocol. By incorporating an FSM that could alert our other modules of when a key was released (and therefore the break code was sent), we were able to fix our encryption and have the cryptographically correct result display when (and only when) the key was being held down on our external keyboard. This mimics how the lampboard will light up only when a key is pressed. Next, we moved onto incorporating more I/O. For the demonstration, we decided to make the starting rotor position for all 3 rotors variable, where switches would select which rotor to rotate and a button would allow you to cycle through the alphabet. After a day spent debugging this implementation, we successfully translated “Hello” to ciphertext and back on Saturday night! Here is a video of it working.

Next week, Amelia and I plan to work on capstone in the first half of the week before Carnival. We aim to incorporate the rotary encoder FSM that I wrote with our existing design and start on the I2C communication for the MAX 7-segment display. This will keep us on schedule since we want to have as little difficulties as possible incorporating the PCB by making sure the individual I/O components can work with our Verilog.

This past week, I worked on the microSD card implementation. I tried to test our microSD card reader with a multimeter to see what its idle voltage was (3.3V or 5V) but after doing some more research, I realized that the microSD card must be inserted in order to activate pull up resistors in the reader. So, while we waited for the microSD card to arrive, I started on the RTL of the microSD card reader, which is SPI protocol. I found a resource from MIT that implemented SPI microSD card protocol in Verilog, but it was dated for the modern microSD cards we were using. With this reference on SPI commands sent for microSD, I added additional steps in the protocol to make it compatible with our new cards. Additionally, I found a different microSD card reader that is made to operate on 3.3V and SPI mode, which would eliminate any concerns about if the reader’s I/O would need to be bumped up to 5V or down to 3.3V to interface with the FPGA. This has more pins (12 vs 6) but some of them can be tied to ground, so it is not too much of a difference.

This week, I will simulate the RTL with data that reflects how we will store the rotor encodings. Also, when the microSD cards arrive, I will see if our current microSD card reader works, and if so, I will hopefully try to synthesize with the FPGA I/O pins. Tomorrow, Tanisha and I will work on PCB routing together. Overall, we are on track and making good progress on both the embedded and RTL side.

This week, I mainly worked with Tanisha on the layout of the PCB. We finalized some of the arrangement of the PCB (such as moving the buttons and rotary encoder to be above the 7 segment displays) as our parts started to come in and we could get a sense for how they would fit together on top of the FPGA. Once these decisions were finalized, we were able to start thinking about how best to format our silkscreen and other aesthetic choices so that users could easily use our product and for it to be more historically accurate.

Above is our most recent PCB layout, with a single rotary encoder on top, 8 buttons to control the 8 seven segment displays, and the display underneath it. The microSD card reader pins are to the right and the lampboard is underneath the buttons. There are four shift registers to cover the many outputs of the lampboard, and the DE10 header is on the bottom right.

Additionally, Amelia and I met to discuss the plan moving forward on the RTL now that she had successfully implemented the PS/2 protocol. She also caught me up on what I had missed when I was sick on Wednesday, and we had our ethics discussion as a team after that. We decided that the most pressing issue after the PS/2 was to ensure that the microSD card protocol worked as well.

However, after the issues we had with our PS/2 keyboard (see the team status report), I started to worry that we may have the same problem with our microSD card reader, since it requires 5V. While there is a 5V source pin on the FPGA GPIO header, all of the GPIO pins are 3.3V logic, and we do not want to provide too much voltage to the pins. After looking at the Amazon reviews and description of the microSD card reader, it still seemed ambiguous if it could function with both 3.3V and 5V, as the reader does step down the 5V to 3.3V internally. I plan on testing the reader now that it has been delivered to see what the idle voltage of the MISO line is, and hopefully it is 3.3V. Otherwise, we may have to explore other ways to regulate the voltage.

Next week, I will focus on the microSD card functionality. This includes verifying that the reader will work with 3.3V so that we can finalize this on our PCB, and then I will move onto implementing SPI protocol for the microSD card in RTL. Our PCB is moving along nicely, and I will help Tanisha with the traces as needed. Overall, we are on track, especially since the keyboard issue resolved itself with Amelia’s hard work!

Since the last status report, I mainly worked with Amelia on completing a lot of the writing for the design report. I specifically worked on the use-case requirements, design trade studies, the system implementation for the custom PCB, the test and validation, and the risk management.

Additionally, when finalizing the components on our PCB with Tanisha, we realized that a matrix scanning implementation of the keyboard would be overly complicated and would require many GPIO pins. I spent some time researching alternatives to keyboards, since we did not want to implement a complicated USB protocol for a USB wired keyboard. When doing more research, I found that the Altera DE10-Standard had a PS/2 port which would support a PS/2 keyboard with a much simpler protocol, so we pivoted our design back to the DE10, which allowed for one PCB that will fit on the top of the DE10. This is also what I wrote about in the design trade studies section of our report.

We initially hoped to have our PCB out for fabrication before spring break, but due to our last minute changes in design and FPGA type, this will be delayed. I will work with Tanisha on the layout this week so we can have it ordered by this week. While we wait for the PCB to be delivered, I will also work with Amelia on the RTL so that we are not wasting time, which will catch us back up to schedule. I hope to complete the PCB layout by this week and start on the implementation of some of the RTL modules.

In the beginning of the week, I finalized the design presentation, especially making sure that our use case requirements were quantifiable and translated into quantifiable design requirements. Later, I worked on the design report, adding more to the introduction and use case requirements sections. Most of this was elaborating on how our use case and its social/economic/historical implications leads to our quantitative requirements.

I also worked with Tanisha on finalizing our PCB schematic. While reading the De0-Nano datasheet, I saw that we had overlooked how the ADC pins are on the bottom of the FPGA, unlike the 2 2×20 GPIO pins. However, the ADC pins are also only accompanied by 13 GPIO pins, so it would not be possible to put all of our I/O on the bottom pins. So, I began exploring how to split up our PCB into 2, with the rotor functionality on the bottom pins where the potentiometers would be (which would need the ADC pins), and the lampboard/SD card/keyboard using the top pins. Additionally, I spent some time looking for the footprint for the FPGA, but I could only find a Fusion-compatible version for the bottom pins. This was a concern since we wanted the PCB to fit perfectly over the top pins on the FPGA and we want the spacing between the two 2×20 headers to be accurate. However, since we can move some functionality to the bottom pins, we only have to use one of the 2×20 headers, eliminating this concern.

Finally, I also researched into interfacing with the ADC and SD card reader through the FPGA. I found two Intel IP cores that work with Quartus that could be helpful — the ADC and SPI cores.

In order to stay on schedule, Tanisha and I need to finalize the PCB schematic and layout before spring break, which will be a good amount of work but doable with us both. This week, I hope to finish this so we can order the PCB over break, and also continue to edit the design report once we receive feedback on our presentation.

This week, I researched into the peripherals we were considering using for our project and further refined the design. More specifically, we met with Prof. Chang on Monday, who suggested that we consider adding a small receipt printer to our design so that museum-goers could walk away with a copy of their encrypted message. I spent time researching into printers that could communicate via UART, and I found some resources that demonstrated using it for Arduino, which could be useful for implementing on the FPGA. Ultimately, we decided against the printer after having our weekly meeting, but the time spent researching more into the GPIO pins on the FPGA & UART protocol could be useful in the future.

Additionally, after receiving feedback from our proposal presentation, Amelia & I met to discuss how we could move more of our functionality onto the FPGA. We researched into the different FPGAs available to us, and saw that the DE0 Nano has 2, 2×20 GPIO pins, which would be sufficient for all of our peripherals given that we use shift registers. We also looked more into the documentation for the FPGA and evaluated whether we could use the existing micro SD card on-board, but decided it wouldn’t be feasible since it is reserved for boot-loading. After meeting with Tanisha as well, we decided that we could implement the entire design on just the FPGA.

I am on schedule since we are finalizing our design, the peripherals that we will use, and the communication protocols we will implement. This week, I help to finalize the design presentation, specifically refining the technical requirements with more quantitative values. I will also do further research into the microSD card reader and power consumption since moving fully to the FPGA, and will begin working on the PCB layout once the schematic has been changed to reflect our new design.

In the start of this week, I helped to finalize the slides for the design presentation, especially with refining the technical challenges and mitigations and relating them to the requirements we had defined on the previous slide. When our team met on Wednesday, Tanisha and I spent time discussing using shift registers for our keyboard and lampboard and further defined the peripherals we would need on our schematic. Later in the week, on Thursday and Saturday, I researched how we should power our design, which was something we received feedback on during our proposal presentation. We had decided that the FPGA should be plugged into a wall outlet, but were unsure about what to do for the Arduino. Having to consider power consumption is something that I have not done a lot before, and took a good amount of time researching the basics, which I summarized in the attached document. Ultimately, I decided that we should use rechargeable AAA NiMH batteries with an Adafruit PowerBoost 500 Basic, which is a DC/DC boost converter. While it requires more work to integrate with the Arduino than a 9V battery connected through the power jack, it will last longer. I also considered a rechargable LiPo battery with a similar converter, which would have a greater capacity, but I liked how using AAA batteries is more accessible and is less of a fire hazard that would need to be mitigated for use in a museum or classroom.

My progress is on track since this was an important aspect to decide on as we start designing our PCB schematic. I will continue to work with Tanisha next week on reviewing the exact parts we selected for our PCB and verifying the schematic before I start on the layout. I will also work on summarizing the work we’ve done on the embedded side of the project that we can include in our design presentation.