Jae’s Status Report 4/16

This week I completed the entire firmware for the DSKY, including the VERB-NOUN pair acquisition and the creation of packets to be sent through UART to the FPGA. Furthermore, I completed a Bluetooth module that will emulate as a “telemetry” between the AGC and Ground Station “Houston” or the Python demo script. The firmware is multithreaded (FreeRTOS) and therefore I ran into extremely unpleasant bugs with race conditions and priority inversions, but all issues have been finally resolved. The plan is to use the DSKY’s ESP32  module to receive mission data via Bluetooth, and allow the AGC to perform calculations on the data then send them back through the Bluetooth channels. At this moment, the DSKY firmware and hardware is fully verified and I plan on working on integration with the AGC and completing the Python demo next week.

Team Status Report 4/16

One risk we mitigated this week was incorrect behavior with double word instructions (MP and DDOUBL). We got multiply working by running it on our testing suite in simulation then reading the waveform. We also worked on our I/O unit, specifically with UART interface logic, to minimize risk as we move into the high-level integration of our entire system next week.

We were able to fully test and verify in hardware the workings of UART TX (Transmission of data from FPGA AGC to DSKY) through using both an oscilloscope and via an FTDI UART to USB converter. We are still working on RX. We plan completing full integration next week.

We have no new big changes to our schedule this week. We are on schedule in the terms of RTL and ahead of schedule in the terms of DSKY work

Christopher’s Status Report 4/16

My task for this week was sharing synthesizing the design on the chip with Donny. However due to Donny being behind I ended up writing the parent module and the transmit module of the IO unit for Donny. I also synthesize the design and made the fixes necessary by myself. However since Donny was not done with the receiving module as of the writing of this I could not synthesize the entire design (basically was just missing the receiving module). Even though we are technically slightly behind (could not synthesize) hopefully we will finish that in our meeting today. Our plan for next week is integration. None of use really have a specific task because we will all be there to help debug our prospective bugs if any come up during that. In addition we should probably make the slides for the final presentation which I believe is in 2 weeks (we will likely each claim a few slides for that)

Jae’s Status Report 4/9

This week I worked on finishing the entirety of the AGC Assembler code for the AGC. This mostly consisted of a simple FSM-like loop that selects appropriate program to execute when a correct program number is entered. For instance, VERB 39 NOUN 1 will run a program to calculate the delta-v required to escape a planetary body’s gravitational field (escape velocity). Other programs include calculating translunar injection velocities, Hohmann transfer orbital transfers, and orbital plane transfers. Furthermore, we realized that the SQRT function from the Apollo missions used instructions which were descoped, therefore I had to implement a custom single precision square root subroutine. The sine functions from the Apollo missions are still being used for calculations.

My goal for next week is to finish validating the AGC program and debug on our SystemVerilog implementation. I also plan on working on finishing the Python demo visualizer.

Donovan’s Status Report 4/9

Earlier this week, I assisted Christopher in debugging our CPU implementation to work with multiplication, division, augment, diminish, and increment instructions.  Although we reached a consensus that these instructions were working, we’ve discovered recently that our double-precision computations don’t work the same way as the yaYul simulator implementation.  For cleanliness, we have decided to forego changing our multiplier and divider circuits as well as adding a double precision adder.  I am currently writing those implementations in SystemVerilog in anticipation of verifying their correctness with example assembly programs. These changes will allow us to implement a CPU that meets the capabilities of our desired demo programs.  Following these changes, I will make updates to the I/O “register file” to support Jae’s desired I/O format, then implement the I/O serial interface.

Team Status Report 4/9

This week a new risk is that we are having trouble with double word instructions (MP and DDOUBL). If we cannot get those working we could be in trouble. In order to minimize risk we worked on debugging the RTL by running it on our double word instruction tests. Other things we are doing to minimize the risk of our project not working is coding up our interface between the DSKY micro-controller and the AGC CPU, and writing the AGC assembly code. The AGC CPU is therefore in the testing and verification phase, and we will begin full integration with the DSKY hardware soon, as well as the AGC demo programs.

We have no new big changes to our schedule this week. We are on schedule in the terms of RTL and ahead of schedule in the terms of DSKY work.

Christopher’s Status Report 4/9

I spent most of this week debugging the RTL. I got the rest of the test cases working this week and helped debug Jae’s code when it was running on the RTL simulation. I also changed the pipeline to support an instruction we did not previously think we were gonna use (DDOUBL). Next week I hope to start synthesizing our code and help Jae with any more debugging. I am on schedule but I doubt I will be able to do everything I need to do next week because of a dependency on Donny.

Jae’s Status Report 4/2

This week was spent mostly spent continuing to work on the demo programs for the AGC and studying more on the AXI-AGC interaction. For the demo, a simple visualization script running on Python will demonstrate the orbital mechanics calculations of the AGC. To do so, AXI will be used to send simulation mission data to the AGC, and after the AGC calculates required orbital delta-v or other parameters, will send the calculation results back to the AXI to the python script. I will be running a simple 3-body simulation of the Moon, Earth, and the space-craft. For the visualization library, I will most likely use matplotlib to plot a simple 3d motions of the planetary bodies and the spacecraft.

I will continue to work on finishing the DSKY firmware next week, especially since I am now aware of the I/O specifications from the AGC Verilog code. I will then finish up the AGC demo code.

Team Status Report 4/2

This week didn’t bring us any new risks. In order to minimize risk we worked on debugging the RTL by running it on our custom test cases, coding up our interface between the DSKY micro-controller and the AGC CPU, and writing the AGC assembly code. The AGC CPU is therefore in the testing and verification phase, and we will begin full integration with the DSKY hardware soon, as well as the AGC demo programs.

We have no new big changes to our schedule this week. We are on schedule in the terms of RTL and ahead of schedule in the terms of DSKY work. The DSKY firmware will be fully complete by next week and the AGC demo programs will start to take shape.

Christopher’s Status Report 4/2

I spent most of this week debugging the RTL. I compiled the finished portion of the RTL and resolved all the lint issues with my portion of the code. I then traced through the most basic test case I wrote INCR.agc. This test case branched then incremented a few addresses in memory before ending. Getting this test case to work required me to catch several bugs. One with the reset value of the pipeline registers, one with reading from ROM, a couple misconceptions in the addressing unit and in the pipeline and some issues in the decoder. According to the schedule Donny and I have one more week till we pass all the test cases. We are on schedule but need to stay work hard next week to stay on schedule.