Category: Status Reports

Team Status Report for 3/29

This week the PCB team finished working on the PCB and sent it to order. The challenges we faced were dealing with Fusion 360 irregularities, double checking all our safety checks, and figuring out our ordering strategy. Since it would take a longer time than we anticipated we had to select the rush order option which ate up a portion of our safety chunk of our budget. However, since we have spent a longer time on the PCB than we anticipated, we are also more confident in its ability to work correctly and are still well within budget. A challenge we foresee would be on board PCB debugging but since we have mitigated everything we could on the pre-manufacturing end I am confident in our abilities to make this succeed. More challenges we had to deal with was just planning out spacing on the board to maximize aesthetics, cost, functionality and speed of delivery.

The Verilog team has been working consistently this whole week to integrate the encryptions with the interfacing of the PS/2 keyboard. They have successfully managed to get a user input from the keyboard, encrypt it and display this to the onboard 7-segment display on the FPGA!! This came with more than it’s fair share of challenges however – handling flashing break codes between encryptions, random letters being encrypted upon first key press, and debouncing algorithm complexity. This is all being done in preparation for our Interim Demo this upcoming week.

As a team we plan to present this working encryption input and output scheme alongside our PCB narrative and final design. We will discuss our use case briefly before moving on to talk about the challenges each of us faced throughout this process – something that has also been detailed through all our status reports. This would be the majority of our work for the upcoming week.

Our team also met with Professor Chang this week to discuss our design layout plans. Since we last spoke to her we had switched to an external keyboard as she recommended for user friendliness, however as we are now doing a PS/2 keyboard we were limited by the vintage offerings (and power considerations – see team status report 3/15). She approved of our PCB layout and user interface and advised us on possible enclosure ideas. We decided that could be a stretch goal for us after completing all of the functionality.

 

 

Tanisha’s Status Report for 29/3

This week I finished all of the routing of the PCB and ordered it [final version attached]. After routing I went through our completion checklist (pours, rechecked documentation for all pinouts, ran ERC and DRC, ensured trace width safety of 10 mils, and all relevant silkscreening was included). There were a few challenges with Fusion 360 during this checklist but I managed to resolve all issues (e.g. errant wire stubs that simply would not disappear, heavily cleaned up routing, and re-organization of components and pins). When it came to ordering we faced another challenge with realizing manufacturing time was not built into the previous OshPark measurements we had looked into previously. This led to us weighing the costs of different sped up manufactoring options vs possibly pivoting back to JLCPCB from China but facing the risk of getting our PCB stuck at customs similar to other PCB orders from CMU. However, after a team discussion I went forward with the expedited order option and hope to have it arrive and start soldering immediately after Carnival.

The rest of our ordered parts also arrived, the new SD Card Reader, SD Cards and SMD resistors.

I also prepared for our Interim Demo by creating slides for our use case and my progress. I plan to distribute print outs of our PCB design iteration process and talk through the challenges faced and the different changes between each of them. I think this well encapsulates the work I’ve put in for this project over the past few months. I also plan to lay each of the individual parts out (rotary encoder, MAX7219, SD card reader, LEDs, resistors etc) so that our showcase would display a clear idea of what our PCB consisted of.

This week I plan to work on our Interim Demo and help with overall Capstone tasks. That would include start thinking about our Final Presentation, individually test our GPIO and figure out the new SD cards and reader integration.

 

Tanisha’s Status Report for 3/22

This week I worked on further testing of the PCB in simulation. I worked on generating heat maps using the PCB thermal simulation software as part of Fusion 360. Simulating both external temperature sources and measuring the distribution as well as electronics cooling to determine if electrical bodies exceed maximum allowable temperature given natural air convention. This was based on supplied power consumption and thermal loads. The results were helpful to verify there were no hotspots with a surplus of heat anywhere hence complying with safety standards. I also updated our PCB to include a new SD card reader as we swapped our old one with a new one that includes a 3.3V breakout board as a mitigation technique we learned from the PS/2 keyboard. I am still waiting on the SD cards themselves to arrive but in the meantime I got started on looking into writing appropriate codes to these cards and how H2GTestW can be used exactly. I understood we can use it to generate tests for speed of writing to and reading from our SD card which will be helpful when integrating it with our PCB. Finally, I continued working on tracing the final PCB out with this design alongside Nancy.

Team Status Report for 3/22

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.

Nancy’s Status Report for 3/22

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.

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.

Nancy’s Status Report for 3/15

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!

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

Team Status Report for 3/15

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.

Tanisha’s Status Report for 3/15

This week I worked on completing the layout of our PCB and ordering all of our parts. We ordered the rotary encoders, MAX7219 7-Segment Display, SD Card readers, and sourced the remaining miscellaneous parts (Micro SD cards, adapters, buttons, LEDs) . Due to a shortage in stock we could only order 2 rotary encoder instead of 3 so we updated our design to only include 1 rotary encoder.

Nancy and I reorganized our PCB layout to be much cleaner, more historically accurate and updated power considerations. We updated the layout of our PCB to be historically accurate to the actual Enigma machine’s lampboard (different from the standard qwerty keyboard – attached). We also adjusted spacing for 10 mil traces as a safety precaution, updated our button footprint with the new tactile button we settled on and changed the layout to float above the FPGA at a diagonal so the onboard buttons and 7-segment display can be accessed as a fallback option. The in progress PCB layout is attached below.

I worked with Amelia a little on the logic of our PS/2 protocol that she wrote and also worked on finding the solution to a setback when our current PS/2 keyboard didn’t work with the power supplied from the FPGA. Nancy and I are planning to mitigate this potential setback with the SD Card reader by testing the required power level for a measurement to be read. Accordingly, we can build in a voltage regulator to our PCB so we don’t have power issues during integration.

This week I will order remaining small parts including 100 Ohm resistors and  right angled header pins. I also plan to finalize PCB layout with updated power considerations, finish the traces and add silk screen labelling for user friendliness. Once PCB work is done, I will work on formatting and writing our MicroSD cards so they adhere to a format that is readable by our SD Card reader and hence our SPI protocol can accurately extract information.