Posted on

Jae’s Status Report 3/26

This week I was responsible for working with Don to make sure the microcontroller on the DSKY and the I/O driver that Don was building spoke with common protocol. Since we were using UART, we decided to go for a plaintext communication such that we can easily debug using a serial terminal window. We gained insight into how to send display data packets to the DSKY and how the DSKY was going to send NOUN/VERB numbers to the AGC core.

I was also responsible for bringing up and verifying that the math functions (SIN, COS, SQRT) were operational and accurate. These functions were from the original Apollo missions so therefore they were well implemented, We are now ready to start writing code for the demo and test on the architecture once it is up and running.

Posted on

Team Status Report 3/26

This week didn’t bring us any new risks. In order to minimize risk we worked on debugging the RTL, coding up our interface between the DSKY micro-controller and the AGC CPU, and writing the AGC assembly code.

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.

There has been progress on the AGC code to be run on our architecture. We have verified that all the math functions were in working order and the simulations were accurate. Therefore, we will soon begin installing Linux on the FPGA SoC core and attempt AXI communication with the FPGA. This step is important for the demo and the AGC programs as we have to be aware of the AXI’s functionalities and limitations, which could be of moderate risk.

Posted on

Christopher’s Status Report 3/26

I spent most of this week debugging as much as I could wile waiting for my partner to finish his portion of the RTL. I compiled the finished portion of the RTL and caught a few bigger conceptual bugs that our pipeline previously had. One example of this is a bug where we had hardwired the bank registers to the memory addressing unit so it would know which bank to address into. The issue with this is since we are pipe-lining we need the relevant banks for reading (which takes place in decode stage) and writing (which takes place in writeback stage) and these might be two different values. To fix this we had to split our adresing unit and have our bank bits be forwarded throughout the pipeline. I also figured our how we will compile our SystemVerilog files (harder than I thought because I’m used to makefiles doing it for me).

I am ahead of schedule. However as I have had more time the last couple of weeks compared to future weeks so this is kinda expected. Next week I hope to get the pipeline working and running the tests without failing. However I still think this is ambitious and this goal is not entirely dependent on me (waiting for my partners to finish their RTL).

Posted on

Jae’s Status Report 3/19

This week and the previous week I primarily worked on finishing the board. At this point in time, the board is fully functional and no design issues were detected. The board bring up was actually not painless at all however, since all the useful gear at Techspark were not operable due to the lack of staff during the break, therefore everything had to be hand placed and hand stenciled. Furthermore, the stencil received was thicker than ordered, therefore this resulted in many solder bridges that I had to manually fix with a soldering iron under the microscope. Afterwards, an acrylic was laser cut and keycaps and standoffs were installed, completing the piece.

My goal for next week is continue working on the ESP32 software (https://github.com/Absolute0K/DSKY-firmware) and researching the AXI interface for the FPGA-ARM communication for the demo.

Posted on

Team Status Report 3/19

This week didn’t bring us any new risks. In order to minimize risk we made progress on the core components of our design. I worked on writing the pipeline, tests, testing infrastructure, and sub-units. Jae even managed to finish the DSKY which was a risk of not working or being complete which is now completely mitigated because it is done.

Only minor design changes occurred in the pipeline with almost no cost because it just meant writing the SystemVerilog a bit differently than expected and changing the diagram (so minor that I didn’t think it was worth including the diagram).  Also, another minor change was that the protocol to be used for FPGA-DSKY communication will be UART and not I2C. This was changed due to the ease of use of UART compared to I2C and the fact that using a bus was not needed.

On the software side, we are working on figuring out the AXI protocol for ARM-FPGA communication for the demo. Goal for next week is to install Linux on the ARM core and attempt sending and receiving of data with the FPGA.

Posted on

Christopher’s Status Report 3/19

I spent 8 hours a day from Wednesday to Wednesday (got COVID at the beginning of break but was more or less asymptomatic so was quarantining for a week and a half with nothing to do). I finished the assembler then wrote all the unit tests in AGC assembly (with the exception of the IO stuff) I then wrote the entirety of our header file wrote the entire pipeline and decoder in SystemVerilog and wrote many of the sub-units (branching unit, stalling unit ect.) In doing all of this I caught issues with our design and that changed our pipeline design and got a better understanding of what some of the instructions do that I previously did not fully understood.

I am well ahead of schedule. However as I will have more time (especially from break) the last couple of weeks compared to future weeks. Next week I hope to get the pipeline working and running the tests without failing. However that is probably a bit ambitious of a goal for one week (I also need to catch up on some of the classes I missed last week).

Posted on

Team Status Report 3/5

This week didn’t bring us any new risks. In order to minimize risk we worked on one of the more uncertain aspects of out design, the assembler. It has been finished. This minimizes the risk of use not figuring it out because we have not done it before.

As we have now finished out design report we are now more aware of some of the tasks that we might have not thought about doing. However our plan still looks good. Thus we have no new big changes to our schedule this week.

The PCB has been ordered. This is a big part of risk mitigation because the fact that we have already ordered it (and should get it over break) means that we will have to worry about a delayed arrival extending the critical path of our schedule.

Posted on

Christopher’s Status Report 3/5

This week I mostly focused on finishing the design review report. I was responsible for writing the abstract, introduction, index words, summary, and project management. I was also expected to contribute to the design requirements, the design trade studies, the system implementation and the test and verification sections in the areas in which I know best about. The reason why I carried a bit more of the writing load is because I did a bit less work on the project than the others this week. I also read over everyone else’s portion and did the bibliography. In addition to that I have been working on the assembler but haven’t made too much progress. I also tweaked the assembler it now works for our purposes as far as I can tell (will be able to test more once I have the RTL finished). Thus I am caught up for this week as I finished the design report and have the testing infrastructure reasonably complete (at least before we finish the RTL). Next week I will be working on the RTL (sub-modules and hopefully if I can get ahead because it is break I can start putting them together).