Month: February 2022

I switched gears a bit this week, and first began gaining familiarity with Quartus’s IP Megafunction generator.  Using the Intel manuals I had recently browsed, Christopher and I configured and procured the Verilog files for our block RAM.  We are currently unsure of how exactly we want to register the RAM ports, but we plan to explore this later next week.  Most of my work this past week involved writing modules in SystemVerilog for our mostly one’s complement ALU.  The one’s complement adder/subtractor with end-around-carry correction has been written.  I realized that signed multiplication/division in one’s complement would be quite time-consuming to develop, so I decided to configure a combinational multiplier using the LPM_Mult megafunction in Quartus.  Because this is a two’s complement multiplier, I also wrote modules to convert between the two forms.  These are instantiated at the ports of the LPM_Mult multiplier.  All written modules still have yet to be verified.

This week didn’t bring us any new risks. As with last week, there are areas of our design that still need to be fleshed out, and they could present unforeseen roadblocks later on. In order to minimize this risk, we will produce a detailed design report that explores all of these possibilities in the next week and a half.

We’ve been working on the deisgn report and that is uncovering some of the stuff we still need to think about. For example the assembler pipeline, the software demo, and the details of the components (i.e. multipliers and dividers). However we have no new big changes to our schedule this week.

After we presented, we talked with our TA about potential risks and mitigations. We came up with basic high level attributes, such as: If the PCB has errors, bodge wires will be used to discretely fix the traces. If the worst happens and the PCB goes up in flames, then we will opt for a software DSKY demo. If our critical path is longer than 200ms, we will weigh the cost/benefits of spending more time optimizing or opting for a slower clock. If some of non-essential instructions are costing us too much time/effort, we will descope them if necessary. Finally, if we are running out of time, we will focus on creating a simple but compact demo that demonstrates the absolute key features of the DSKY.

This week I was responsible for watching and filling out the peer reviews for my section, as well as rehearsing and delivering my presentation on Wednesday. Meanwhile, I completed the first revision of the PCB and resolved all the ERC (Electrical Rule Check) for my schematics and DRC (Design Rule Check) for my PCB. I quadruple checked my schematics against all the component datasheets and made sure my design rules were all within specs for PCBWay (our PCB fab). I am currently on track to do another round of final checks and begin the process of sending out the gerber files. In the upcoming week, I will start the purchasing process of the PCB as well as the components from Digikey. With the components/PCB purchased and on route, I will begin the firmware/software development process as I wait.

Although I planned to have already finished the remainder of edits to our CPU pipeline diagram, altsyncram megafunction parameters, and AXI clarification, these tasks are ongoing, and I plan to complete them by tomorrow evening.  I developed the early drafts of our high-level system block diagram (to be presented during the design review), which required me to study Jae’s work on the PCB, microcontroller, and serial communication fronts.  Along the way, Jae and I clarified design details regarding I2C communication between the ESP32 microcontroller, the DSKY PCB, and our AGC assembly programs.  We don’t plan to implement interrupt capabilities in our microarchitecture, so we need to write a main program that effectively polls inputs and regularly updates the display when necessary.

This week my primary focus on the programs that will be run on the AGC and finishing up the first revision of the PCB. I have been analyzing sample AGC assembly routines and experimenting with certain basic instructions (such as XCHG, MUL, DV,  etc.) to get a feel for how to develop code for our implementation. I have also identified certain subroutines used by the actual Apollo missions that we will be able to run on our architecture with minimal to no changes. This will be a nice demonstration of the correctness of our implementation. Finally, I have more or less finalized the first revision of the board. Next week, I will triple check my schematics and layout and get ready to send the gerber files out to be fabricated. Also, I will continue experimenting with the AGC Assembly language to build some proof-of-concept programs.

Given that we have settled on using an Altera DE10-Standard dev board to implement the core components of our system, I located its PDF Manual from the Altera website and made a few high-level notes.  This particular dev board has a Cyclone V System-On-Chip (SOC) that includes both an FPGA and an ARM core to run embedded C programs.  I confirmed with Jae that the included GPIO will be sufficient to interface with the DSKY.  I’ve discovered that we’ll need to check our current versions of Quartus and possibly add additional software packages that allow us to write programs and then run them on the included core.  Assuming that we go forward with writing a program that feeds simulated sensor data to our CPU on the FPGA, we’ll need to get familiar with the Advanced eXtensible Interface (AXI) bridge included on the Cyclone V as an interface between the FPGA and core, and I plan to personally do just that in the coming week.

Our current plan specifies the use of Altera’s ‘altsyncram’ megafunction IP to implement our dual-ported RAM and single-ported ROM.  I’ve been reading through the Altera Manual in the efforts of learning how we will use Quartus to generate the modules we need.  The included parameter table has allowed me to make note of exactly how we will configure each parameter to produce the desired functionality of our memory modules.  I plan to finish making note of these in the next few days.

Christopher generated the core structure of our Architecture in schematic form, but I’ve been looking back at our detailed ISA notes to make subtle changes that will permit us to process all of our desired instructions.  These changes have involved re-routing various nets to ensure correctness with pipeline stages as well as adding additional control signals.  Through discussion, we’ve realized that a subset of double word instructions can be added to our scope with little implementation difficulty, so I will be working on ensuring correctness of our architecture for these additional instructions.

This week my tasks included ironing out the specifications for the DSKY interface, setting up the software toolchain for the AGC assembler, and beginning the PCB design process.

I have started setting up a rough software toolchain for us to be able write AGC assembler code and simulate them before running the code on our custom AGC architecture. I wrote an extremely simple program that moved around values in the registers and successfully verified its functionality through a debugger.

Finally, I began the schematics capture process for the PCB. I am on track towards completing a first revision by the end of the coming week. I am constantly keeping track of the availability of components in Digikey to guarantee that I will not be designing around unavailable parts.