Author: dgionis

At the very beginning of the week, I spent most of my time preparing to deliver the final presentation.  Once that was complete, my focus shifted to video production tasks.  Christopher and I wrote multiple revisions of a script for our video’s intro and ISA description.  I’ve continually provided Jae necessary information to develop video animations that accurately convey the points we are making about the architecture.  Lastly, I recorded my speaking part for the video intro and transition into the architecture discussion.  I will continue work on video production and begin preparing the final report as we enter the final week.

Last week, I performed additional verification of my UART receive_connector module as we were experiencing difficulty with comms.  This revealed that my design was functioning as expected, but a few minor bugs with chip_interface were identified and corrected.  Following that, I worked on getting up to speed on Jae’s work at the integration level, paying specific attention to the demo assembly program that our CPU runs.  In anticipation of my upcoming presentation this week, I am generating slides and rehearsing to ensure effective timing.

Earlier this week, I was working on producing a new division module that complied with the double precision format of the AGC architecture, as my previous design did not.  Unfortunately, a few implementation details prolonged that work, and as a team, we decided that DV and DDOUBLE instructions would move lower on our list of priorities.  Putting that aside, we shifted focus to our CPU’s UART interface, by which the I/O registers communicate with the outside world.  I implemented and tested a module that receives an update stream for the CPU’s input registers, byte-by-byte, from a unit (courtesy of Ben Marshall on GitHub) that already handles receiving the data bit-by-bit.  My unit then updates the CPU’s input registers as the data is received.  We have begun the first leg of high-level integration and validation.  Next week, I plan to assist in this process as well as prepare for the final presentation.

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.

I neglected to post the last couple of weeks, but most of my tasks have been long-term anyways.  I wrote the initial implementations of our CPU’s register file, arithmetic logic unit, memory address translation unit, and I/O unit a few weeks back.  Since then, a number of bugs with those units as well as the lower level computational units have been detected and addressed.  With our interim demo quickly approaching, I’ve started to run basic tests using simple assembly programs written by Christopher, each testing a specific subset of our instruction set.  Along with simple visual scans of Verilog implementations, a number of larger functional bugs have been identified and resolved.  As of now, basic arithmetic appears to be working fine, as well as memory loads and stores.  I plan to move on to writing test assembly programs for I/O instructions in anticipation of the interim demo.  Following that, I will begin implementing the I/O<->serial interface units.

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.

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.

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.