Introduction

The NYU Processor Design Team is a Vertically Integrated Project team with the goal of taking novel microprocessor designs from ideation, through RTL design, verification, synthesis, layout, and finally tapeout and validation in real silicon.

Syllabus

Contact Information

Uma’s Office Hours

My office hours are shared with other classes, who will take priority over VIP students. That said, my office hours aren’t busy 90% of the time so don’t hesitate to drop in if you have a question. Email or ping me in the discord to drop into my personal meeting room.

Course Prerequisites

Students must be pursuing their undergraduate or graduate degree at NYU in order to enroll in a VIP course. Enrollment is based on a rolling application process through the course website. Decisions on acceptance to the course will be made by the faculty advisors. New student decisions are made by the beginning of each semester. Students may apply to various VIP course options (i.e., VIP teams), then select one VIP team to participate on for three consecutive semesters.

For the Processor Design team: Applicants should have completed CS-UY 2214 or ECE-UY 2204 or have equivalent experience with RTL design. Team participation assumes familiarity with Verilog and associated tooling.

About VIP

The Vertically Integrated Projects (VIP) Program operates in a research and development context. Students join VIP teams by enrolling for credit each semester for their participation in design/discovery efforts that assist faculty and graduate students with research and development issues in their areas of expertise. The teams are:

• Multidisciplinary – drawing students from all disciplines on campus
• Vertically-integrated – maintaining a mix of sophomores through PhD students each semester
• Long-term – each undergraduate student may participate in a project for up to three years and each graduate student may participate for the duration of their graduate career

The continuity, disciplinary depth, and professional breadth of these teams intend to:

• Provide the time and context necessary for students to learn and practice many different professional skills, make substantial technical contributions to the project, and experience many different roles on a large, multidisciplinary design/discovery team
• Support long-term interaction between the graduate and undergraduate students on the team. The graduate students mentor the undergraduates as they work on the design/discovery projects embedded in the graduate students’ research
• Enable the completion of large-scale design/discovery projects that are of significant benefit to faculty members’ research programs

Project Objectives

This course operates as an engineering-focused team, research and learning objectives are achieved through building. Team members will be working collaboratively with industry-standard methodology and modern tooling to construct novel microprocessor designs. This VIP course coordinates with the NYU Tandon School of Engineering and the Purdue University SoCET team.

The team has a special focus on modularity of design, toolchain implementation, continuous integration, testing and verification, test coverage reporting, and module packaging. Team members should expect to develop a familiarity with all of these areas prior to developing a specialization.

Learning Objectives

The team seeks to attain the following outcomes for participants:

• an ability to identify, compartmentalize, and structure solutions to complex problems in digital design using sets of modular components

• an ability to design and implement repeatable and robust toolchains and workflows using industry-standard tooling

• an ability to collaborate effectively with team members and integrate diverse, distributed work into a single cohesive solution

• an ability to independently research and consider possible solutions to a problem space and present concise recommendations for evaluation

Project Structure

This VIP team does not have designated sub-teams. A single team-wide meeting will be held weekly at a time determined by participant schedules.

Course Topics

A short list of topics team members will become familiar with:

• System Verilog
• C/C++ for Verification
• Toolchain Automation
• Processor pipelining and pipeline stage implementation
• Caching
• Design flow tooling
• Elements of a PDK
• RISC-V ISA

Course Structure

Time

Students attend weekly meetings and work outside of those meetings individually and/or with team members. The time commitment expected from each undergraduate student is commensurate with the level of variable credit enrollment:

1 credit: 4 hours per week

2 credits¹: 8 hours per week

3 credits²: 12 hours per week

Graduate students enroll for 1.5 credits, commensurate with 50 hours over the semester.

Zero-credit enrollment: Students may enroll in VIP for zero (0) credits on a case-by-case basis to address issues of enrollment limitations (e.g., credit limits). This enrollment option can only be used up to 2 times.

Weekly Meetings

Each VIP team determines regular team and/or sub-team meeting times during which students discuss project updates, work on tasks, and plan upcoming objectives. Weekly meetings generally take place for 1 hour.

Students are responsible for participating in their team and sub-team meetings. Contact the VIP Student Leadership and/or VIP Advisor prior to missing a meeting to be excused from attendance. If you miss any meeting, you are responsible for knowing what occurred in that meeting (typically by discussing it with a team member). An excused absence does not relieve you of that responsibility.

Communication

Students are expected to communicate with team members during weekly meetings and through mid-week exchanges. Students are expected to respond to communications in an appropriate time frame and to communicate respectfully. Reach out to VIP team leadership with any issues concerning miscommunication.

The NYU Processor Design team coordinates via Github issues, pull request comments, and our Discord.

VIP Notebook

Every VIP student maintains documentation consisting of meeting notes, details about their work and progress, lists of responsibilities, tasks, and deadlines, reflections, etc.

The notebook format for the Processor Design team is markdown documents submitted as pull requests to this repository. Feedback will be provided in the pull request, and timeliness is judged based on when a PR is submitted.

Team members are expected to update their notebooks weekly. An accepted PR represents full credit for the purposes of grading.

It is not the intent that notebooks represent solely individual work. This is not a test, members’ individual knowledge is not under consideration. Group efforts on labs, developing documentation, or achieving individual or team-wide objectives are all acceptable work for the purposes of the VIP design notebook.

Required Materials

There are no required materials for this course. Introductory project information, training, and resources will be made available to students.

Grades

Students are graded based on participation, contribution, and documentation. Attendance is expected at weekly meetings, and every student reports their individual contributions on a weekly basis through the VIP Notebook.

Zero-credit enrollment: Students enrolled in a zero-credit VIP course will receive a Pass (P) for 80% or higher.

Current Membership

Project Leadership:

Project leadership facilitate and administrate the academic aspect of the team, determine high-level objectives, and develop materials for a broad set of team requirements.

Faculty Advisor: Ratan Dey

Team Lead: Uma Nachiappan

Finance Manager: Rielle Lim

Czars:

Czars own their respective parts of the technology stack. They have complete discretion to make technical decisions, review change requests, set iteration goals, and develop materials directly related to their objectives.

CPU: Cameron Bedard, Xingzhi Dai

RISC-V core design

Memory:

Memory controller and bus design, and memory compiler integration

AMBA/Peripheral:

Everything AMBA-related, and essential peripherals

Simulator:

Verification simulator development and integration

Software:

RISC-V software and toolchain development

Onboarding/Documentation: Uma Nachiappan

Labs, project documentation, and outreach

Active Members:

Active members are currently enrolled with the team, or were enrolled in the most recent full semester. Each develops their own goals and works in conjunction with project leadership and czars to make sure those goals advance the project and develop valuable technical skills.

VIP

• Joshua Cho
• Ben Feng
• Ruichen Gao
• Darren Kuo
• Kyle Liu
• Noah Mays-Smith
• Xhovani Mali
• James Jin
• Anurag Tadapaneni
• James Xie
• Dmitri Lyalikov

Design Notebook Guide

1. Getting Started With Git

2. Working With Your Repo

3. Your First Pull Request

4. Your First Design Notebook

Getting Started With Git

Purpose

git is a tool for tracking changes to a set of files, collectively called a “repository” or “repo” for short. The importance of git is in its distributed nature. git makes it possible for members of a team to clone a repository, work on the set of files individually, and then re-integrate those individual changes into a cohesive whole.

For collaborative projects like the Processor Design Team, these functions are fundamental to the work we do. Thus, your ability to use git is vital to participating with the team. With that in mind, you will need to use git to submit your first (and all future) design notebook entry.

git and GitHub

We need to take a moment to discuss the difference between the tool, git and the website GitHub. git is a program that runs on your computer and allows you to track, manage, diverge, and integrate changes to a repository of files. GitHub is website and web service that understands the protocols and storage conventions used by the git program.

The advantage of GitHub is it allows users to easily setup and manage remote repositories. A remote repo is a simply a repository that does not exist on your computer, instead the set of tracked files exist on a server, just another computer somewhere on the internet.

Because this repo exists on a continuously hosted internet server, many people can get access to the repo and clone the files. Using Github we can also easily manage who has permission to make changes to the remote repo. If we were hosting our own server we would have to manually create accounts and setup permissions for each person who wanted to access and modify our remote repo.

This is not an idea exclusive to Github. Many different web services are built around git and allow users to easily create and manage remote repos. Github is one of the most popular of these services, and it is the one used by the Processor Design Team which is why it is discussed here.

Github also provides many other services that are unrelated to git the program. Issue tracking, team management, file browsing, and most notably a formal pull request mechanism are all features of Github the service, not git the program.

Creating a Github Account

For the purposes of your design notebook, the first step is going to be creating an account on Github. If you already have a Github account, there is no need to create a new one exclusively for the team.

Configuring git

In any environment where need to use git you first need configure the program on your current account. You need to tell git your name:

git config --global user.name "Your Name"

And next you need to tell git an email address, this should typically be whatever email is associated with your GitHub account

git config --global user.email "your_email@example.com"

Setting up SSH Access

ssh stands for “secure shell” and is a encrypted communication protocol for logging into and communicating with servers. git does not inherently have a mechanism to communicate with remote repositories, instead it piggy-backs on existing protocols such as https and ssh. For security purposes, Github restricts many operations to the ssh protocol.

ssh is built upon the principles of public-key cryptography. What this means for users is you must generate and store a public/private key pair for use with the protocol. There is no single way to do this step depending on your development environment. What follows is a description of how to generate this key pair and use it with the Anubis ProcDesign IDE environment, but Github provides excellent instructions for how to work through this process on a variety of platforms.

The first thing to do is generate a public/private key pair, you can do this with the following command:

ssh-keygen -t ed25519 -C "your.email@nyu.edu"

The generator will ask the following questions:

Enter file in which to save the key (/home/anubis/.ssh/id_ed25519):

Hit enter, as we want to use the default location for this file

The next question will be:

Enter passphrase (empty for no passphrase):

If you enter a passphrase, you will be required to enter it prior to performing most ssh operations. It’s fine to leave this blank.

Now we need to let various operating system components know about your new keys, so that git will be able to find them later. The way to do this is by using a command called ssh-add. Unfortunately, ssh-add doesn’t have enough information to do its job by default. So we need to run a command to retrieve this information and add it to the local environment. If those words don’t mean anything to you, don’t worry, just run this command:

eval "$(ssh-agent -s)"

Finally we can add our new ssh keys with the command:

ssh-add ~/.ssh/id_ed25519

The last step is adding your SSH keys to Github, for which you should follow the public Github documentation.

Working With Your Repo

Purpose

While some developers prefer to use git purely from the command line, others enjoy using the interface built in to their IDE. This is purely a preference-based decision. In this section, we’ll demonstrate how do work through some common git operations using both the command line, and how do to the equivalent operation using the Source Control tab on VSCode and Anubis. Note that most of these features are provided by the GitLens plugin for VSCode and Anubis.

There is far, far more to git than could be productively covered here. It is highly recommended that you seek guidance from the Git Book for a complete discussion of both basic and advanced operations.

Initializing a Repository

Inside a new empty folder, you can create a new git repo using the command:

git init

This is equivalent to using the “Initialize Repository” button in the Source Control tab:

Staging Files

When a new file is added to the project, or changes are made to a file, you can inform git about those changes with the command:

git add [file_or_folder_names]

This command adds the files to “staging”, which is what we call the set of file changes that we’re going permanently track in the repository.

A common pattern is to use:

git add .

Where the . is a Unix filesystem convention for refering to the current folder. This command tells git to add all files that have been added or changed to “staging”.

The equivalent in the Source Control tab is to use the plus and minus signs to move files in and out of “staging”:

Making a Commit

To make the collection of changes in staging permanent, we make a commit. Every commit is accompanied by a message. You are encouraged, by not required, to follow the conventional commits guidelines for what to write in this message. The czar of a given repo may require this or some other commit message format if you eventually want them to incorporate your changes “upstream”.

The commands to make a commit message depend on how long your message is, commits with short messages can be made with the following:

git commit -m "docs(example): This is a commit message"

If a longer message is needed, the same command without the -m can be used:

git commit

git will open an editor to be filled with the commit message, when the file is saved and the editor is exited, git will open that file and read the commit message.

The equivalent in the Source Control tab is the commit box:

Pushing Changes

Once changes have been made to a local repo, they can be pushed to tracked remotes using the following command:

git push

This is somewhat equivalent to the Source Control operation of “syncing”

Your First Pull Request

Purpose

The pull request is a mechanism for integrating changes between two copies of the same repository. It is not an inherent process builtin to git, but rather a formal or informal process built on top of git. In this section we’ll briefly exam the usage of the GitHub pull request system.

Fork the Repo

A pull request is a request to incorporate changes made on one copy of a repo, into another copy of the same repo. So to start we will need to make a copy to perform changes on. In the case of the design notebooks, the repo to fork is the one that contains the site you’re reading right now.

To understand why you should work on forks, read the next guide - Working Collaboratively.

To create a fork, you need only click the fork button at the top right of the page:

We can now clone the fork as usual.

Branching

Before we start making changes, we probably want to branch the repo. This way we don’t mess with the commit history of the “main” branch, so it will be easy to incorporate changes that happen in the main repo we forked from.

To create a branch we can use the following command:

git branch -c branch_name

Then to switch to the branch we can use:

git switch branch_name

These two operations are so common, that there is a shortcut to do them in a single command:

git switch -c branch_name

The same behavior can be found in Source Control by right clicking on a branch you would like to branch from:

Publishing Changes

After you have added your commits to the branch, you can publish the results to Github with the following commands:

git push [remote_name] [branch_name]

This is equivalent to the Source Control “Publish Branch” button:

Making a Pull Request

To make a pull request, navigate to the “Pull requests” tab of your repo:

And click “New pull request”:

Use the drop-down menu on the right to select the correct branch you would like to pull from:

Now create the pull request.

For the following dialogue, it’s fine the leave the title as whatever is generated for the commit. In the comments field, include any information that might be pertinent but isn’t included in the commit itself.

Discarding the Branch

Once your PR has been merged into the “upstream” repository, it is safe to delete the branch you did the work on.

You can do this with:

git switch main
git branch -D branch_name
git push origin -d branch_name

The first command switches off of the development branch, because you cannot delete a branch that is currently checked-out. The second command deletes the local copy of the branch, and the third command deletes the remote copy.

The deletions are equivalent to right clicking and selecting “Delete branch” in Source Control.

Integrating Upstream Changes

You can now pull the upstream changes into your repo, this can be done with

git pull [remote] [branch]

Your First Design Notebook

Purpose

The design notebook is the mechanism used by the team and the VIP program to demonstrate student involvement with the program. As a practical matter, the design notebook serves as an index for an individual’s contributions to the team. Instead of searching through repositories, code, issues, and discussions to find and evaluate what you have done, the design notebook serves as a single point of reference to those materials.

For the Processor Design Team, your design notebook is expected to be principally outbound links to pull requests, repository snapshots, and possibly individual commits, combined with a short (one sentence) contextual explanation of what the linked work is. This is an engineering team and the expectation is that your work is mostly functional, not hypotheticals or explorations of theory. Typical VIP notebook items, such as resources or “task completion” should be implicit in the linked materials.

Format

This website represents the expected format of design notebooks for the Processor Design Team. Every page on this site is built using Markdown files, a plaintext markup language format for quickly producing reasonably formatted HTML documents.

Each VIP student is expected to create a file named netid.md under the design_notebooks/semester folder of this repository. Where netid is the student’s NYU NetID (for example, nvg7278.md), and semester is the semester they are enrolled for (for example, design_notebooks/2023spring).

Each week, students are expected to make a pull request against this repository to update their design notebook file for the semester.

If you are unfamiliar with markdown or wish to revisit its nuances, refer to this markdown cheatsheet.

Content

A typical entry in your design notebook should be a list of items that represent work that was done that week. This list might be longer or shorter depending on the magnitude of each item in the list. If you’ve completed an onboarding lab, a single link to the completed lab repository might be the only item for that week. If you did a little work across project repositories, you might have three or four items linking to PRs, commits, and issue discussions.

Additionally, an entry should have a one or two paragraph personal narrative that contextualizes the work done that week and adds details that can’t be known just from inspection of the linked work. This could be struggles, false starts, or perhaps just the impetus for the work.

Example

## Week of 10 October 2022

Project Work:
  * [Onboarding Lab 5](link/to/repo): Completed Lab 5, worked with Jerry and
    Rishyak

  * [Doc Workflow Update](link/to/pull_request): Updated the documentation
    workflow, docs are now generated in ~5 seconds instead of 3-4 minutes

This week was mostly spent on lab 5 from the onboarding series. I worked in
close collaboration with Jerry and Rishyak to complete a suite of system
verilog modules that interoperated to solve the lab objectives.

We struggled with the lab's description "interfaces" and what their
applications were. After a discussion with Prof. Epstein, we gained a better
idea of how to apply interfaces to collect related signals together when
connecting components in a top level module. However, our solution to the
lab doesn't make extensive use of interfaces right now.

Working Collaboratively

Purpose

Collaboration is an essential part of working in any team. Much of our work is shared and built upon each others’ contributions - whether it is the components themselves, editing documentation, or making improvements to this website.

Additionally, as team members join the team with different areas of expertise, it is important to support one another in the learning and development process.

Terminology

• upstream: The main repository owned by the organisation
• origin: Your fork of the repository

Team Repositories

• Team members should have access to the NYU Processor Design GitHub organization.

• Throughout the project, you will need to work on the shared repos - for example, adding a design notebook entry to our website, or editing a component of the AMBA or core.

• To work efficiently, you want to fork the appropriate repo and make a branch on your fork.

• After making changes, create a pull request to merge your changes to the team’s repository by following this guide.

• Once your changes have been merged, delete your branch and update your fork.

Working on Forks

• When working on your fork of a active and constantly updating repository, you want to avoid working directly on the main branch of your fork.

• This keeps main clean to fast-forward¹ any changes from upstream.

• If you work on main, merging changes from upstream will cause “merge” commits, making upstream and origin have different histories

• It also creates extra work for the maintainers because they have to clean your fork before merging your changes.

• Working on main will also create messy pull requests with merge commits and other commits that aren’t associated with your work.

• This ‘pollution’ makes it harder for git to incorporate changes from upstream and may cause merge conflicts, which will have to be fixed

• Before you start working, make sure to update your fork’s main branch to match the team’s upstream repo.

  • You can use the “Sync fork” button on GitHub

  • Or, locally with the following commands:

    git pull upstream main
    git push origin main
    

• Then, follow the Your First Pull Request guide.

Fixing Fork Issues

After reading the previous section, you are now realizing your PRs and forked repo are a little messy. Don’t worry, you can clean up your main branch by following the guide below and create a new, beautiful, PR.

Guide

1. Create a branch from your current main branch so you don’t lose any changes.

   git branch oldmain
   

2. Clean up your main branch by performing a hard reset from upstream’s main. This will equalise upstream and origin - their histories will be the same. Anything not on upstream will be lost.

   git fetch upstream
   git reset --hard upstream/main
   

3. Force-push your changes to origin

   git push -f
   

4. Create a new branch for your changes/work (called temp below):

   git switch -c temp
   

5. Then, cherry-pick your changes into your temporary branch:

   git cherry-pick <commit>...
   

   • Where <commit>... will be the SHA’s of the commits you want to bring over
   • For example, if you wanted to cherry-pick 1337abc, eb722ec, c00eba4, your command will be:

     git cherry-pick 1337abc eb722ec c00eba4
     

   • Don’t worry - you’re not expected to know cherry-picking or regularly use it.
   • For now, trust that this command will take your changes and store them on your temporary branch.
   • If you’re interested, you can find out more about how/why this works in the Pro Git Book.

6. Optionally, if you have more than one commit, you can squash them into one commit if you know how, but if not, the maintainers can squash and merge your commits into the upstream repo.

   • The easiest way to squash commits is to perform an interactive rebase

After cleaning up your fork, you can now create a clean pull request from your branch.

Issues and Questions

• Nobody’s perfect, which means there may be errors and questions on component modules, git documentation, etc.

• If you see a problem or have a question, ask the team and/or open a new issue on GitHub using these guidelines.

• You should also use this contribution guide when submitting a design notebook entry.

Additional Support

• You are all talented and intelligent – that’s why you’re here – but team members will join the VIP with different levels of experience and knowledge.

• The best part of working collaboratively is learning from one another and
  supporting each other.

• If you see someone struggling or learning something new, offer your assistance in a helpful and respectful way.

Developement Environment Guide

1. Homebrew Installation (macOS)
2. VirtualBox Virtual Machine Guide
3. WSL with VSCode Installation (Windows)
4. VS Code Extension Recommendations

Homebrew Installation Guide for macOS

Homebrew is a free and open-source software package management system for macOS.

This guide will show you how to install the Homebrew Package Manager on macOS and use it to install the required dependencies for the NYU Processor Design Team.

Contents

• System Requirements
• Installing Homebrew
• Installing Packages
  • CMake
  • Verilator
• Maintaining Packages
• Further Reading

System Requirements

• CPU: 64-bit Intel or Apple Silicon
• OS: macOS Big Sur (11) or higher
• Command Line Tools for Xcode
  • You can install these by running the following from your terminal:

    xcode-select --install
    

• Bourne-again shell for installation (You most likely have this)

Installing Homebrew

• Disclaimer: It is best to not copy-paste commands after the first installation command from this guide. The commands use paths specific to the computer this was written on. That computer also uses Apple Silicon and Homebrew has different installation processes for Intel and Apple Silicon computers. Use this guide as a reference.

• Open Terminal and run the following command:

  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
  

• Next, it will ask you for your password and you should provide the password you use to unlock your computer

  ==>Checking for `sudo` access (which may request your password)...
  
  Password:
  

• The tool will then display a list of everything it will install and the directories it will create, before asking you to press RETURN/ ENTER to continue, or any other key to abort

• Press RETURN/ENTER to continue the installation

    Press RETURN/ENTER to continue or any other key to abort:
  

• The tool with then start to install Homebrew and any needed Xcode dependencies

  • Let the command run fully and do not close the terminal
  • It may appear at times to be stuck or frozen but it is simply downloading the files it needs
  • Many of these files such as the Xcode command line tools are rather large so expect the installation to take several minutes.

• You will know the installation is done when the following shows up on the Terminal:

  ==> Installation successful!
  
  ==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
  
  Read the analytics documentation (and how to opt-out) here:
  
  https://docs.brew.sh/Analytics
  
  No analytics data has been sent yet (nor will any be during this install run).
  
  ==> Homebrew is run entirely by unpaid volunteers. Please consider donating:
  
  https://github.com/Homebrew/brew#donations
  
  ==> Next steps:
  
  -Run these three commands in your terminal to add Homebrew to your PATH:
  
  echo '# Set PATH, MANPATH, etc., for Homebrew.' .. /Users/test/.zprofile
  
  echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/test/.zprofile
  
  eval "$(/opt/homebrew/bin/brew/ shellenv)"
  
  - Run brew help to get started
  
  - Further documentation:
  https://docs.brew.sh
  
  

• You will then need to run the following three commands one at a time to fully set up Homebrew

  • These commands will allow you to access the homebrew commands from your terminal
  • Remember to change the username from the path from test to whatever your username is if you are copying commands from this guide

• Adds a comment in your zsh profile file

  echo '# Set PATH, MANPATH, etc., for Homebrew.' .. /Users/test/.zprofile
  

• Adds homebrew to your PATH

  echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/test/.zprofile
  

  eval "$(/opt/homebrew/bin/brew/ shellenv)"
  

• Run the following command to confirm your installation

  brew help
  

Installing Packages

• The installation command for Homebrew is:

  brew install <package name>
  

  • This will search for the specified package¹ in the brew registry and install it in your system.
  • You can list multiple package names in one command, for example:

    brew install cmake verilator clang-format
    

• Homebrew installs packages in /usr/local/Cellar/ by default

• It will then make symlinks to the package at /usr/local/opt/ and /usr/local/bin/ so the packages can be used as executables

• If you want to get information about a specific installed package, you can use the brew info command like this:

  brew info <package name>
  

• macOS comes with most dependencies pre-installed, so you only need CMake and Verilator

  • To install said dependencies, run the following commands in the Terminal

CMake

brew install cmake

Verilator

brew install verilator

Maintaining Packages

• To update Homebrew and package definitions, regularly run the following

  brew update
  

• Upgrade everything

  brew upgrade
  

• Upgrade a specific package

  brew upgrade <package name>
  

• Uninstall a package

  brew uninstall <package name>
  

Further Reading

• If you want to explore more about Homebrew or run into any trouble visit the official site or the FAQs for many more guides and explanations.

VirtualBox Guide

Last updated February 7, 2024

VirtualBox (VBox) is a popular hypervisor¹ for x86 virtualisation. It allows you to create virtual machines, which are effectively emulations of computers on your computer. This allows you to use operating systems you do not have on disk, run programs that may be risky to run on your computer, or work with historical machines that are hard to find now.

We will use VirtualBox to create a virtual machine (VM) to contribute to the NYU Processor Design Team without having to install Linux natively or buy a new computer. VBox is a plug-and-play solution for all intents and purposes of the NYU Processor Design Team.

This guide will help you use the provided VM configuration with VBox.

Contents

• Minimum Requirements
• Virtual Machine Information
  • Specifications
• Downloading VirtualBox
• Downloading the VM
• Importing the VM
• Starting the VM
• Logging In
• Homescreen
• Exploring your VM and Tips
• Configuring your VM

Minimum Requirements

• CPU: Any reasonably powerful 64-bit x86 processor
  (fancy for “most modern computers”)

• Memory: 8 GB RAM

• Disk Space: 16 GB available space
  (Virtual hard disks are dynamic and grow with usage. You do not need 16 GB available immediately, that’s just what the VM is set up for)

• OS: Any major 64-bit operating system such as Windows, macOS, and most Linux distributions

Note: If you already use Linux or macOS, you can start working immediately and do not need a VM, but nobody will stop you if you wish to use one regardless. Check the Lab Guidance page for what you need to have. Optionally, macOS users are encouraged to look at the Homebrew Installation Guide.

Virtual Machine Information

• The provided VM is set up for VirtualBox >7.0.0, which means it is guaranteed to work with any version of VBox after 7.0.0

• Currently, VirtualBox is on 7.0.14, as of writing this guide

• The VM is set up with Ubuntu Desktop 23.10 Mantic Minotaur

• The VM contains all tools you need to begin working right away

Specifications

• OS: Ubuntu Desktop 23.10

• Processors: 4 processors

• Memory: 6 GB RAM

• Disk Space: 16 GB

• Appliance Size²: 8 GB

Note: You can edit these later to your desire if your computer has more resources to allocate to the VM.

Downloading VirtualBox

1. Go to virtualbox.org

2. Download the latest version of VirtualBox

Downloading the VM

1. Go here

2. Download the .ova file

   • OVA stands for Open Virtualisation Appliance
   • It is a common file extension that hypervisors use
   • The NYU Processor Design Team VM contains the entire OS, some applications, utilities, etc. and therefore, is ~7 GB.

Importing the VM

1. Open VBox

2. Click on “File” and then “Import Appliance”

3. Find the procezzor.ova file in your file system

4. Click Next

5. Keep all the default options, click Next

Starting the VM

• Double-click on the VM or press Start

Logging In

• You will now be presented with a log-in screen like this:

• Click on the “designer” user and you will see this:

• Enter the password “processor” and hit Enter/Return

• You will now be presented with the Ubuntu homescreen (the wallpaper might be different)

Homescreen

• You will see the home folder on the Desktop, in the top-right corner

• On the dock, you will see:

  • Files (the file explorer)
  • Firefox (browser)
  • VS Code (text editor) with some useful extensions:
    • C/C++
    • CMake and CMake Tools
    • GitLens
    • System Verilog Language Server
  • Terminal
  • Recycle Bin

Exploring your VM and Tips

• Now you have a Linux VM to play around with

• You can do whatever you want with it

  • Since this is not a real computer, you do not have to worry about breaking it so play around
  • Worst case: Just re-install the VM
  • Word of advice: It’s best to stay away from playing with root, bad things can happen

• Although, it is recommended that you change the password

  • You can do so through settings or by opening the terminal and typing:

  passwd
  

• You can also go through the settings and customise it to your preferences - remember, it is now your virtual computer

• You should regularly run the following two commands:

  • Update and upgrade packages

    sudo apt update && sudo apt upgrade -y
    

    • update fetches the latest information of the installed packages
    • upgrade will upgrade them if newer versions have been released
    • the -y flag simply tells APT that it has permission to upgrade everything and doesn’t have to ask you to say “yes” to each upgrade

  • Update Snap packages

    sudo snap refresh
    

  • Snap is Canonical’s³ deployment system

    • Ubuntu’s equivalent of the App Store/Play Store/Windows Store

• You can close your VM by clicking on the close button, choosing whether to keep the machine frozen in its current state or shut down completely; you can also use the power options in Ubuntu

Configuring your VM

• This VM was created for the average computer one may have

• If you have a more powerful computer, you would benefit from increasing the resources your computer can dedicate to the VM

• To do so, press Control/Command+S or right-click and then choose “Settings” or click on the bright-orange cog symbol in the ribbon

• You will see the settings screen

• Here, you can click through the various sections and configure your VM

  • Word of Advice: It is best to not mess with most of these

• You should look at the “System” and “Display” tabs and adjust the settings for your computer

  • It is recommended to give a quarter to a half of all your resources to a VM

• Play around with these settings and your VM will feel like a native install in no time

Windows Subsystem for Linux (WSL) Installation Guide

The Windows Subsystem for Linux (WSL) is a type 1 hypervisor¹ developed by Microsoft to allow developers to run Linux environments directly on Windows, without the drawbacks of type 2 hypervisors¹ such as virtual machines, or, the hassles of dual-boot setups.

This guide will show you how to install the Windows Subsystem for Linux (WSL) on Windows and use it to install the required dependencies for the NYU Processor Design Team.

Contents

• Installing WSL
• Using VSCode with WSL
• Installing Packages (Ubuntu)
  • CMake
  • Verilator
  • cURL
  • Git
• Maintaining Packages
• Optional: Using Zsh
  • Prettifying Zsh
  • Changing VSCode’s Default Terminal
• Further Reading

Installing WSL

• Open a Terminal and run the following command:

  wsl --install
  

• The following command will install the default Linux distribution (Ubuntu), but you can install any of the distributions listed by wsl -l -o

  wsl --install -d <distribution_name>
  

• After a restart, running the command wsl in the terminal or running the wsl command in your start menu will open a virtual linux environment in your pc

• Once WSL has been set up you will have to create a username and password for your linux machine

• Follow the instructions provided and remember the password you enter as it will be required to run sudo commands

  • sudo stands for “Super User Do”

Using VSCode with WSL

• Install VSCode in your native Windows environment first.

• In VSCode, install the WSL extension using the Extensions tab on the left tool panel

• Now, VSCode can be run in the WSL environment by doing one of the following:

  1. Clicking on the “Remote Window” button at the bottom left of your VSCode window and clicking “New WSL Window”
  2. Pressing F1 or Control+Shift+P to open the command palette and selecting WSL: New WSL Window

Upgrading the Ubuntu Version

By default, WSL only has LTS (Long-term support) versions available. This doesn’t work for us because we want to use more up to date packages that are only available in more recent versions.

• If the second sed command fails, you might want to open sources.list and see a line like this deb http://archive.ubuntu.com/ubuntu/ jammy main restricted. If instead of jammy, it says focal or

Before you begin, open sources.list, and find a line like deb http://archive.ubuntu.com/ubuntu/ jammy main restricted. If instead of jammy, you see focal or bionic, switch jammy to focal or bionic in the commands below.

cat /etc/apt/sources.list

• The first step is to switch from the LTS branch to the normal Ubuntu branch

  sudo sed 's/lts/normal/g' /etc/update-manager/release-upgrades
  

• Next, the package sources need to be pointed to lunar instead of jammy.

  sudo sed -i 's/jammy/lunar/g' /etc/apt/sources.list
  

• Once the sources are updated, the existing packages must be upgraded to the new version. This can take several minutes to complete.

  sudo apt update
  sudo apt upgrade
  sudo apt dist-upgrade
  

Troubleshooting

Installing Packages (Ubuntu)

• The installation command for Ubuntu is

  sudo apt install <package name>
  

  • This will search for the specified package in the APT registry and install it in your system.
  • You can list multiple package names in one command, for example:

    sudo apt install verilator clang-format
    

CMake

Unfortunately, APT doesn’t have the latest version of CMake, so we must use this alternative².

• Uninstall existing CMake Versions

  sudo apt remove --purge --auto-remove cmake
  

• Preparing for Installation

  sudo apt update && \
  sudo apt install -y software-properties-common lsb-release && \
  sudo apt clean all
  

• Obtain a copy of kitware’s signing key

  wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /etc/apt/trusted.gpg.d/kitware.gpg >/dev/null
  

• Add kitware’s reposity to sources list

  sudo apt-add-repository "deb https://apt.kitware.com/ubuntu/ $(lsb_release -cs) main"
  

• Optionally, installing kitware-archive keyring package to keep Kitware’s keyring up to date

  sudo apt update
  sudo apt install kitware-archive-keyring
  sudo rm /etc/apt/trusted.gpg.d/kitware.gpg
  

• If running sudo apt update gets the following error:

  Err:7 https://apt.kitware.com/ubuntu bionic InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6AF7F09730B3F0A4
  Fetched 11.0 kB in 1s (7552 B/s)
  

  Copy the public key 6AF7F09730B3F0A4 and run this command:

  sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 6AF7F09730B3F0A4
  

• Finally, update and install the cmake package

  sudo apt update
  sudo apt install cmake
  

Verilator

sudo apt install verilator

cURL

sudo apt install curl

Git

sudo apt install git

• Then follow the Getting Started With Git tutorial to configure git

Maintaining Packages

• To update APT and package definitions, run the following

  sudo apt update
  

  • update fetches the latest information of the installed packages

• Upgrade everything

  sudo apt upgrade -y
  

  • upgrade will upgrade them if newer versions have been released
  • the -y flag simply tells APT that it has permission to upgrade everything and doesn’t have to ask you to say “yes” to each upgrade

• Uninstall a packages

  sudo apt remove <package name>
  

Optional: Using Zsh

• Ubuntu’s default shell is the Bourne-again shell (Bash)

• Z-shell (Zsh) is a Unix shell built on top of BASH

• Zsh includes more features and is the default shell on other popular Linux distros such as Arch Linux

• To replace Bash as Ubuntu’s default shell, first install zsh:

  sudo apt install zsh
  

• Change login shell to Zsh

  chsh -s $(which zsh)
  

  • chsh changes your login shell
  • The -s flag specifies the login shell
  • The $() syntax tells the shell to interpret everything between the parentheses as a command
  • which identifies the location for various executables and prints the full path of the executables; in this case, we want the path for zsh

• Log out and log back in for the change to take effect

Prettifying Zsh

• The default Zsh appearance is, for the lack of better words, hideous, unpleasant, and unsightly

• To fix this, many open-source frameworks have been created to create themes for Zsh terminals

• Oh My Zsh is the most popular Zsh theme framework

  • Sidetrack: Fun story about the ideation of Oh my Zsh, written by the creator, Robby Russel

• Not only does it make Zsh much more pleasant to look at, it also provides useful and important information such as your current working directory, git branch, git status, etc.

• To install Oh My Zsh, use the following command

  sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
  

• To change the theme of your terminal, you can run the command nano ~/.zshrc and change the line ZHS_THEME="robbyrussell" to any of the available themes listed here

  • The .zshrc file is a special run-command file that contains configurations for your zsh terminal session
  • It exists on your home directory as a hidden file, hence the ~ and . beginning
  • It is executed when you log in

Changing VSCode’s Default Terminal

• To change VSCode’s default terminal, press F1 or Control+ Shift+P to open up the command palette

• Search for Terminal: Select Default Shell and select zsh

• Now every time you open a terminal in WSL, VSCode will open a zsh terminal

Further Reading

• Microsoft’s excellent documentation for WSL

• VSCode’s excellent documentation on developing in WSL

• Ubuntu’s documentation about Ubuntu on WSL

• TroubleChute’s documentation on how to update Ubuntu from one release to another.

Useful Extensions for VSCode

VSCode has many extensions and tools that may be helpful in the development process for the NYU Processor Design team. This guide is a compilation of recommended VSCode extensions. Most installation instructions can be found in the associated links.

Contents

• SystemVerilog Language Server
• C++ Pack
• Doxygen Generator
• Better Comments
• Spell Checker
• Git & GitHub
  • GitLens
  • GitHub Actions
  • GitHub Pull Requests
• Markdown All in One
• Optional Bonuses
  • ColdCode
  • Makefile Tools
  • GitHub Style Markdown Preview
  • Marp
  • Rewrap

SystemVerilog Language Server

SVLangserver is a language server for System Verilog that features auto-completion, module hierarchy, code snippets for common blocks, code formatting, syntax highlighting, and more.

To install, find svlangserver in the VSCode marketplace. You can modify your extension settings to your desired preferences as detailed in the link above. The extension’s commands and troubleshooting can also be found in the link.

C++ Pack

This extension pack has 4 sets of popular extensions:

• C/C++ support
• C/C++ Themes
  • This is simply a visuals/aesthetic extension; not necessary, just part of the extension pack. You can use whatever theme you like.
• CMake support
• CMake Tools

Doxygen Generator

Doxygen is a documentation generator that extracts documentation from C++ source code comments. This Doxygen comment generator creates Doxygen comments for a variety of code snippets: constructors, functions, file descriptions, etc.

Better Comments

Better Comments helps to create more understandable, categorizable comments for your code, and works with C++ and Verilog.

Spell Checker

This Code Spell Checker does exactly that: it is a basic spell check that can be customized and has a variety of add-on language dictionaries.

Git & GitHub

GitLens

GitLens is a customizable extension that includes a wide variety of features such as a Git command palette, and detailed commit, repo, and branch histories. Full details can be found in the link above.

Note: This is a highly recommended extension, and the Pro version is free with GitHub’s Student Developer Pack.

GitHub Actions

GitHub Actions lets users manage workflows and view workflow history for github.com hosted repositories.

GitHub Pull Requests

The GitHub Pull Requests and Issues extensions lets you review and manage GitHub PRs and issues directly in VSCode.

Markdown All in One

Markdown All in One is a collection of Markdown commands and features like keyboard shortcuts, math, table of contents, etc.

Optional Bonuses

ColdCode

ColdCode is used to take screenshots of your code with various configuration options (show line numbers, titles, etc).

Makefile Tools

Makefile Tools provides IntelliSense configurations to the C/C++ Extension for Makefile projects. It also has commands to build, debug, and run targets.

GitHub Style Markdown Preview

This extension lets you preview Markdown files using GitHub’s styling, and is customizable with GitHub’s various themes.

Marp

Marp is used to create slide decks in Marp Markdown directly in VSCode. (For our Google Slides haters and VSCode lovers, we got you.)

Rewrap

Rewrap performs hard wrapping for comment blocks and any kind of plain text files.

Onboarding Labs

1. Lab Guidance

2. Lab 1: CMake and Toolchain

3. Lab 2: System Verilog

4. Lab 3: Verification

5. Lab 4: Advanced Verification

6. Lab 5: Advanced System Verilog

7. Lab 6: Packaging and Dependency Management

8. Lab 7: Becoming a Processor Designer

9. Lab 8: Advanced Processor Design

Lab Guidance

Purpose

What follows is generic guidance applicable to all of the Onboarding Labs

Guidance

• Labs do not require any specific computing environment so long as the required tools are present. You are free (and somewhat encouraged) to work on a personal machine. However, all of the requirements for the labs are provided on Anubis if you don’t have a development machine that can run the required tooling.

• For a personal computing environment, the required tools across all the labs are the following:

  • cmake

  • verilator

  • git

  • curl

  • zip, unzip

  • tar

• Labs are intended to be run and completed in their own directory/repository. If a lab requires you to clone an existing repository and work inside it, that will be noted in the instructions.

• For the purposes of the design notebook, you will need to push the final state of a given lab directory to a repo. You can then link to this repo in your design notebook, see the Design Notebook Guide for more.

• Labs may ask that you Make Note or Answer the following at various points in their instructions. These notes and answers should be collected in a ReadMe.md file in the root of the lab directory. There is no specific layout required for this file, other than it should be obvious what notes and questions correspond to which answers.

Lab 1: CMake and Toolchain

Before You Begin

Take some time to review the Lab Guidance before beginning on these labs. If you’re using the labs to populate your design notebook entries, failure to follow the lab guidance could adversely affect your Documentation grade.

Purpose

In both hardware and software development, we use a variety of tools to achieve our goals, tools such as compilers, linkers, simulators, etc. These tools can be quite complex, have non-trivial inter-dependencies, and the overall process of invoking all the necessary tools to build the final product may have many steps.

For projects of sufficient complexity, it is rarely feasible and never desirable to run all the necessary tools by hand. Instead, we write programs to run the tools for us. These programs are collectively referred to as the toolchain. In this lab, you will learn to work with the major toolchain program used by the Processor Design Team, a tool called cmake.¹

Part 1: CMake Hello World

cmake is a tool for describing toolchains. Typical usage of cmake looks like:

cmake [directory]

Where [directory] is a location on the filesystem that contains a file named CMakeLists.txt. This file is often referred to as an acronym, “CML”, and we will do so in these lab instructions as well.

We will start by creating an empty CMakeLists.txt file in the lab directory. Before we put any commands into the file, we need to know what version of cmake we are running. We can discover this with the command:

cmake --version

Make Note: What version of cmake is running in your environment?

The cmake version number is split into three parts, separated by periods. The first is called the major version, the second the minor version, and the third is called the patch number. These make up a system known as semantic versioning which we will discuss more in a later lab.

Now we are ready to add the first line of code to our CML file, and it should look like this:

cmake_minimum_required(VERSION [major].[minor])

In this line of code, [major] and [minor] should be the major and minor version number you learned from the earlier command. As you might suspect, cmake_minimum_required is a cmake command which will ensure the cmake tool running the file is at least of a minimum version. Unless you’re specifically testing or making certain your CML runs on older cmake versions, it’s best to set this to the version of cmake you’re currently using.

The next line of code isn’t strictly necessary for "Hello World", but you will see it in nearly every CML so we’ll include it here too:

project(week-one-lab VERSION 1.0.0)

Here we have the project name and version number for our code. This isn’t very significant yet, but it will be in the future.

It’s time to make the magic happen, the third line of your CML will be:

message("Hello World")

Now we’re ready to run cmake. First, create a directory named build inside your lab folder. In a console, navigate to the build directory and run the command cmake ... The .. tells cmake to look for our CML file in the parent folder of our current working directory.

cmake will generate an amount of output, but among its many messages should be our "Hello World"!

Part 2: Building a Program

The astute student will notice that our build directory is now filled with random crap. This is, in fact, why we created the build directory. In the future, we’re always going to want to run cmake in its own directory for this reason, so that the generated files don’t pollute our source code folder.

But what are all these files? What purpose do they serve? Before we answer that question, let’s try to build an actual program with cmake. First, write a Hello World program in C++ and save it as hello.cpp at the top level of the lab repository (the same folder which holds the CML).

Next, we’re going to tell cmake we would like to build a program, using the following two lines of code. You can remove your message() command from the CML and replace it with:

add_executable(hello_world)
target_sources(hello_world PRIVATE hello.cpp)

The first line informs cmake about the new program named hello_world that we would like to create, and the second tells cmake about a source code file we would like to associate with this new program, and that’s it! (We’re going to ignore that PRIVATE keyword for now).

Inside the build directory, run the cmake .. command again to re-run the cmake tool on the edited CML.

Unfortunately, our program has not been created. In fact, the files inside the build directory are exactly the same files as before. Before we answer that question, let’s get a working hello world program. The following command, run inside the build directory, will build the final program:

make

The command is make not cmake

Make Note: Run make help and figure out what the valid targets (command arguments) are for this project. For all the targets that start with “hello”, can you figure out what they produce? What about all and clean?

Despite their similar names, make and cmake are completely unrelated programs. make is a build system, it produces a final program executable that you can run. cmake is a meta-build system, it reads the CML and produces other build systems, such as the Makefile that make uses to build our hello_world program.

Just like a compiler can support multiple computer architectures, cmake supports multiple build systems. In the build directory, try running the following commands so that cmake will generate a ninja build system instead of a make build system (the first command removes the old files from the build directory, to prevent errors):

rm -rf *
cmake -G Ninja ..

Now you can run the ninja command in the build directory to produce the final binary. Optionally, you can run cmake --build . and cmake will run the correct build tool for whichever build system was generated.

Why is this so complicated? Historically, build systems were either fast and hard to use or very slow but flexible and easy to use. cmake’s solution to this problem was a flexible tool that generates a fast build system. The ninja build system in particular is never meant to be used directly by humans, but only as a target for other programs like cmake.

Part 3: Adding More Files

Now that we have basic cmake usage down, there’s only a little more left to talk about before you’re ready to strike out on your own.

Let’s create a more typical file structure, we’re going to have an src directory that holds C++ implementation files, and an include directory that holds C++ header files. We’re also going to create two new files, name.cpp and name.hpp. The final file structure should look like this:

In name.cpp write a function that asks the user their name, and returns it as a std::string and add the function declaration to name.hpp. In hello.cpp, include the header file with #include "name.hpp" and call the associated function so that you can greet the user by name.

We can modify our target_sources command in the CML to account for the new file locations:

target_sources(hello_world PRIVATE src/hello.cpp src/name.cpp)

It would also be acceptable to do this across multiple commands:

target_sources(hello_world PRIVATE src/hello.cpp)
target_sources(hello_world PRIVATE src/name.cpp)

Header files do not need to be added directly, instead, we just need to inform the build system what directories to search for them in:

target_include_directories(hello_world PRIVATE include)

You should now be able to build and run your modified hello world program

Answer the following:

• The paths used by target_sources and target_include_directories are relative, not absolute. What file or folder are they relative to?

• What are some differences between cmake and ninja?

• Why is it important to run cmake in its own directory?

Lab 2: System Verilog

Purpose

This is a crash course in basic System Verilog constructs. As some level of exposure to Verilog is a requirement for access to the team, this lab consists of a series of exercises that will ensure you’ve got the basics on lock.

If you find there is a construct or challenge you’re unsure how to approach, seek guidance from the team. Asking questions is encouraged.

Setup

Fork the Lab Week 2 repo to your personal Github account and complete the exercises in that repo. (For design log purposes, this cloned repo will be the one you link to.)

The toolchain has already been setup for you for all the exercises. It uses techniques you have not been introduced to yet so don’t be concerned if you don’t understand all of it. You can build the simulations using the techniques from the Week 1 Onboarding Lab.

If you wish to test your work, you can do so by running the following command inside your build directory:

ctest --output-on-failure .

We’ll talk more about setting up and running tests in the next lab.

Exercise 1: Warm Up

Implement the following opcode table with a single combinational assign statement.

Exercise 2: Sequential Logic

Implement an xor-based Fibonacci Linear Feedback Shift Register with taps at bits 15, 13, 12, and 10 (schematic provided below). If the reset is low, the LFSR should be initialized with the value present on the init input bus.

Step the output on positive clock edge.

Exercise 3: Module Composition

There are two Mystery modules under the Mysteries directory. Compose them according to the following schematic:

Make Note: In the next lab you’ll learn more about verification testing, but for now take a quick glance at dv/exercise1.cpp, dv/exercise2.cpp, and dv/exercise3.cpp. Exercise1 exhaustively tests all possible inputs, Exercise2 samples some possible initial values for a hundred cycles, and Exercise3 randomly tests inputs for a hundred cycles.

Why do you think the reason for these different testing approaches are? What are their advantages and disadvantages?

Exercise 4: Combinational Logic

Using an always_comb block, implement a decoder/mux that implements the behavior described in the following table.

Lab 3: Verification

Purpose

The layout of this lab is the same as the previous one, but the situation is reversed. Instead of having all the tests available and implemented already and filling in the SystemVerilog, the SystemVerilog is written and you will be implementing tests.

Testing, in the hardware world we call it “design verification”, is essential to ensuring that designs fulfill their intent. The options for repairing hardware that has already been fabricated are limited.

Background

In the Processor Design Team, design verification tests are regular C++ programs. If the program returns 0 from its main function, the test has passed, if the program returns something non-zero, the test has failed.

The heart of a test is the model. The model is a simulation of the device-under-test (DUT), synthesized from the SystemVerilog files which describe it using a program known as verilator. You don’t need to worry about invoking or using verilator directly, the toolchain does that for you.

The model is a C++ object, the public members of this object are the port list present on the SystemVerilog module. For example a module with the following port list:

module DUT(
    input [7:0] alpha;
    input [7:0] beta;

    output [15:0] gamma;
);

Will generate a model with the following public members:

struct VDUT {
  uint8_t alpha;
  uint8_t beta;

  uint16_t gamma;
};

When changing inputs, the outputs of the model can be evaluated using the .eval() method. For example:

  VDUT model;
  model.alpha = 5;
  model.beta = 8;
  model.eval();

  // model.gamma will change

Setup

Fork the Lab Week 3 repo to your personal Github account and complete the exercises in that repo. (For design log purposes, this cloned repo will be the one you link to.) Write your C++ test bench code in the C++ source code files located in the dv folder of the repo.

The toolchain has already been setup for you for all the exercises. It uses techniques you have not been introduced to yet so don’t be concerned if you don’t understand all of it. You can build the simulations using the techniques from the Week 1 Onboarding Lab.

Exercise 1: Something Familiar

Write a test that verifies the module implements the following behavior. Test all possible values of a and b for each operation.

Exercise 2: Reading Rainbow

Being able to read code is as important as being able to write it. For this exercise, assume that the module is correct. This test is being written to ensure that any future changes to the module do not change its external behavior.

Design a test that reasonably verifies the behavior of the Exercise2 module. Note that testing the entire space of possible states is likely not viable.

Make Note: What testing strategy did you adopt for this Exercise2? What decisions did you have to make and how did you come up with your answers?

Exercise 3: A Verification in Many Parts

The Exercise3 module follows the same schematic as in Lab 2:

However, the mysteries have been changed. Mystery1 operates as follows:

• If a is 0, then d is:

• If a is 1, then d is:

• If a is 2, then d is b

• If a is 3, then d is c

And Mystery2 operates according to the following rules:

• Clocked on negative clock edge

• When reset is high, out is initialized to:

• When reset is low, the output cycles through the following states:

Write a test that reasonably verifies the behavior of the module.

Exercise 4:

The Exercise4 module has the following behavior:

Write a test that reasonably verifies the behavior of the module.

Make Note: How does testing a Don’t Care work? What must be done to ensure the input truly has no effect on output?

Lab 4: Verification Toolchain

Purpose

This lab will be a walkthrough of the toolchain elements of verification. This will build on the toolchain lessons establish in Lab 1 and cover much of the material that was glossed over in Lab 3.

Some of the ideas that will be covered include: creating libraries of System Verilog modules, adding dependencies to a project, and using a testing framework.

Background

Oftentimes when building either software or hardware, we want to integrate third-party components and libraries, code written by other people. To do this we use a tool called a package manager. In the Process Design Team, the package manager we use is called vcpkg. While vcpkg is nominally a package manager for C/C++ projects, it’s suitable to be used with any collection of files including with our SystemVerilog projects.

One of the dependencies we’ll be interested in for the purposes of verification will be a test framework. A test framework provides utilities for running and logging information about our design verification tests. Since correctness is very important to hardware development, these utilities will come in handy. The Process Design Team uses a test framework called catch2 for its design verification.

Setup

Fork the Lab Week 4 repo to your personal Github account. This repo features the same modules as Lab 3, but you will be converting your tests to use the catch2 framework. In addition, much of the toolchain code is not yet written. We will need to add it ourselves.

Registries

A registry is a collection of information about packages, where packages are the source code files (SystemVerilog, C++, or even cmake files) that we wish to use in our project. We keep track of the registries we’re using in a given project with the vcpkg.json file.

If you look at the vcpkg.json file in the Lab 4 repo, you will find something that looks like the following under "vcpkg-configuration":

{
  "default-registry": {
    "kind": "git",
    "baseline": "6046e48163a26252f7a8f4aa036cbdd9eb793c20",
    "repository": "https://github.com/microsoft/vcpkg.git"
  },
  "registries": []
}

This is a registry listing, a json object that tells vcpkg where to look for packages. In this case, the only registry listed is the default-registry, which is where vcpkg will search if a requested package is not listed for any other registry. Here the default-registry is pointed at a git repo managed by Microsoft, which has many useful packages in it. The registries list, which would contain all other registries we wish to use, is empty.

We will need to add a registry to the registry list. The required fields for a registry are:

• kind: What type of registry is this? For our purposes this will always be a git repository, so you can always put "git" here

• baseline: the git hash to pull from. We’ll cover where to get this in a moment

• repository: a link to the git repository

• packages: a list of packages you would like this registry to be responsible for

The Processor Design package registry is located at:

https://github.com/NYU-Processor-Design/nyu-registry

To add that registry to the registries list, the entry should look like this:

  "registries": [
    {
      "kind": "git",
      "baseline": "",
      "repository": "https://github.com/NYU-Processor-Design/nyu-registry.git",
      "packages": [
        "nyu-*"
      ]
    }
  ]

This is incomplete, we still need to add a baseline. In order to get the necessary hash, go the registry repo page and click on “commits”.

Then, on the commits page, click on the double square icon to copy the full hash to your clipboard. You can then paste this into the baseline field.

We briefly note that the packages field contains the string "nyu-*", this tells vcpkg that this registry will provide every package that begins with “nyu-”.

Dependencies

Now take a look at the rest of vcpkg.json, this file describes our project. It should look something like this:

{
  "name": "week-four-lab",
  "version": "1.0.0",
  "description": "Template for week four lab",
  "homepage": "https://github.com/NYU-Processor-Design/onboarding-lab-4",
  "maintainers": [
    "Vito Gamberini <vito@gamberini.email>"
  ],
  "license": "CC0-1.0",
  "dependencies": [],
  "vcpkg-configuration": {
    ...
  }
}

The most important field to note is the dependencies list, it’s empty. Here is where we’ll list the packages we need vcpkg to fetch for us.

The packages we’ll need for this lab are:

• nyu-cmake: Utility functions for cmake. These functions make working with SystemVerilog more convenient

• catch2: The catch2 test framework mentioned above

Add these as a list of strings to the dependencies field of vcpkg.json. The order you list them does not matter.

Libraries and Packages

Once a package has been listed as a dependency, vcpkg will fetch it for us when we run cmake to generate our build files. We need to let cmake know about these packages in order to be able to integrate them, and the command to do this is called find_package().

The first package we’re going to need is nyu-cmake, so in the CML add the following line of code after the project() command:

find_package(nyu-cmake CONFIG REQUIRED)

find_package() takes three arguments here:

• nyu-cmake: this is the name of the package we want cmake to find

• CONFIG: this flag changes the search behavior cmake uses to find the package. If you’re curious to learn more, you can read about this in the official cmake documentation, but it’s not vital to understand

• REQUIRED: this flag tells cmake to throw a build error if it cannot find the requested package

Next we need to create a library. This works just like creating an executable from Lab 1, except the command is add_library() instead of add_executable().

We’re actually going to create a special kind of library called an interface library. This differs slightly from a “normal” library because an interface library can consist of code and files that aren’t compiled immediately.

Our SystemVerilog files cannot be compiled directly, so they’re a good fit for this style of library. To create our SystemVerilog library, add the following line to the CML:

add_library(lab4 INTERFACE)

Subdirectories and nyu_ Commands

In the same way that we split up source code into multiple files to keep it organized, we often split CMLs into multiple files for the same reason.

One way to do this is the add_subdirectory command, which will search a subdirectory for a CML and then run that CML. First, create a CML inside the rtl folder of the repo, then add the following line to our original CML after the add_library() command:

add_subdirectory(rtl)

Now we can add code to the rtl/CMakeLists.txt file, and it will be run by cmake when it reaches the add_subdirectory() command.

One of the important commands that the nyu-cmake package gives us is nyu_add_sv(), which lets us associate SystemVerilog files with a library (or any other cmake “target”).

In the rtl CML file, add the following lines:

nyu_add_sv(lab4
  Exercise1.sv Exercise2.sv Exercise3.sv Exercise4.sv
  Mysteries/Mystery1.sv Mysteries/Mystery2.sv
)

Note that the first argument is the target we wish to associate the files with, followed by said files. Also note that the paths are relative to the CML file the command is written in.

Conditional Statements and Enabling Testing

It’s not always appropriate to build simulators. Sometimes people will want to integrate our modules into their own code, and reassured that we have thoroughly tested the modules ourselves, do not need to spend the time and CPU cycles building and running the tests themselves.

To support this style of usage we will check a variable, in the case of the Processor Design Team this variable will always be named NYU_BUILD_TESTS.

The usage of the conditional then looks like this:

if(NYU_BUILD_TESTS)
  # Conditionally run commands go here
endif()

The exact semantics of a cmake conditional are a little bizarre and not something we’re going to worry about too much. If you’re interested in all the things that are considered “true” or “false” by cmake, you can read more about it in the official docs.

We’re going to write our testing commands inside the dv directory (dv stands for design verification), so add a CML to the dv directory.

Inside the top level CML (“top level” means the original CML, in the root directory of the repository), add a conditional that checks NYU_BUILD_TEST and inside that conditional add the following lines:

  enable_testing()
  add_subdirectory(dv)

The add_subdirectory() command should now be familiar. The enable_testing() command tells cmake that we want it to generate files necessary to automatically run tests for us.

When running cmake, we’ll need to turn this conditional on. To set the NYU_BUILD_TESTS variable when running cmake, we’ll use the following command (assuming we’re running cmake from inside a build directory):

cmake -DNYU_BUILD_TESTS=TRUE ..

The Test Executable

Inside the dv CML, we’re going to need to grab our test framework package with the following line of code:

find_package(Catch2 3 REQUIRED CONFIG)

You might notice that this find_package() has an additional argument, 3, this is a major version number. We’re telling find_package() we need at least version 3 of the Catch2 package.

Now we can create an executable file that consists of our tests. To do this, use the add_executable() command to create an executable named tests and the target_sources() command to add all the .cpp files in the dv directory as sources.

We also need to associate the lab4 SystemVerilog library to our executable. We do this with the following command from the nyu-util package:

nyu_link_sv(tests PRIVATE lab4)

This takes all the SystemVerilog files we associated with the lab4 library, and also associates them with our tests executable. But we still need to tell cmake what to do with these files.

To transform a SystemVerilog file into a model, like the ones in Lab2 and Lab3, we need to tell the verilator tool which modules we would like to be exposed for simulation. These exposed modules are called top modules, and we’ll need to tell cmake and verilator about them explicitly.

In these labs, the Exercise1, Exercise2, Exercise3 and Exercise4 modules are our top modules, while the Mystery1 and Mystery2 modules are only used internally and don’t need to be available for testing on their own.

The command to invoke verilator and choose top modules is the following:

nyu_target_verilate(tests
  TOP_MODULES Exercise1 Exercise2 Exercise3 Exercise4
)

Because of limitations in cmake and verilator, the nyu_target_verilate() command should always come after all nyu_add_sv() and nyu_link_sv() commands.

Finally, we also need to associate Catch2 with our tests executable and tell Catch2 we would like it to handle generating tests for us. We do that with the following command:

target_link_libraries(tests PRIVATE Catch2::Catch2WithMain)

This is sort of like nyu_link_sv() above, but it’s linking a C++ library instead of verilog source code.

The absolute final thing is we need to tell Catch2 about our tests we would like it to run. This is an automatic process, and we’re not going to worry too much about how it works or the exact semantics, the commands are:

include(Catch)
catch_discover_tests(tests)

If you’re curious, you can learn more about Catch2’s cmake-integration from the official docs.

Adapting the Test Cases

Previously your test cases probably looked something like this:

int main() {
  VExercise1 model;

  // Setup some inputs
  model.eval();

  int expected;
  // Calculate the expected value

  if(model.out != expected)
    return 1;
}

When writing test cases with Catch2, our code will look like this:

TEST_CASE("Exercise 1") {
  VExercise1 model;

  // Setup some inputs
  model.eval();

  int expected;
  // Calculate the expected value

  REQUIRE(model.out == expected);
}

To adapt your current code to Catch2, you should only need the REQUIRE() macro, but Catch2 has many other useful structures as well that you can explore in its docs.

To complete the lab, adapt all of your test cases to the Catch2 model and run it using the same procedure used for the previous two labs.

Review

Answer the Following:

• What is a registry?

• What is a package?

• What’s the difference between an interface library and a “normal” library or executable? Can you think of any uses for this besides SystemVerilog files? (Think about source code used for generic programming)

• What is a top module?

Lab 5: Advanced System Verilog

Important Note

This lab is currently incomplete as the Lab Week 5 Repo is currently incomplete and there is no exercise for this lab. You should read over the information provided in this lab and then move on to Lab 7 for details on what to do next.

Purpose

System Verilog is a large language, but we have almost covered all of the synthesizable elements (meaning, “stuff that can be turned into hardware”) already. Non-synthesizable parts of the language are used for design verification. Since the Processor Design Team uses C++ for performing design verification, we won’t concern ourselves with the parts of System Verilog that cannot be synthesized.

This lab is designed to cover most of the remaining elements of System Verilog that are useful for our purposes. This will still consist of a substantial amount of work, and is not expected to be completed in a single week.

Having completed this lab, you will be sufficiently prepared to contribute to component design and implementation for the team.

Setup

Fork the Lab Week 5 repo to your personal Github account. As with lab 4, a great deal of the toolchain code has not yet been written. You are expected to write the necessary toolchain code to implement any required modules and design verification tests. It may be useful to review the instructions of lab 4 if you need a refresher on this.

Data Types

You are familiar with the standard names reg and wire, and have some intuition that these map onto concepts of “registers” and “buses” that represent physical flip flops and copper interconnects between components respectively.

This understanding is misleading, or at least insufficient. There is no requirement that a reg value be implemented as a physical register, and similarly there is no guarantee that a wire does not involve intermediate buffers or other timing elements. Because these names are misleading, in our code from here on out we never use reg and rarely use wire.

Let’s be formal for a moment, in the System Verilog specification there are two main kinds of data objects: nets and variables. These two groups differ in the way in which they are assigned and hold values.

Nets can be written by one or more continuous assignments, primitive outputs, or modules ports. A net cannot be procedurally assigned.

Variables can be written by one or more procedural statements. Alternatively, variables can be written by one continuous assignment or one port.

A wire is a type of net and, in plain English, the advantage of a wire is that is can be driven by multiple continuous assignments. When a wire has multiple drivers, it is resolved to the value of the “strongest” driver. Electrically speaking, this can be thought of as the input with the lowest impedance. In digital design, we rarely have any reason to have multiple continuous assignments to the same bus, and so we rarely have any reason to use a wire.

A reg isn’t even an object kind, it’s technically a data type and one that comes with tricky restrictions that we don’t have time to explore here.

logic is also a data type, by default it is a variable, and it has the same semantics as reg. logic does not run afoul of the same complications as reg and so it’s what we’ll use.

Further Reading: This explanation leaves a lot to be desired, I’ve written a blog post that explores this in much more depth than we have room for here. You’re encouraged to give it a read.

The quick and fast rules are these:

• Use logic for single driver circuits (most things), wire for anything else

• Always declare port direction for each port

• Allow everything else in a port declaration to be implicit except if you need an output variable, then use output logic

Other Net Kinds

System Verilog includes many more kind of nets, and even allows for user-defined net kinds. These include kinds such as tri, wand, and wor.

The general rule for the Processor Design Team is this: Don’t use any of the other net kinds.

There may exist extremely rare instances it makes sense to violate this rule, in which case the question should be raised and the exception noted in the code.

Interfaces and Modports

An interface can be thought of as a special type of module that bundles ports and connections between ports together.

Consider the following modules:

module Controller(
  // Inputs from top-level module
  input alpha,
  input beta,


  // Interface with a peripheral module
  input phi,

  output chi,
  output psi,
  output omega
);
  // Do stuff
endmodule

This module has two sets of ports. The first set is used to receive directions from the top-level module, and the second set is used to communicate with a peripheral module.

The peripheral module will have an inverse set of ports:

module Peripheral(
  output phi,

  input chi,
  input psi,
  input omega
);
  // Do stuff
endmodule

The top-level module will have to do some work to connect the Controller to the Peripheral. Something like the following:

module TopLevel(
  input alpha,
  input beta
);

  logic phi, chi, psi, omega;

  Controller ctrl(alpha, beta, phi, chi, psi, omega);
  Peripheral prph(phi, chi, psi, omega);

  // Note: System Verilog has a couple shorthands called
  // "implicit named port connections" and "wildcard named
  // port connections" that we could use here. But those
  // are outside the scope of this example

endmodule;

This is less than ideal. We need to make sure we get all the ports in the right order in the module instantiations, if we ever modify the interconnects between the Controller and the Peripheral we will need to change the code in many places, and sometimes such interconnects can contain dozens of logics which becomes a lot of code to write.

The answer is an interface consider the following:

interface Com_if();

  logic phi, chi, psi, omega;

  modport ctrl(
    input phi,

    output chi,
    output psi,
    output omega
  );

  modport prph(
    output phi,

    input chi,
    input psi,
    input omega
  );

endinterface

Now we could modify our modules to use this new interface:

module Controller(
  input alpha,
  input beta,

  Com_if.ctrl com
);

  // phi, chi, psi, and omega can now be accessed via
  // com.phi, com.chi, com.psi, and com.omega respectively

endmodule

Similarly with Peripheral:

module Peripheral(
  Com_if.prph com
);
  // Do stuff
endmodule

And finally in the TopLevel, we can interconnect like so:

module TopLevel(
  input alpha,
  input beta
);

  Com_if com();

  Controller ctrl(alpha, beta, com.ctrl);
  Peripheral prph(com.prph);
endmodule

Since interfaces work just like modules, we can take this one step further and move alpha and beta into the interface as well, but only expose them to the Controller module:

interface Com_if(
  input alpha,
  input beta
);

  logic phi, chi, psi, omega;

  modport ctrl(
    input alpha,
    input beta,

    input phi,

    output chi,
    output psi,
    output omega
  );

  modport prph(
    output phi,

    input chi,
    input psi,
    input omega
  );

endinterface

The Controller:

module Controller(
  Com_if.ctrl com
);

  // alpha, beta, phi, chi, psi, and omega can now
  // be accessed via com.alpha, com.beta, com.phi,
  // com.chi, com.psi, and com.omega respectively

endmodule

Peripheral is unchanged, so the TopLevel now looks like this:

module TopLevel(
  input alpha,
  input beta
);

  Com_if com(alpha, beta);

  Controller ctrl(com.ctrl);
  Peripheral prph(com.prph);
endmodule

An interface is itself a module, and thus can have all the styles of logic implemented inside it as a normal module can. That said, this should be avoided. It may be appropriate for simple continuous assignments to be performed inside an interface, but in most cases an interface should consist only of logic elements and modports.

Parameterized Modules & Interfaces

We do not always know every way a module is going to be used, parameterization allows us to defer some elements of a module’s implementation until it is instantiated. In this way, parameterized modules work similarly to C++ templates.

Consider the following ALU-type module:

module ALU #(
  WordSize = 16
) (
  input clk,
  input logic [1:0] op,
  input logic [WordSize - 1:0] a,
  input logic [WordSize - 1:0] b,
  output logic [WordSize - 1:0] out
);

  always_ff @(negedge clk)
    case(op)
      0: out = a + b;
      1: out = a - b;
      2: out = a & b;
      3: out = a | b;
    endcase

endmodule

There is some unfamiliar syntax here, notably the #() element. This is a parameter list. It precedes the port list and contains a variable named WordSize which is given a default value of 16.

This will make our ALU module ports 16-bits wide if we instantiate it in the normal way, for example:

  // This will be a 16-bit ALU
  ALU alu(clk, op, a, b, out);

However, we don’t have to use the default values. We can expand our ALU without having to change the module code thanks to the WordSize parameter. The syntax is the following:

  // This will be a 32-bit ALU
  ALU #(32) alu(clk, op, a, b, out);

Exercise

Lab 6: Packaging and Dependency Management

Lab 6 is currently incomplete, please see Lab 7 for details on what to do next.

Lab 7: Becoming a Processor Designer

“Procezzor”

By now, you should be quite comfortable with CMake, SystemVerilog, C++, and general team operations and expectations.

The Time Has Come

Now, you must choose what you wish to work on for the semester. Your choices are outlined below.

Core

The heart of an SoC is the CPU Core. As part of the core team, you will work on the design and implementation of a CPU core capable of executing the RISC-V-32I instruction set.

Many of the individual modules that make up the core have been outlined in detail for easier implementation so you can get started writing Verilog code right away. You can find our getting started guide here. We also have interfaces between modules that need to be built. More information can be found here.

For those with more advanced skills and seeking a deeper level of involvement on the core design itself, many of the modules that make up the core have yet to be fully outlined for implementation and we encourage you to take a shot at making those outlines yourself, a list of where exactly each module stands can be found here.

Finally, for those with the requisite knowledge, skills, and passion, much of the overall core design still needs to be finalized. This includes things like the caches, branch prediction, hazard detection, and more. Designing these components and functions will require a strong background in computer architecture as you’ll need to be ready to validate and troubleshoot both, your designs and the designs of others. You can see the block diagram of the current core design on the repository, and you can find the functionality and design documentation for the more complex components here.

Memory

An SoC needs memory. As part of the memory team, you will work on the memory simulator and integrating it with the bus. You will work closely with the AMBA team whilst designing and implementing the memory manager since the memory manager is a subordinate on the AMBA high-performance bus.

Our SoC’s memory is an experiment in using OpenRAM, an open-source RAM compiler. As part of the team, you will be expected to become an expert in OpenRAM and how it interacts with our chip.

As it stands, we have RAM and ROM generation scripts, but they need to be thoroughly tested and deciphered. If you wish to work on memory, reach out to leadership since the team is currently defunct.

AMBA

AMBA is the interconnect architecture which connects various parts of the SoC together. It is the vertebrae of the chip, connecting core to important subordinates like RAM and ROM, GPIO, UART, etc, and to each other, when needed.

An intriguing facet of working on AMBA is comprehending and translating ARM’s specification. Trivial concepts have been summarised for easy access but you will still be expected to read the spec sheets, propose and discuss component designs with the team.

Additionally, our implementation is one of very few open-source AMBA implementations on the internet, which allows us a unique challenge of not having a reference. Everything you produce will be one of its kind and all of us will learn and grow from that process.

But perhaps, AMBA’s most interesting challenge includes translating logic into RTL. Everything AMBA does is easy to think about programmatically, but it is admittedly quite challenging to translate into SystemVerilog. Every day, the team learns novelties in SystemVerilog and our extended toolchain.

If working on AMBA speaks to you, read more about it here.

Onboarding/Documentation

A project of this magnitude needs thorough technical documentation for the sake of future team members and strangers who wish to see our work. Documentation includes writing module and interface templates, development guides, improving onboarding labs and the team’s website, and other written issues that don’t directly involve coding/Verilog.

It is strongly recommended that you join a development team such as Core, Memory or AMBA as well as working on documentation. You can be responsible for that team’s docs while also contributing to component development.

Something Else Entirely

You can work on things that our team has never worked on before, such as, the simulator, or develop software for the chip to be. Alternatively, you could be individualist and prefer not to work in a team - feel free to work on one of the many peripherals we need.

Whatever the case may be, if none of the above speaks to you, reach out to leadership to discuss next steps so we can equip you for success.

Overwhelmed by Choice

Don’t worry if you’re not quite sure what you’d like to work on. You can work on as many teams as you wish to. Just don’t spread yourself too thin.

Take the week to explore how various teams operate, talk to the Czars, and other team members.

After Deciding

Once you know what team(s) you wish to work on, inform the project manager, and check in with your Czar.

Happy processor designing!

Lab 8+: Advanced Processor Design

Fall 2024 Design Notebooks

• Anu Tadapeneni

• Cameron Bedard

• Darren Kuo

• Dmitri Lyalikov

• Rielle Lim

• James Jin

• James Xie

• Joshua Cho

• Kyle Liu

• Noah Mays-Smith

• Ruichan Gao

• Uma Nachiappan

• Xingzhi Dai

• Xhovani Mali

• Ben Feng

Anu’s Design Notebook

Week of Sept 16, 2024

• Started labs and created my design notebook

Week of Sept 23, 2024

• Finished lab 1 this week, got started on lab 2
• Lab 1 was pretty fun but also the link didn’t work initially, seems to be an update error.
• link to be updated shortly

Week of Sept 30, 2024

• Finished lab 2, did not get started on lab 3
• Lab 2 was also pretty basic since i have a lot of experience with verilog, so no troubles here
• Started going through the projects in the github to find what I want to do

Week of Oct 7, 2024

• I did Lab 3, it took me longer than expected because of a bug that had no right being as hard to fix as it was
• I’m pretty interested in Memory and/or Amba, so ima read up so more. Optimization problems are fun and this is a pretty complex one.
• The teams are pretty bare though, so I’m digging through the previous documentation

Week of Oct 14, 2024

• started lab 4, did not finish
• Midterms are next week so not very productive when it comes to the VIP right now. Did some research on how exactly memory works.

Week of Oct 21, 2024

• May god have mercy on our souls

Cameron Bedard Design Notebook

09/16 - 09/20

• Reviewed Core Team Documentaion. Brainstormed ways to make it more beginner friendly.

09/23 - 09/27

• Met with Xingzhi on Core Team objectives for the semester and plan to enroll new members to the team.

09/30 - 10/04

• Studied the past outlines of the interconnection modules.
• Began to understand the outstanding outlines for the interconnection modules.

10/07 - 10/11

• Worked on documentation for the General Control Module. Backtracking through the documentation studying origin of design decisions.
• Worked with Michael on understanding implementatnion details.
• Identified mistakes in the outlines whcih caused mistakes in the implementation.

10/14 - 10/18

• Updating the General Control Modules outline and implementaion and doublechecking design logic.

Darren’s Design Notebook

Week of September 6th

Project Work

• Created Design Notebook for Fall 2024
• Discussed with Rielle regarding some Finance related things

Comments

• Don’t press random buttons on gitlens expecting things to work
• I know cmd git, gitlens should be easy, I just need to think about it

Week of September 13th

Project Work

• Looked at my spaghetti Code for Onboarding Lab 3 from last semester

Comments

• I need to learn better C++ one way or another during this semester

Week of September 20th

Project Work

• Attempted to continue work on Lab 3, got stuck and asked Uma for help during the meeting, still stuck.
• I understand the concept of what the module does, I just can’t seem to figure out how to right a proper test in c++ for it

Week of September 27th

Project Work

• I was quite sick this week, unfortunately no work done.

Comments

• Why is my immune system so weak

Week of October 4th

Project Work

• Discussed with Uma regarding next steps I should take in the VIP since I am stuck on the onboarding labs.
• Awaiting Vito’s response since Rishyak is busy regarding the memory subteam.
• Looked at last semesters design notebook to see where I was at with researching about memory and OpenRAM

Comments

• Glad to be able to work directly on one of the subteams without having to finish these labs, since I think I would learn better by attempting work on the subteam.
• Will look at the the nyu-mem repo for poential starting points or just a general where-abouts regarding this defunct subteam

Week of October 11th

Project Work

• Looked into one of the issues on nyu-mem about generating the ROM script using OpenRAM
• The last commit regarding the ROM and RAM generation stated issues with the ROM Generation
• Successful RAM generation
• After reading at the docs available on OpenRAM, I have a slightly better understanding of what a potential config file could look like, but I still am not sure
• Slight confusion on Rishyak’s comments on not tracking files generated by OpenRAM since on OpenRAM ROM Generation it states that after a succesful generation there should be additional files such as
  • GDS(.gds)
  • SPICE(.sp)
  • Log(.log)
  • Configuration (.py) for replication

Comments

• The LVS (Layout vs. Schematic)/DRC (Design Rule Check) check in the Config file is to ensure that the RAM and ROM can be physically generated for ICs
• OpenRAM environment setup questions I need ask either Vito or Rishyak

Week of October 18th

Project Work

• Looked into another issue on nyu-mem, this time on experimenting with the tech_name parameter in the RAM_Config.py file.
  • According to OpenRAM, they provide access to 2 different tech models for RAM generation
    • SCMOS SCN4M_SUBM is the current one in use in the config file
    • FreePDK45 which is a foundry model unlike a generic based one such as the SCMOS
  • We may want to test out the FreePDK45 model as that might result in a better final product
  • Current workspace in out repository is based off of Sky130 which is another PDK
  • First get a working ROM_Config.py then potentially moving on to testing with different technology for this as well
    • Testing out ROM generation using gf180mcu, this is currently not supported for RAM generation according to OpenRAM
• Hex to Verilog translator is under the HexParser directory
  • Latest note by Sean is how this will be useful once ROM is generated properly
  • Will be able to test after being able to get ROM generated successfully
  • This can be done using a Python Script, which I will need to learn about

Comments

• PDK stands for Process Design Kit and can be used to create Photonic ICs (PICs)
• Potentially look into how to make docs for this repo, as the lack of it makes it hard to understand the current status of this repo
• Still trying to figure out the status quo of this semi-abandoned repo since past members have graduated

Week of October 25th

Project Work

• Nothing done this week, 3 midterms to take care of.

Comments

• Are EE’s just math majors in disguise?

Week of November 1st

Project Work

• Looked into Python Scripting
  • Its just a .py file, or a plain-text file that contains python code to be run directly
  • Has no association with outside classes as it is self sufficient, I might wrong regarding this statement, will come back to fix if is the case
• Relooked at the open issue on nyu-mem regarding the Hex to Verilog python file
  • Am confused since this is labeled as module on Github, however can be as a script. so is the current file a module a script, or something in between
• Also read up on the Onboarding Lab 4 regarding the Catch2 framework.
  • Unfortunately, due to my incompetence, I can not seem to figure out a feasible way to complete lab 3 just yet
  • The Catch2 Framework makes sense, adding the verilog files that are to be tested, and then linking up the C++ test file and then running the tests that have been changed to work under the framework

Comments

• Catching up on Design Notebook entries is actually quite rewarding.
• Will continue to think about Lab 3, and look read up on Lab 5 soon

Week of November 8th

Project Work

• Talked to Uma regarding conferences and how that could help get the VIP get funding
• Looked into possible conferences we could attend as a VIP related to Semiconductors
  • Keeping time and location in mind as of right now there are three front running possibilities
  • ASMC Albany 2025
    • May 5th - May 8th 2025
    • Technical Conference for improving the manufacturing of semiconductors
  • SemiExpo Heartland, Indiana 2025
    • April 1st - April 2nd 2025
    • Focuses on Smart Mobility
      • EVs and Power semiconductors driving sustainability
      • Autonomus Vehicles powered by AI
      • Chiplets reshaping Computer Architecture
  • MRS Boston 2024
    • December 1st - December 6th 2024
    • Much tighter time and possible conflict with being close to Finals
    • Focuses more on Material Engineering such as
      • Electronics, Optics and Photonics
      • Nanomaterials
      • Processing, Manufacturing, and Synthesis
      • Quantum Materials

Finance Updates

• There are still none from the start of the Semester
• Conference thing is a start of getting somwhere, awaiting news on if VIPs are Yearly funded or Semesterly Funded

Comments

• I think even if a conference soon is not possible, working towards the process of being able to be funded for one would be very interesting and potentially increase membership if this is something we can get done relatively consistently. All this for more funding for the VIP so that we have the ability to do more

Dmitri Lyalikov’s Design Notebook

Work for Week Ending 9-13

• Completed Lab 1 and built dependencies on local system (cmake, verilator, git, cURL)
• Completed Lab 2 and began on Lab 3 for verification: https://github.com/DmitriLyalikov/onboarding-lab-2/

Rielle Lim’s Design Notebook

Week of 15 September, 2024

• Created this design notebook a full week late :P

Week of 22 September, 2024

• Reviewed Lab 1 because I don’t remember how things work
• Did some admin recon with Uma about attendance and meetings
• Planning to redo/review all labs and pick up on a core issue next week

Week of 6 October, 2024

• Didn’t get to do what I planned to last week due to unforeseen circumstances
• This week:
  • Picked up on documentation issue in Core for reformatting in hex

Week of 27 October, 2024

• Planned out future meetings with Uma
• Help host makeup meeting and formal meeting

Design notebook for James Jin (2024 Fall)

Oct. 7th - Oct. 13th, 2024

Work done

• Lab 5: “completed” lab 5

Working comments

In the past weeks I was fully committed to finishing a journal paper. Now that the urgent work is done, I have read the advanced system verilog tutorial to understand some of the team’s rules with verilog usage.

James Xie’s Design Notebook

Week of 2 September 2024

Created Engineering Notebook.

Week of 16 September 2024

Finished onboarding lab 1

Week of 23 September 2024

Finished onboarding lab 2

Week of 30 September 2024

Finished obboarding lab 3 and lab 4

Week of 7 October 2024:

Finished onboarding lab 5 (no repo according to the lab manual)

Week of 14 October 2024:

Finished onboarding lab 7 (no lab 6). Now ready to start development jobs.

Week 1:

• Reviewed all of the labs

Week 2:

• Looked into AMBA and Core teams. Talked to some people about them. AMBA seemed interesting at first because I wanted to learn more about communication protocols.
• Deciding to just go with the Core team

Week 3:

• Before breaking into the RISC-V processor design, I am currently creating a very simple CPU which I am going to implement on an FPGA
• Thinking about having a 2 bit instruction set for addition, subtraction, and, or
• 4 bit registers
• Thinking about what parts of a Control Unit I would need to make the CPU barely functional
• Currently designing memory unit

Week of 9 September 2024

Project Work:

• The VIP processor design team commenced the project with a kickoff meeting to establish a shared vision. Team members discussed high-level goals, including performance, power consumption, and integration challenges. By the end of the week, a comprehensive list of requirements was created, serving as a roadmap for the project.

• A timeline was drafted to outline key milestones and deliverables for the project. This timeline included deadlines for design, implementation, and testing phases. The team felt confident as they laid the groundwork for a structured approach moving forward.

Week of 16 September 2024

• In the second week, the team focused on exploring different architectural options for the L1 instruction cache. They analyzed various configurations, such as direct-mapped, set-associative, and fully associative caches. Each option was evaluated based on its impact on speed, complexity, and power consumption.

• Team members engaged in collaborative brainstorming sessions to weigh the pros and cons of each architectural choice. This collaborative environment fostered creativity and allowed for a diverse range of ideas to surface. Ultimately, the team selected a hybrid approach that balanced performance with practical implementation challenges.

Week of 23 September 2024

• During the third week, the team continued to plan out the L1 instruction cache efforts.

Week of 30 September 2024

• As the week progressed, the team collaborated closely to discuss the implications of their findings on overall processor design. Regular updates ensured that everyone was aligned on the direction of refinements. By the end of the week, the team had a clearer path forward, backed by solid data-driven insights.

Week of 7 October 2024

• Important instruction cache work was discussed with Core team member Xingzhi Dai and James.

Week of 14 October 2024

• Work has officially started albeit the coding is less than 10 lines long.

Week of 21 October 2024

• The fourth week centered on performance analysis, utilizing advanced simulation tools to evaluate the cache’s effectiveness under various workloads. Key metrics, such as cache hit rates and access latencies, were rigorously analyzed to identify potential bottlenecks. The team recognized that even small optimizations could lead to significant performance improvements.

Noah Mays-Smith’s Design Notebook

Week One:

Created first design notebook

Week 1.5:

Project Work: Finished Lab 1: https://github.com/Noahms12/lab1

Had some problems with updating my notebook. I need to get the hang of the order that everything is done in. Suggestion for “Your first design notebook”. The description “(link/to/repo)” is not clear on whether it wants a link to a file within our repo or a link to my personal github. I’d recommend changing it to something like “https://github.com/example”

Week 2:

Project Work: Started work on Lab 2: https://github.com/Noahms12/onboarding-lab-2.git

Attended the meeting on Thursday and asked some questions about parts of lab 1 that I was confused about as well as asked for help figuring out the workflow for each lab. Worked through excercise 1 after reteaching myself some verilog. Then I compared my solution to people in previous semesters to ensure it was correct. I cannot figure out where to run the command “ctest –output-on-failure .” to test my code for Excercise 1. I ran it in all of the files in the lab directory, but every time I got the output “No tests were found!!!”

Week 3:

Project Work: Finished work on Lab 2: https://github.com/Noahms12/onboarding-lab-2.git

Finished working on Lab 2. Excersises definitely helped me remember verilog from my classes, and I’m feeling much more confident with it now. Still couldn’t figure out how to test my code aaas described at the beginning of the lab 2 description, but I compared my work to other members’ Lab 2’s to make sure I was doing everything correctly.

Week 4:

Project Work: Started Lab 3: https://github.com/Noahms12/onboarding-lab-3.git

Got through exercise 1, and started exercise 2. I haven’t combined c++ with verilog before in this way, so understanding how things like the uint16_t data type work, and how I can manipulate it is difficult. I’ve looked at a few completed design notebooks to get some ideas, but out of the ones i’ve found, there’s a lot of syntax that I’m not familiar with.

Also attended the meeting on thursday to try to figure out the problem last week with testing my code, but was unable to find an immediate solution.

Week 5:

Project Work: -None-

Still working on Lab 3, but I wasn’t able to get a lot of work done because of midterms and multiple personal events this week. I have updated the formatting of my notebook to what it is supposed to be.

Week 6:

Project Work: -None-

Absolutely swamped with homework after midterms. Additionally, personal events have also gotten in the way of having enough time to complete everything. Attended meeting on thursday.

Week 7:

Project Work: Completed Lab 3: https://github.com/Noahms12/onboarding-lab-3.git

Was able to get it finished. I realized that a lot of the c++ in lab 2 could be used as a framework for the questions in lab 3, so I was able to finish of the lab. I was recommended to use Rishyak’s lab’s as assistance if required, so I did in order to help check that I had done it correctly.

Week 8:

Project Work: Started Lab 4: https://github.com/Noahms12/onboarding-lab-4.git

Started Lab 4 but got stuck. Ran into an issue when running the find_package(nyu-cmake CONFIG REQUIRED) command. I’m getting the error “syntax error near unexpected token `nyu-cmake’”. I asked in the Discord but haven’t had time to follow up and complete the lab. I plan on reading some documentation for the subteams, and try to join one in the next two weeks.

Week 9:

Project Work: Read through Core and AMBA documentation

Haven’t made any progress on Lab 4, again because of midterms. After monday, I will be done until finals, and plan on making a lot of headway during that break. I read through the Core and AMBA documentation, and I have decided that once I feel more confident in the material, I will start working with Core. I would like to sit with, take notes, and ask questions to someone about the workflow, as I am still confused about a lot of what is going on. Next meeting I will also ask about some issues that I’ve been having with testing the labs.

Ruichen (Richard) Gao’s Design Notebook

This is the Design Notebook of Ruichen (Richard) Gao for NYU Processor Design Vertically Integrated Projects

This is the repository for Onboarding Labs All Labs and Questions are in the repository

Work Progress

Week 1 September 2024

Joining the team

Week 2 September 2024

Getting to know team projects

Week 3 September 2024

Meeting with the team

Week 4 September 2024

Finishing Lab 1

Week 1 October 2024

Working on Lab 2

Week 2 October 2024

Finishing Lab 2

Uma Nachiappan’s Design Notebook

A Doc Czar doc czarring and processor designing…

Week of 23 Sept 2024

• figuring out how to admin!
• team meetings scheduled and started
• trying to get all the design notebooks on the site and have new members working on onboarding, with old members continuing their previous work
• continuing to re-draft site docs

Week of 30 Sept 2024

• had some issues with a few labs & CMake (various development environment differences, cmake version differences)
• signed up for VIP Showcase and got volunteers for the table
• got an email for Rising Violets (fundraising opportunity)

Week of 7 Oct 2024

• attendance/dn issues
• spoke to people about transitioning to core/AMBA development
• had a mini crisis about not paying enough attention to PRs and DNs

Week of 14 Oct 2024

• VIP showcase! Our three QR codes against the world (and the robot next to us). Had some recruitment! and students who already applied also showed up.
• Started actually assessing where people were with DN progress –> thinking about midterm grading/reports

Week of 21 Oct 2024

• midterm reports! and getting people to actually push their notebooks – looking a little sparse as I write this (including my own). I don’t want the C train but who knows, that might be where this is going.
• procrastinating on site docs as usual
• need to check in with core team leads to see what’s going on – no serious commits since last semester

xingzhi’s Design Notebook

Week of Sept 20, 2024

• Meeting with the team. Discuss with cameron about what to do fro core in this semester.

Week of Oct 1, 2024

• Meeting with the team. Reading documentation about the Ins cache and try to fix the outline and the code.

Week of 7 Oct 2024

• Rewrite outline of L1 chache
• Start working on the rtl

Week of 14 Oct 2024

• VIP showcase. Meet with some possible team member there.

Xhovani’s VIP Processor Design Notebook - Fall 2024

Weekly Updates

Week of 23 September 2024

Progress Summary:

I set up my development environment on my MacBook Pro. Homebrew is already installed from prior internship work. For virtualization, I use Parallels on macOS and access VirtualBox remotely on my desktop.

Project Work:

• Onboarding Lab 1

  • Repository Link: Onboarding Lab 1 Repository
  • Issue Encountered: I encountered issues with CMake, specifically an error during the build process suggesting compatibility issues.
  • Resolution: Resolved the issue by reinstalling make with support for the arm64 architecture.

• Onboarding Lab 2

  • Repository Link: Onboarding Lab 2 Repository
  • Issue Encountered: Testing command wouldn’t recognize the folder structure from the build folder.
  • Resolution: Resolved the issue by changing the directory to the build folder and running the test command.

• Onboarding Lab 3

  • Repository Link: Onboarding Lab 3 Repository
  • Issue Encountered: Header files provided shown as errors.
  • Resolution:
  • Issue Encountered: I encountered issues with CMake, specifically an error during the build process suggesting compatibility issues.
  • Resolution: Resolved the issue by reinstalling make with support for the arm64 architecture.

Week of 30 September 2024

Progress Summary: Attended the weekly meeting to review onboarding labs, discussed challenges, and continued working on tasks with feedback from the session. Spoke about possible events for the semester as well as next steps post onboarding-labs.

Week of 7 October 2024

Progress Summary:
Separated the onboarding lab folders into a new repository based on feedback from the weekly meeting.

Week of 14 October 2024

Progress Summary:
Attended the VIP Showcase Event!

Week of 21 October 2024

Progress Summary:
Finished working on onboarding-lab 2.

Week of 28 October 2024

Progress Summary:
Finished working on onboarding-lab 2.

Week of 4 November 2024

Progress Summary:
Almost done with onboarding lab 3. Just need to confirm code and test.

Ben Feng 2024 Design notebook

week 3 of 19 September 2024

Project work:

• onboarding lab 1: complete lab .

I finished lab 1 this week and learned how to build new system with Cmake and also learned how to work in the virtual box for the first time.

The work enviorment was pretty struggling and especially how to getting used to with the Ubunto in the virtual box. Also, I done the pull request wrong and thankfully Vito help me out at the end.

week 4 of 26 September 2024

Project work:

• onboarding lab 2: working on it.

There is a project for my electronics course and I spent most of my week on it. I just finished exercise 1 in the lab 2, and expecting to finish them next week.

week 5 of 3 October 2024

Project work:

• onboarding lab 2: finished

I finished lab 2 this week, and review some basic verilog content like how to use clock to indicate when will the program start and how to assign output based on the what the input is.

The verilog grammar struggle me for a while since I haven’t touch it for the entire summer so I have to look up in the internet to check how to write the correct verilog code. Also, I spent some time with understanding what the question is asking for, and eventually I think I figure it out? Maybe.

week 6 of 11 October 2024

Project work:

• onboarding lab 3: working on it

Working on lab 3, and had some issues with the testing process. And dicussed with Vito, he said the VM is too old and helped me set up my WSL instead. Unfortunately the WSL also doesn’t work so Vito is trying to figure out the issue in WSL and hopefully it will work soon.

week 7 of 18 October 2024

Project work:

• onboarding lab 3: working on it

Dive into midterm study for this and next week entirely, going to continue to work on it after the midterm.

week 8 of 22 October 2024

Project work:

• onboarding lab 3: working on it

Still studing for midterm, going to resume to work on lab next week.

week 9 of 31 October 2024

Project work:

• onboarding lab 3: exercise 1 and 2 done

Restarted the lab with Vivado as WSL and virtualbox is not working for writing in system verilog and have to switch to Vivado and write in Verilog.

Spent quite a lot of time in figuring out how to diaplay the text in Vivado and how to write the testbench correctly and test all the possible values. Hopefully next week will finished exercise 3 and 4.

week 10 of 9 November 2024

Project work:

• onboarding lab 3: done

Finish lab 3 this weekend. All test run successfully in Vivado and the expected results matches the results in design file. exercise 3 is quite difficult as I don’t know how to call the function in the testbench file, so I re-written the design file in verilog so that it still follows the requirements and were able to tested it in the testbench. I still feel not very confidence with Verilog coding as every exercise in the lab 3 I need to learn something new from the internet (sometimes from gpt) to help me fix the issues in the code.

Spring 2024 Design Notebooks

• Auryn Yamamura

• Aditya Joshi

• Cameron Bedard

• Darren Kuo

• Fatima Farooq

• Geoffrey Guindine

• Rielle Lim

• James Jin

• Kevin Guo

• Joshua Cho

• Krzystof Chciuk

• Kyle Liu

• Leen Kharouf

• Michael Lippe

• Pingchuan Dong

• Uma Nachiappan

• Xingzhi Dai

Week of February 11, 2024

Project Work:

• Finished Onboarding Lab 2
• Worked on Onboarding Lab 3 - WIP

I enrolled late into the course so this is my first design notebook entry.

I got really stuck on Onboarding Lab 3: I have the general idea of how each test should be implemented but got really wrapped up in the details. I kept trying to think of ways to write my code cleaner (despite not yet having the tools to do so), which really slowed me down. I’ve also been learning how the models work through the tests written for Onboarding Lab 2, plus a lot of trial and error.

This upcoming week, I’m gonna try to finish Onboarding Lab 3 and Onboarding Lab 4. I’m not sure how much further I’ll get since I’m also quite ill right now.

Week of February 18, 2024

Project Work:

• Finished Onboarding Lab 3
• Finished Onboarding Lab 4

I finally completed all the onboarding labs. Lab 3 ended up being super tricky for me. When I got really stuck I ended up heavily referencing Michael’s completed labs - my exercise 1 is identical to his as I didn’t (and still don’t) understand if the model will allocate more bits than necessary to what we’ve defined for a input/output. However when I got to Lab 4, I took more inspiration from Vito’s code (from Lab 2) and made my solutions way more concise.

I also talked to Vito during the makeup meeting and will be joining AMBA.

Week of February 25, 2024

Project Work:

• Read Ch. 1 and Sections 5.1-5.2 of the AMBA Specs
• Started brainstorming diagram of APB Manager

I talked to Rishyak on Tuesday, and I’ve decided to work on the APB Manager. I read the “Introduction to the AMBA Buses” to learn how the AMBA buses work together in general. I asked a lot of questions about the bus signals and what “speed” meant in regards to the different buses, which ended up sparking a lot of discussion and debate in the dev channel (oopsies). I am very grateful for everyone who responded to me - I feel more comfortable with the high-impedance state and purpose of multi-driver wires. I also appreciate the Physics II review from Michael and Krzysztof.

I also read the first two sections of Ch. 5, which were about the APB manager, and drew a rough mock-up of my plans for its implementation.

I am still shaky on the timing of the data transfers, so I’m currently awaiting feedback from Rishyak.

Week of March 3, 2024

Project Work:

• None

I spent 12 hours grading E15 Turbo for CompArch, so I had no time to work on PD.

Week of March 10, 2024

Project Work:

• None

Similar to last week, I spent 10 hours grading the array reversal question early for the upcoming CompArch midterm. Was also too busy helping students prepare for said midterm.

Week of March 24, 2024

Project Work:

• Talked to Vito and Rishyak about what the APB actually does
• Redid some of the pseudocode

I talked to both Vito and Rishyak about the purpose of the APB manager and took extensive notes. Essentially the APB manager receives signals from a device using the generic interface, and its purpose is to translate those signals into APB-specific signals. Conversely, the APB subordinate’s purpose to translate those APB-specific signals back into generic. The reasons why we do these translations rather then just using the generic signals directly are:

1. Generic is slow.
2. Generic can only connect two devices, whereas AHB/APB is capable of connecting multiple devices.

My next goal is to sit down and crank out the APB Manager module whenever I have time.

Week of March 31, 2024

Project Work:

• None

Was very busy with other work (mainly CompArch related, but also I had a Japanese composition and exam due this week.). Life just sucks ass sometimes. :P

Week of April 7, 2024

Project Work:

• None

To be honest, I’ve been procrastinating real hard on the work I have to do for ProcDesign. I was frustrated with how long it was taking me to understand the APB specs on my own, and I started feeling overwhelmed by how much work I have to complete by the end of the semester (especially since I’m a three-credit student). I did talk to Vito about all of this, and have decided to sit down with him next weekend to talk about the APB Manager module.

Week of April 14, 2024

Project Work:

• Finished APB Manager module
• Wrote test bench for APB Manager module

This Saturday I sat down with Vito for four hours and cranked out the APB module. To be honest, it was much simpler than I thought it would be. I definitely feel silly in hindsight since I put it off for so long. After finishing the APB Manager module, I wrote a test bench for the APB Manager (using the test bench for the Generic Bus Manager as a template).

I wasn’t able to test it myself, so I just made a pull request. I am currently waiting to hear feedback from Rishyak on Tuesday.

Week of April 21, 2024

Project Work:

• Tried to debug test bench for APB Manager Module
• Started working on APB Sub Module

Unfortunately my test bench had some bugs (bummer) so I sat down with Vito to debug them. We didn’t get very far though since CMake was having trouble configuring my project – this was mostly due to me not updating my computer for three years (I was using macOS 11, current version is macOS 14).

While we were waiting for my computer’s package manager to finish upgrading cmake (which it took over an hour to do), Vito made me read some of the messages that popped in my terminal. I learned some new terminology, which I’ll write here:

• Dependencies are inputs (for our purposes) to Verilator, so Verilator depends on them. Thus they must be installed before we install Verilator.

• CMake Configure is the process of “setting up” our project. Our IDE creates a build folder, put a bunch of files in there, and then tells CMake to do its setup within the build folder.

• Make/Ninja: CMake doesn’t actually build any software, it just configures things. Make is build system, which is responsible for building our executable (aka compiling and linking).

• make install: During configure, the build system was told which folder we want to copy the results of the build into. The process of copying only what came our of the build step is called “installing”.

I also got to ask about the purpose of BaseAddr and AddrMask from the Generic Subordinate module, added to my APB notes. My goal for next week is to write the module for the APB subordinate, finish debugging my APB Manager test bench with Vito, and write the APB Sub test bench. (This is what I get for putting off my work all semester :P)

Week of April 28, 2024

Project Work:

• Finished debugging test bench for APB Manager
• Finished APB Sub Module
• Finished test bench for APB Sub
• Made presentation

It’s crazy, but I completely finished everything (yay!)

First off, I was still having trouble configuring my project even after updating my laptop, so I sat down with Vito this Thursday. Basically I was having trouble because at some point I downloaded Anaconda onto my computer, which completely trashed my file path and caused me to get errors about incompatible file types. We managed to amend this somewhat (my project configures now), but my filepath is still trash (Vito recommends saving the data I care abt to a hard drive and nuking my computer lmao).

After that, I was able to build my project and realized that bugs with my test bench were from direction that some of the APB signals were declared in my top level for the APB Manager test bench, as well as APBCommon_if. After fixing those, my module passed all test cases.

Secondly, I finished both the APB Sub module AND its associated test bench (pause for applause). I wrote the APB Sub module this past Sunday, and cranked out the test bench this Friday. Once again I had trouble running my test bench – this time it was because it was having trouble building. After my presentation, I sat down with Vito again who explained why I was running into my issue. He told me about how labels for functions get declared (using C and C++ as an example), and explained that I was getting errors because I was using gcc as my compiler (hence using the gcc standard library), whereas when I did brew upgrade, it used the clang standard library (which has a different implementation). Long story short, I switched to clang, compiled my test bench, and was able to run my test bench.

Finally I made slides about the work I did this semester and presented it today in front of Vito (and Geoffrey). Tbh I didn’t take it super seriously since I have little-to-no honor left about the (lack of) work I’ve done for PD. I’m glad I also went to the PD meeting this past Thursday bc

1. I learned it was totally fine to talk about our mistakes or things we learned along the way
2. I got to see everyone in in-person, including meeting Krzysztof and seeing my old student Joe Aronov.

Overall, I shouldn’t have procrastinated on the work I had to do for PD for as long as I did, but I am very happy that I made it to the finish line. These past 2-3 weeks, I’ve learned a lot about CMake, build systems, compilers, etc. I’m especially grateful to both Vito and Rishyak, who sat down with me for many hours and explained stuff to me because I can’t read (esp Vito). I hope that the stuff I’ve written this sem gets merged with the main for the AMBA repo, so I can finally have my profile on the list of contributors :D

Design notebook for Aditya Deepak Joshi (2024 Spring)

Feb. 5th - Feb. 11th, 2024

Work done

• [Design notebook task]: Was granted access to the repository and opened a pull request for this update.
• [Design notebook task]: Setup the Development Environment and created repository for Lab work
• [Design notebook task]: Worked on parts 1 and 2 of Lab 1 in repository folder here

Working comments

I decided to join the Project and learn under Prof Ratan Dey after learning about the usage of C and C++ in verification. Additionally after researching multithreading, and multiprocessing as a part of my undergraduate studies. I am currently interested in researching Hardware, Software optimizations for speeding up algorithms.

Design Notebook for Cameron Bedard

Week of Feb 5th:

• Added to the Github and read through the Course Documents and Getting Started section of the VIP website. Looked up and familiarized myself with termanology I did not know. Sought help from the team making my first pull request to create this notebook.

Week of Feb 12th:

• Started working through the Onboarding Labs. Downloaded and booted my VM from the provided OVA file.
• Worked on getting C++ wokring on my pirmary Windows OS as well. Had a error when trying to run code which led me to troubleshoot for two days before fixing a PATH issue with the compiler I installed. It was a good learning experince as far as how installing a compiler works and how VS Code works. A little futile considering all the work will be done on Linux but learned something none the less.
• Finished setting up my Linux VM and completed Lab 1.
• Started work on Lab 2.

Week of Feb 19th:

• Continued work on Lab 2. Made slow progress due to school work load. But as a consequence I have been learning about timing in a processor and how different timers are used for differnet functions in a processor.
• I started reading through the core documentation. Planning to power through the labs and join the work effort with the core team.

Darren’s Design Notebook

Week of February 2nd, 2024

Project Work

• Created Design notebook for Spring 2024

Comments

This was a good refesher of how to use git, and work with repos, and forks. Also had to spend some time getting WSL to run again after running into issues with Hyper-V on my system.

Week of February 9th, 2024

Project Work

• Completed Onboarding Lab 1

Comments

• When working on the forked repository I need to remember to create a branch first.
• Asked Vito for some basic help with fixing the mistake of not making a branch first as well as fixing a Cmake issue in Lab 1.
• Rishyak helped with locating a compiler issue which was just needing to install gcc/g++

Week of February 16th, 2024

Project Work

• Completed Exercise 1 and 2 of Onboarding Lab 2

Comments

• Worked on during weekly meeting with help of Vito
• Ran into some cmakelists.txt issues
• Refreshed a little on Verilog assign statments

Week of February 23rd, 2024

Project Work

• Finished Lab 2

Comments

• Worked with Rishyak on Exercises 3 and 4
• Refresh on Verliog always and comb blocks
• Asked Vito for help on some git and some cmake issues.

Week of March 1st, 2024

Project Work

• Started Lab 3 Exercise 1

Comments

• Asked Vito during weekly meeting about how to start writing a test for Module 1 which tested simple logic
• Ran into some issues with the for loop inside of the test
• Will make neater for loops in the future, or avoid them when possible

Week of March 8th, 2024

Project Work

• Continued Lab 3 Exercise 1

Comments

• After getting the for loops to run, there were still comparison errors with the logic of the tests
• Troubleshooting with Vito resulted in some variable declaration issues in C++
• This took way too long

Week of March 15th, 2024

Project Work

• Finished Lab 3 Exercise 1

Comments

• Commit above includes Exercise 2, I need to get in the habit of commiting more often
• Even though these labs are primarily done locally, commiting more often would allow for ease of work from multiple locations

Week of March 29th

Project Work

• Started Lab 3 Exercise 2
  • Same commit as from the previous week due to my git incompetence

Comments

• Vito gave me a quick lesson on how to get the value of a bit by shifting it and then “anding” it
  • uint16_t val = (model.out >> 0) & 1;
• Learned how to test a register without going through every possible value, rather by testing each bit of the register
• While test is running and passing, the test could be more comprehensive

Week of April 5th

Project Work

• Update ReadME for Lab 2
• Update ReadME for Lab 3

Comments

• Just needed to fill out the ReadMe for Lab 2
• While Lab 3 is still unfinished, I was able to answer part of the ReadME and thought I would update it alongside Lab 2

Week of April 12th

Project Work

• Research into what OpenRAM is
• Went through the Git Repo for OpenRAM
• Watched a video on a presentation on OpenRAM

Comments

• I never quite understood what I was looking at, other than that OpenRAM is a memory compilier, and can produce a file for SPICE simulators to use
• Stumbled upon a Cornell Grad Git page on OpenRAM simulation, showed me what OpenRAM can generate, which was quite interesting

Week of April 19th

Project Work

• Look at the AMBA repo for the AHB Doc
• Looked at some of the registers/databus information, got confused, and read some more
• Understood that the Memory communicates with the AHB subordinate

Week of April 26th

Project Work

• View End of Semester Presentations
• Work on my on presentation

Comments

• Michael’s presenation was very informative, taught me more about the VIP and the Core team

Week of May 3rd

Project Work

• End of Semester Presentation
• Brief discussion with Vito about memory, and how it communicates with the AHB using Generic

Comments

• This semester has been significantly more eventful than the last, I learned more this semester
  • Actually asking for help is good
  • I learned Verilog, Digital Logic really did not teach me much
  • While taking a Class in C this semester, it has helped me understand more of C++
  • Writing simple verification tests in C++
• Great time at the meetings with help on the labs and just great people to talk to all around
• Looking forward to next semester when I embark on my memory journey

Week of 29 January 2024

Project work:

• created the design notebook

This week, I mostly spent time wrapping my head aroud Github: froking, creating and understanding branches, commiting, pulling requests, pushing from lcoal machine to upstream

Week of 5 February 2024

Project work:

• Started lab1 on Annubis (created CMake file and implemented the hello world program)

This week, I spent most of the time figuring out the error I got when I tried to push something from my local machine to my remote github repo but I had no luck so switched to Annubis just to get started with onbaording lab1. I downloaded VS Code with Git Lens extension, and I aim to work on it when working on my local computer. I plan on finishing lab1 by next week as well as successfully setting up the devlopment enviroment on my computer(mac).

Week of 12 February 2024

Project work:

-Completed Lab 1

This week, I spent trying to overcome the error I got when trying to push from my computer to github. I finally managed to overcome it by generating and using SSH key. I also finished lab 1 and familairized myself with the format of Makefiles and build systems

Week of 19 February 2024

Project work:

-completed Lab 2

This week, I spent a lot of time revisitng verilog syntax and sequential and combinatorial concepts in Verilog. I also got introduced to the different test types and successfully completed lab 2.

Week of 26 February 2024

Project work:

-started lab 3

This week, I started with lab 3 but encountered errors as I continued working on lab3. I then spent significant time setting up the development ennviroment on my laptop. I encounterted multiple errors when running cmake but was able to resolve it through installing the required packages I then spent most of the time trying to familaize myself with the testing frame and how to utilize it to configure appropriate tests for the given verilog modules and completed exercise 1 and 2.

Week of 4 March 2024

Project work:

-continued work on lab 3

This week, I spent alot of time trying to write the test code for exercise 3 but I had a lot going on because of midterm week so was not able to complete the entire lab. I was able to complete exercise 3 but at least one of my test fails. I hope to resolve this and complete lab 3 by next week as well as start on lab4

Week of 11 March 2024

Project work:

-Completed lab 3

This week, I spent time completing lab 3 and could not do much else because I had couple of midterms this week

Week of 18 March 2024

Project work:

-None

Spring break

Week of 25 March 2024

Project work:

-Started lab 4

This week, I started with lab 4 but it took me long to progress through every step as I kept going back to reinforce what the different terminoligies referred to and what are their differences and their different uses: packages, tools and toolchains (which we learned earlier about), package manager, dependencies, registries

Week of 1 April 2024

Project work:

-Completed lab 4

This week, I completed lab 4 and was able to gain a concrete understanding of the different things meant by libraries, packages, tools and toolchains, package manager, dependencies, registries, frameworks

After completing the verification section of the lab, I read a little more on design verification through this

Week of 8 April 2024

Project work:

-completed lab 5

This week, I completed lab 5 and got introduced to as well as gained a comprehsnive overview of the different Verilog data types and modules

Week of 15 April 2024

Project work:

-Read through lab 7

This week, I just went over the skills I gained during through the onboarding labs and familized myself with teh different teams in the Design Processor team which I can potentially contribute to. I could draw a lot of connections between the learned concepts in Comp Arch and the core team but before I actually contirbute to core, I wanted to research a little more on the CPU core so that I have a stronger conceptual undertstanding of what I would be contributing to as well as fill up some missing gaps from Comp Arch.

I read about:

• Differnt components of the CPU
• Multi-core CPUs

Week of 22 April 2024

Project work:

-Worked on preparing final presentation & presented

This week, I spent time summarizing my work in the processor design team this semester in the form a presentation

Week of 2 February 2024

Project Work:

• Onboarding Lab 1: Completed Lab 1

I spent this week working on Lab 1, and I didn’t really have any issues with the lab, except for forgetting to save my VScode files. I will be continuing to work on the rest of the onboarding labs, aiming for getting 1-2 done per week.

Week of 18 February 2024

Project Work:

• Onboarding Lab 2: Completed Lab 2

I spent this week finishing up Lab 2 and trying to familiarize myself with System Verilog. I have worked with VHDL before, so I kind of understand how SV works better than I would if I didn’t use VHDL before. I also installed a System Verilog formatter, which makes coding in it a lot easier.

Week of 25 February 2024

Project Work:

• Onboarding Lab 3: Completed Lab 3

This past 10 days I was working Labs 3 and 4. I just finished up Lab 3, linked in the link above. This lab was a bit confusing at first, but eventually I started to understand. I think this is a great way to understand the Cmake toolchain, especially since I didn’t understand it too well intially. I want to practice understanding CMakeLists file more, I will do some more reading to understand that.

Week of March 3 2024

Project Work:

• Onboarding Lab 3: Completed onboarding labs

This past week I have been working on finishing all of the onboarding labs, which can be linked to the above repo containing all of my onboarding labs. The onboarding labs have been relatively straightforward, the most confusing part definitely being the toolchain configuration and how all of these tools work together. The code has been decently challenging to write, considering the lack of a proper IDE for Verilog, so having to memorize the syntax/types has been necessary for doing the labs. I also had a poor understanding of what each tool actually did, so that messed with my projects a bit. I was intially writing tests in SV, while we were supposed to be doing it in C++. I thought that vertilator made the tests for you, while it just produces a verilated module for the user to use.

Week of March 23 2024

Project Work:

• [Documentation]

Since a bit before and after spring break, I have been working on reading the documentation for the AMBA team. I am trying to figure out how to implement the memory suboordiate component, but this is proving to be a daunting task, as there is not a lot of material available through the internet. I am going to spend some more time with Rishyak trying to figure out this issue, and I am hoping that I will actually be able to write some code in the very near future. Also still reading up on docs on how SV and C++ work together through the Cmake toolchain with stuff like verilator.

Week of March 30 2024

Project Work:

• AMBA Memory Suboordinate Design: Started memory sub work

This past week I have been working on implementing a general memory suboordinate for the AMBA team. I am currently working on implementing the behavioral model, however I am having some trouble on that. Will ask Rishyak this week for some help, but I think that I got all of the control,signals down. However, that is just kind of copy and pasting from the docs, so the behavioral component will be much harder to accurately implement.

Week of April 10 2024

Project Work:

• AMBA Memory Suboordinate Design: Initial design of memory sub done

I was able to complete the memory sub work intially, however there are some issues with how I was interfacing with our current libraries, so I need to fix that. I am waiting for Rishyak to make a comment on my PR, and then I will continue with the work I am currently doing.

Week of April 17 2024

Project Work:

• AMBA Memory Suboordinate Design: Started memory sub work

I integrated the AHBCommon_if and MemCommon_if interfaces into the SubMemCtrl module, replacing direct signal definitions with these interfaces. Also I added the ahb_resp_t enum for response status signaling within the module. I think that these changes will smooth out the process of creating the rest of the design.

Rielle’s Spring 2024 Design Notebook

Week of January 29, 2024

Project Work

• Core Team Startup: Created a getting started doc to help new members navigate the repo and how to contribute to nyu core!

Comments

I’ll link the doc once the PR is merged but this week was mostly this and checking in to see if there is any finance stuff to do :) Going to have to get to know more members to decide on a junior finance person with the team soon too so there’s that. Currently now open to working on some core issues which have progressed a heck of a lot more than when I was last on here, so I’m gonna need to take some time to refamiliarize myself with the issues listed.

Week of February 5, 2024

Project Work

• Getting Started with Core: Doc refined for core startup

Comments

Made some extra changes to this doc for better coverage of info and better words.

Week of February 12, 2024

Project Work

• Dev and Test Docs: Updated the dev and test doc to implement the new changes in formatting and good practice.

Comments

I am bad at reading comprehension and only finally understood what was asked of me 4 days after assignment. Got a couple of new assignments given to me by both Michael and for some reason Rishyak to whittle down on. Currently working on updating module docs.

Week of February 19, 2024

Project Work

• Dev and Test Docs: Additional refinement for CMake file instructions and updated testing format

Week of February 26, 2024

Project Work

• Reorganized the Getting Started docs for better flow and clarity

Comments

Currently working with Uma to refresh and reword the getting started docs so that members can better understand how to navigate through the github and contribute in a more orderly fashion. Gonna get started with the general control module that Michael assigned to me once I finished midterms.

Week of March 4 - 11, 2024

Project Work

Unfortunately no work was done during this time…

Week of April 1, 2024

Project Work

• Helped Cameron navigate git and source control for the general control module
• Outlined testing module of general control module with Cameron.

Week of April 8, 2024

Project Work

• Rewrote/Reformatted Getting Started documents; Especially the document on repo navigation
• Began discussing and planning the end of semester presentation with Uma; Topics have been decided upon and outlined.

Comments

After working with Cameron last week and listening to some questions that were raised in the meeting, Uma and I devised better formatting and ideas that needed more highlighting/explanation. This will hopefully be a much better foundation for the future of the team.

Design notebook for James Jin (2024 Spring)

Feb. 5th - Feb. 11th, 2024

Work done

• [Design notebook task]: was granted access to the repository and opened a pull request for this update.

Working comments

I decided to join the processor design team after a discussion with professor Dey on my interest in a deeper understanding of computers’ mechanisms. Due to my existing committments in the CS undergraduate research course, I have decided to enroll in the VIP with zero credits to familiarize myself with the work. However, I am particularly interested in optimizations and will aim to applying my theoretical / higher-level programming knowledge. Of course, I remain open to learning new things about hardware.

Feb. 12th - Feb. 18th, 2024

Work done

• Lab 1: completed the first lab using a WSL ubuntu distribution.

Working comments

For each of the future weeks, I aim to complete at least 1 lab. At least with this 1st lab, I found my existing familiarity with some specific cmake and build tool commands allowed straightforward completion of the labs. Nevertheless, I learned the concepts of build tool, toolchain, and cmake.

Feb. 19th - Feb. 25th, 2024

Work done

• Lab 2: briefly begun lab 2

Working comments

Due to extra research duties, I couldn’t complete lab 2. Given next week’s paper deadline, lab 2 will likely be further delayed. Nevertheless, I intend to at least update my cmake installation to enable building the project. Thus, I aim to complete and test another exercise.

Feb. 26th - Mar. 3th, 2024

Work done

• Lab 2: completed lab 2

Working comments

Lab 2 is fully complete and tested. I found my memory of verilog syntax rusty, but my awareness of combinatorial vs. sequential logic is still strong. Critically, I learned the different implication of “`include” in verilog vs. in C++/C. I look forward to learning about writing tests in lab 3.

Mar. 4th - Mar. 10th, 2024

Work done

• Lab 3: completed exercise 1 (out of 4) for lab 3

Working comments

After finishing the verilog code for the modules of lab 2, I am then tasked with writing C++ testcases for such verilog. I understood and implemented the basic strategy of iterating through all input combinations, simulate output, and verifying correctness.

Mar. 11th - Mar. 17th, 2024

Work done

• Lab 3: completed exercise 2 for lab 3

Working comments

While applying similar testing strategies as the start of lab 3, I leveraged the given credibility of the existing module and only tested unique combinations of bits that affect the output. This significantly reduced the amount of test cases required.

Mar. 25th - Mar. 31st, 2024

Work done

• Lab 3: begun exercise 3 for lab 3

Working comments

Exercise 3 of lab 3 is tricky due to the impossiblity of brute-force testing all possible inputs and the complexity of the module hierarchy. I decided to implement the mystery1 module as a separate function to more efficiently simulate its two identical copies in verilog.

Apr. 1st - Apr. 7th, 2024

Work done

• Lab 3: completed exercise 3 for lab 3

Working comments

I successfully finished the test code for exercise 3 after adopting a random number generation strategy. This was feasible due to the modules only affecting bit positions instead of operating on bit values. I verified the correct behaviours of the complex hierarchy through repeated testing.

Apr. 8th - Apr. 14th, 2024

Work done

• Lab 3: completed lab 3

Working comments

For various factors such as conference paper deadline and internship search, the work done in the past month is limited to lab 3. My tasks until the semester’s end should be split between labs and instruction cache duties assigned by Michael.

Apr. 15th - Apr. 21st, 2024

Work done

• Lab 4: completed lab 4

Working comments

Lab 4 involved a relatively straightforward refactor of lab 3’s verification code using the established interfaces and macros of the processor design team and Catch2. Nevertheless, I learned the cmake commands and vcpkg configurations necessary to enable these libraries.

Apr. 22nd - Apr. 28th, 2024

Work done

• core L1 instruction cache: begun design verification for L1 instruction cache
• End of semester presentation

Working comments

Using my prior understanding of caches and verfication knowledge from this semester, I started strategizing tests for the eventually completed L1 instruction cache module. I plan to at least test for correct storage of data and the cache’s performance gain over memory.

Design Notebook for Kevin Guo (2024 Spring)

Week of 6 Feburary 2024

Project Work:

• [Design Notebook]: Design Notebook created

I learned commands in git and created my own design notebook and did my first pull request.

I should use git to commit changes instead of creating new files on github. This is not enough for most of the projects I am going to do in the team. I also put the notebook in wrong position. However, rishyak fixed them for me.

Week of 13 Feburary 2024

Project Work:

• Onboarding Lab1: Completed Lab 1.

I had trouble downloading Brew but eventually I got it from its website. I also download the github desktop, it’s very conviniennt. I had trouble building the program because I did not save it. But everything worked out fine after I figure those small things out.

Week of 20 Feburary 2024

Project Work:

• Onboarding Lab2: Completed Lab 2. All test past

I encounter two main problems. In buillding the test, I kept getting the error that system cannot find the path for Mystery 1 and 2. But then I realize not writting any include’ statement solve the problem. So the path is initially set up for us.

Another problem is that I cannot run the test. James and Vito helped me updated my brew and downloaded Verilator, then everything worked out.

Week of 1 March 2024

Project Work:

• Onboarding Lab3: Almost done with Lab3, fixing problems

I encounter problem for implementing catch2. All acutal testcase has to be ran inside test_case special function. Now I am still fixing test cases problem and refining my code. Will finish after midterm.

Week of 14 March 2024

Project Work:

• Onboarding Lab3: Almost done with Lab3, fixing problems

I kept getting 0 for my model.out command in excercise 3 dv. Vito help me figured it out that for negative edge clk trigger, I need to set clock to 1 then eval, then back to 0 and eval again to simulate this. James also helped me out with an interesting bug. For exercise 3, out has to be set using reset, or it will always be 0. So to test out, I have to write it with reset.

Week of 21 March 2024

Project Work:

• Onboarding Lab3: Finish Lab3, all test for 4 excercise passed

I spent hours of debugging, it seems like my exercise 3 does not do a correct wrap around. The expected output is always off by 1 step. James pointed out for me that the problem is that in my step function, I should set count =0, just like in reset. This problem occur again as it bothers me a lot in exercise 2. Since c++ will just set a initialized value to 1.

Week of 7 April 2024

• Project Work: Working together with the core team. Learning instruction cached verification. Trying to build L1 verification.

We are trying to mimick the previous cache verification process. We also want to simulate memory to cache write back activity.

Week of 14 April 2024

Project Work:

• Onboarding Lab4: Completed Lab 4. All test past

I encounterd one problem that verilator is not in used. Vito helped me fixed this by going into setting.json and manually set NYU_BUILD_TESTS to true. I can do it in terminal but I did it wrong.

Week of 7 February 2024

** Important to know that I have never run anything like this before ** (Was a mech-e student)

• Figuring out how to set up all the things necessary for the onboarding labs.
• Am I supposed to write the codes in the lab documents in the terminal of my computer???
• Went with writing in terminal of computer, don’t know if it worked out or not…

Week of 14 February 2024

• Nevermind, about last week. Just realized that all of these needs to be completed in VSCode. Doesn’t “need” to be in VSCode but I think it would be easiest to be accomplished in there.
• Attempting to redo all of the setting ups

Weeks 21 March 2024, 28 March 2024

• Was pretty sick during this time

Week of 7 March 2024

Setup:

• Had to redo the setup of the development. Thought that the codes in the documents were supposed to be inputted into the terminal of my computer. Finally realized that it was supposed to be in the built-in terminal in VSCode. Typical Errors that I ran into was creating the SSH and initializing the repository. Never did anything like this before and am very new to VSCode so was not sure where to put what. An error that occurred when trying to create the SSH was that I did not realize the locations of the keys. Initially, tried to use the clip command but had to search for the .ssh file instead. Also when looking for the file location, it was important to note that looking in the vscode SSH file did not give the correct key but instead, I looked for it in the Ubuntu file. There I was able to easily set up the SSH. Additionally did not realize to first write the codes within the WSL remote connection. Fixed this and the rest of the setup went smoothly. Next had to figure out how to properly initialize the repository.

Week of 14 March 2024

Lab #2:

• Working on Lab #2 (cmake). The first error that I ran into was figuring out exactly where to create the file for CML. Ended up being in the folder under Ubuntu and not the normal VSCode folder. My assumption now is to create the lab files and any necessary folders, directories, and documents in the root file in Ubuntu. After figuring this out, wrote the code directly into the CMakeLists.txt file but was able to figure out that I could just open the CML text file through VSCode and write the code there. Next, ran the code with the CML file and ran into this error:

CMake Error at CMakeLists.txt:2 (project): No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment variable “CXX” or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.

According to the internet, might need to install g++ and then set the compiler path. All I needed to do was to install g++ and code properly ran. The lab document does not include installing g++ and ninja.

Week of 21 March 2024

• Productive last week, learned a ton about the structure of VSCode, how to run things, etc. Shoutout Vito.
• Finished the rest of the lab. Have a few questions that came up during the rest of the lab. Part 2 Lab 1:
• Build at the bottom tab makes the task much simpler. After building, pressing the run or play button will execute the code.

Part 3 Lab 1:

• Created the codes for the name.cpp and name.hpp but when I ran the code, the src files were not found. Looking into this. A question I have is that after every time I edit the files or add a new file do I need to run the make command?

Lab 1 Questions: The paths used by target_sources and target_include_directories are relative, not absolute. What file or folder are they relative to?

• Great question, I don’t really know but what I can tell from the first part of the lab was that hello2 is the build file that these changes are being made to. If I do src/hello.cpp, it targets the src folder. In the first part of the lab, there was no src/ so I would assume that What are some differences between cmake and ninja?

Why is it important to run CMake in its own directory?

Week of 28 March 2024

• Began working on lab 2. Lab 2: SV Lab

• There were two different folders for writing the code, DV and RTL. This stands for Design Verification and Register Transfer Level. Was initially confused about where to write what code but after doing a bit of searching on the internet, found out what DV and RTL meant. So, came to the conclusion that I should write the code that describes how and what the hardware is going to input and output. The DV basically is testing those different codes that I write in the RTL to see if the codes meet the design specifications or standards.

• What is Zone.Identifier though?

• The pictures for all of the labs don’t load by the way so I didn’t know what to do for exercise 3

• This lab went pretty smoothly and introduced me to SV and modules within SV such as the always_ff and always_comb. I didn’t know what it meant when it said “Using an always_comb block, implement …”. always_ff stands for always flip-flop and describes the behavior of a flip-flop and is used for sequential logic. This is different from using the always block because it adds a restriction so it can only contain one event control and no blocking timing controls. always_comb stands for always combinational. This differs from always because the block automatically executes once at t=0. Additionally, there are some restrictions.

• Reflection: I should take time to learn more about SV and how to write in that language. Went through some basic functionalities using SV but since processors are a lot more complicated, I need to learn more.

Week of 4 April 2024

I worked on Lab 3: Verification and setting up my vscode again…

• After I worked on lab 2, I realized that I wasn’t properly forking the lab2_sv. I should be making it so that I can make any updates to VSCode and then be able to update it so it appears on my Github. Finally figured it out. I think I tried this about 3 times and did 3 different methods which did not work until doing this one. I first forked the repo into my own GitHub account then I then pressed the <> code icon and created a clone which I then uploaded into VSCode using this code:

git remote add

I then pushed it to the main repository(the repository that I created) using this code:

git push -u origin master

Then I basically made the repository in my GitHub account first, then I added the file using the remote add origin code. When I made any updates, I would then use git add . and then git commit -m “message” and finally git push. This would update the repo on my GitHub account to match the code that I wrote on VSCode. Pretty cool how this works.

• Compared to the previous lab, this lab did not already have the verification tests written and I had to write them myself.

Week of 11 April 2024

• Tried to add the lab 3 document into my VSCode, the remote add didn’t work. I tried it again but instead I downloaded the Zip file and added that file into my “Processor Design” folder. Then I did the git add, git commit and git push command. It worked. So now I am re-looking into what the git remote add does. I messed up at first because I didn’t realize the git remote add created a short name path for the repository. So I tried to add the name origin again but it messed it up because that already existed.

• Lab 3 was about design verification which is a job position I discovered while trying to see the different career paths for Processor Design. Honestly, pretty exciting stuff. A question about Verilator I had was that if we write code in C++ and Verilator converts it into Verilog, do people in the industry need to know Verilog?

• The task of Lab 3 was pretty straightforward, just needed to look up how to do some of the things.

Week of 18 April 2024

• This week was spent finishing up lab 4 and working on the final presentation

Week of 25 April 2024

Krzysztof’s Spring 2024 Design Notebook

Week of January 22, 2024

Project Work:

• nyu-coins repo: Created the nyu-coins repo.
• Project Management: Kept track of the general team status and individual members contributions.

Week of January 29, 2024

Project Work:

• nyu-coins: Re-created and uploaded a 3d model of a front of the coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of February 5, 2024

Project Work:

• nyu-coins: Re-created and uploaded a 3d model of a back of the spring 2023 founder coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of February 12, 2024

Project Work:

• nyu-coins: Re-created and uploaded a 3d model of a back of the fall 2023 member coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of February 19, 2024

Project Work:

• nyu-coins: Created and uploaded a 3d model of a back of the spring 2024 member coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of February 26, 2024

Project Work:

• nyu-coins: Created and uploaded a 3d model of a back of the future fall 2024 member coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of March 4, 2024

Project Work:

• nyu-coins: Created and uploaded a 3d model of a back of the future spring 2025 member coin.
• Project Management: Kept track of the general team status and individual members contributions.

Week of March 11, 2024

• nyu-coins: Converted all 3d models to STL files for 3D printing.
• Project Management: Kept track of the general team status and individual members contributions.

Week of March 25, 2024

Project Work:

• VIP fair: Manned the VIP showcase fair with Uma.
• Project Management: Kept track of the general team status and individual members contributions.

Week of April 1, 2024

Project Work:

• nyu-coins: Began the 3D printing of the coins.
• Project Management: Kept track of the general team status and individual members contributions.

Week of April 8, 2024

Project Work:

• nyu-coins: Finished the 3D printing of the coins.
• Project Management: Kept track of the general team status and individual members contributions.

Week of April 15, 2024

Project Work:

• nyu-coins: Prepared my semester required presentation.
• Project Management: Kept track of the general team status and individual members contributions.

Week of April 22, 2024

Project Work:

• nyu-coins: Gave my semester required presentation.
• Project Management: Kept track of the general team status and individual members contributions.

Week of April 29, 2024

Project Work:

• nyu-coins: Gave away the coins ro team members.
• Project Management: Kept track of the general team status and individual members contributions.

KL’s Design Notebook

Week of 22 January 2024

• This week’s work was done on creating the first design notebook and getting back into the gist of things.

Week of 29 January 2024

• Instruction cache was straigtened out and continually enhanced.
• Immersion in project objectives, focusing on optimizing instruction cache engineering for enhanced performance.
• Establishing clear communication channels and aligning understanding of project goals, emphasizing the importance of instruction cache optimization.
• Brainstorming sessions with lab members to explore innovative approaches and lay the groundwork for efficient collaboration.

Week of 5 Febuary 2024

• Conducting in-depth research on instruction cache architecture, exploring existing methodologies, and identifying areas for improvement.
• Analyzing performance metrics and benchmarking data to inform decision-making and refine project objectives.
• Collaborative discussions with lab members to evaluate research findings and prioritize strategies for instruction cache optimization.

Week of 12 Febuary 2024

• Prototyping initial instruction cache optimization concepts and design ideas to validate feasibility and functionality.
• Iterative refinement of prototypes based on feedback from lab members and preliminary testing results.
• Collaborative design sessions to finalize instruction cache architecture and layout, emphasizing efficiency and scalability.

Week of 19 Febuary 2024

• Setting up comprehensive testing frameworks and environments tailored specifically for instruction cache optimization.
• Collaboratively configuring test cases and scenarios with lab members to ensure thorough coverage of instruction cache performance.
• Integrating automated testing tools and processes to streamline testing procedures and enhance reliability.

Week of 26 Febuary 2024

• Commencing code implementation for instruction cache optimization, adhering to finalized design and specifications.
• Collaborative coding sessions with lab members to distribute tasks and maintain consistency in engineering practices.
• Regular code reviews and pair programming sessions to uphold code quality standards and foster knowledge sharing.

Week of 4 March 2024

• Collaboratively exploring novel instruction cache optimization techniques through iterative development cycles.
• Engaging in regular brainstorming sessions with lab members to innovate and refine implementation strategies.

Week of 11 March 2024

• Collaboratively orchestrating the seamless integration of instruction cache optimization modules into the existing system architecture.
• Implementing rigorous testing protocols with lab members to validate functionality and performance across diverse use cases.

Week of 18 March 2024

• Conducting collaborative deep dives into performance data with lab members to identify optimization opportunities and refine strategies.

Week of 25 March 2024

• Co-authoring comprehensive documentation detailing the journey of instruction cache optimization, from inception to implementation.
• Collaboratively crafting captivating presentations that highlight project insights, achievements, and future directions.

Week of 1 April 2024

• Leveraging GitHub for collaborative development, version control, and issue tracking.
• Iteratively refining instruction cache optimization techniques based on feedback from lab members.
• Restarting the project with renewed focus and energy, incorporating lessons learned from the initial phases.

Week of 8 April 2024

• Integrating instruction cache optimization modules into the codebase via GitHub, ensuring seamless integration.
• Implementing continuous testing practices using GitHub Actions or similar tools to maintain code quality.
• Conducting thorough testing and validation of instruction cache enhancements, iterating based on test results.

Week of 15 April 2024

• Instruction cache part 2 is being worked on

Week of 22 April 2024

• Instruction cache part 2 is being worked on.

Week of 29 April 2024

• Final Presentation!
• Helped organize the entire presentation.
• Group L1 cache had over 5 individuals!

Week of 6 May 2024

• Instruction cache part 2 is being worked on.

Week of 13 May 2024

• Instruction cache part 2 is being worked on.

Leen’s Design Notebook

Week of Feb 4 2024

• Created a Notebook
• Learned github from Rishyak

Michael’s Spring 2024 Design Notebook

Week of January 22, 2024

Project Work:

• Implemented ID Connection Module: Implemented and finished the Verilog module and Verilator tests for the ID connection module.

As this was the first week of the semester I was mostly focused on getting settled back into school but I did manage to finish the ID connection module I started at the end of last semester.

Week of January 29, 2024

Project Work:

• Fixed Branch Manager Errors: Fixed errors in the Branch Manager module and test that were overlooked due to the module’s absence from the CMake files as noted by Xingzhi.
• Changed Titles of Labs: Changed the titles of the onboarding labs from Week # to Lab # as the former naming scheme implied the labs should only be done one week at a time which is quite a slow pace, especially for some of the earlier labs.
• Updated Summary Page with Spring 2024 Design Notebooks: Updated the summary page of the website to include the new folder for the Spring 2024 design notebook entries.
• Assigned Rielle to work on Core Intro Guide: Assigned Rielle to work on a detailed introduction guideline for new members joining the Core Team which helps explain how the team works and how the core repo is structured.

The team officially spun into gear this week as new members start to work on the onboarding labs and existing members start to pick up where they left off in the fall. As such, I sent messages to existing core team members with unfinished work from the fall to check that they planned to remain with the team this semester and were good to keep working on their existing tasks. Most of the people I messaged have at this point confirmed they plan to continue their work from the fall but I am still waiting on a couple more responses which I hope to get soon.

One of the people who did respond, Xingzhi, noticed while continuing his work on the Branch Control connection module that the Branch Manager module was not included in the CMake files and that it caused several syntax errors when it was added. It quickly became clear to me that I had forgotten to add both the Branch Manager module and its test to the CMake files when I first made them so they were never properly tested. I quickly attended the CMake files and fixed the syntax errors in the Verilog code for the Branch Manager. Once I had done that it also became clear that there were errors in the Branch Manager tests where I was checking against the wrong output value for certain cases, so I fixed that issue as well. With those various fixes made the Branch Manager now worked properly and was no longer missing from the CMake files.

Since new people will be joining the team this semester, I wanted to make a few improvements to the Website repo that I had been meaning to do for a while. Namely, I wanted to finally change the onboarding lab titles from Week # to Lab # so that new members would not be encouraged to only do a single lab per week. Last semester we had a major issue where it took around half the semester for the first of the new members to finish the onboarding labs. Given that there are only 4 complete labs, as Lab 5 does not yet have an associated exercise to complete, and that a significant portion of the first lab is copy-pasting text into files, it should only take 3 to 4 weeks for new members to make their way through the labs as evidenced by how quickly people completed the labs in Spring 2023. While there are certainly more significant issues that led to the slow progress last semester which we are hoping to address this semester, at the very least we shouldn’t be actively encouraging new members to clock out for the week after they finish a single on-boarding lab by titling the labs as week numbers.

Finally, I also wanted to start work on a more detailed Core repo and team introduction document to complement our existing development and testing guidelines document. At this point, navigating the Core repo along with the associated links and projects is second nature for me, but it can be confusing for new members, especially those new to GitHub. As such, this introduction document will serve to help new members understand the layout of the Core repo and more quickly and easily find the resources they need. This is especially true for the projects associated with the repo as the Core Design and Implementation project is essential to our workflow but is hard to find and easily confused with the General Core Tasks project. Thankfully, Rielle reached out asking if there was anything she could work on and agreed to take on the tasks for creating this intro guide.

Week of February 5, 2024

Project Work:

• Outlined Top Level Connection Module: Finished the outline for the Top Level Connection Module.
• Started Updating Module Tests: Started updating the module tests to use the new format Vito described. So far I have updated the tests for the EX/MEM Latch test, MEM/WB Latch, and Program Counter.
• Reviewed Rielle’s Starter Doc PR: Reviewed the introduction document Rielle made for the Core Repo and asked her to also update the dev and test document with the new test format.

The big thing this week was the new test format Vito asked us to use. Apparently, we were not grabbing device references correctly and this was causing issues. He also presented a better testing method than random numbers in order to get consistent input range coverage. Vito updated the ALU test as an example and I have been working through all the tests to change them to the new format. It should be noted that many of the tests can be cleaned up further through consolidation of similar functions but I want to get all the tests moved over to the new format first and then we can worry about code cleanliness.

Week of February 12, 2024

Project Work:

• Continued Work on Updating Module Tests: Continued updating the module tests with the new format. This week I finished updating tests for the Branch Evaluator, Pipeline Reset Module, Branch Manager, CPU General Purpose Registers, and Branch Address Calculator.
• Reviewed and Merged Rielle’s Starter Doc PR: Had Rielle make a few more changes to the new getting started doc and existing dev and test guidelines doc and then merged the changed.
• Updated Core Links in Lab 7: Added a new link to Lab 7 that takes people to the new Core Team getting started doc.
• Merged L1 Cache PR: Confirmed that Surya will not be rejoining the team semester so merged the existing progress made on the L1 Data Cache.

I continued working through the tests this week and am now about two-thirds of the way through updating them, at least by the number of tests there are. Many of the remaining tests that need to be updated are rather complex, however, so in terms of total work I am probably closer to 50-60% through updating everything. A lot of the work involved is less about changing over the format and more so about consolidating the testing code into two or three functions so that I’m not just making a new function for each test case that is nearly identical to the other test functions except for one or two things.

In terms of other things I did this week, Rielle and I went over her pull request for the new introduction document and updates to the existing dev and test guidelines document. She was able to make all the changes I asked for in my review of the PR so I merged her changes meaning we now have a proper introduction guide to the Core Team for new members. I also finally heard back from Surya about whether he would continue his work on the data cache this semester. Unfortunately, he will not be continuing with the team but he did PR all the progress he made last semester, which includes a finished outline and module for the L1 Data Cache. With Surya gone, I do need to find someone to take over work on the data cache. If need be I can take over that responsibility, but given that this is my last semester, I would like to start having other Core Team members take on these more complex tasks so that they can get more familiar with Core as a whole and one or more of them is prepared to take over as Core Czar next semester.

Week of February 19, 2024

Project Work:

• Finished Updating Module Tests: Finished updating the remaining module tests to the new format. All existing module tests are now in the new format.
• Put L2 Data Cache On Hold: Put the development of the L2 Data Cache on hold indefinitely as our design really only needs the L1 Data Cache.
• Replaced L2 References in L1 Data Cache: Changed the variables and function names in the L1 Data Cache that were in reference to the now-on-hold L2 Data Cache to instead reference RAM.

I finally finished updating all of our existing module tests this week, and as I suspected, the remaining tests were some of the most complex and time-consuming to convert. The ID/EX Latch test proved particularly frustrating as the sheer number of full 32-bit word inputs to the module meant that it took far too long to test every combination of isolated input bits. Instead, I had to design the test cases such that we still tested each bit of each input in isolation at least once, but that only the relevant inputs for each test case had their bits fully cycled through.

This week I also had a discussion with Vito at our team meeting about the caches, specifically the L2 Data Cache. I had initially designed the data cache hierarchy to mimic that of modern CPU designs by Intel and AMD, with per core L1 and L2 and a shared L3. The L3 data cache had already been put on hold as it didn’t make much sense for our single-core design and was more of a “wouldn’t it be cool if we had this” idea than anything else. At the meeting, Vito asked why I was even planning an L2 Data Cache given our single core design. After some discussion on per-core L2 cache in current processor designs from AMD and Intel, Vito made the point that for a design as simple as ours, the L2 cache was unnecessary and just needlessly complicated implementation. Ultimately, Vito convinced me of his argument and so I put the L2 Data Cache on hold indefinitely. I also looked through Surya’s implementation of the L1 Data Cache and found a couple of outputs and functions that were meant to communicate with the now-on-hold L2 Data Cache. These were not completely useless however as they could be repurposed to communicate with the RAM rather than L2. As such, I renamed all the outputs and functions to reference RAM rather than L2.

Week of February 26, 2024

Project Work:

• Added data_mode Input and Functionality to L1 Data Cache: Added the data_mode input and its corresponding functionality to the L1 Data Cache module.
• Updated L1 Data Cache Test Bench: Updated the test bench for the L1 Data Cache to reflect the removal of the L2 Data Cache.
• Outlined Data Cache Manager: Completed the outline for the Data Cache Manager Module.
• Impletented the Module and Test for the Data Cache Manager: Implemented the Verilog module and Verilator test for the Data Cache Manager module and ensured full functionality.
• Reviewed and Commented on Xingzhi’s PR for the Branch Control Connection Module: Reviewed and commented on Xingzhi’s PR for the Branch Control Connection Module implementation and tests with the goal of tracking down and fixing test failures he was having.
• Assigned Rielle to Implement the General Control Module: Reassigned the task of implementing the General Control Module to Rielle.

My main focus this week was on the Data Cache related modules. The first thing I had to do was implement the data_mode functionality into the L1 Cache. The data_mode input specifies whether we are writing to the least significant byte, least significant half, or the entire word at some address in memory. With Surya gone I had to spend a significant amount of time reverse-engineering how his cache implementation worked in order to figure out what parts I needed to modify to implement the required functionality. I was able to get a fairly good idea of how his design worked and believe I was able to modify all the relevant areas; however, I can’t truly know if I made all the required changes without completing the corresponding test for the L1 Data Cache. Surya had tested the L1 Data Cache using a test bench which I would ultimately need to remake into a Verilator C++ test. To make it easier to take the test bench logic and use it for a Verilator C++ test, I modified the existing test bench to remove references to the now-defunct L2 Data Cache and instead simulate calls to RAM. The changes made to the test bench should make it easier to determine the logic used in each of the tests and so allow me to implement the same logic into the Verilator test instead of having to do everything from scratch. For now, I decided to hold off on making the L1 Data Cache test, but with the I/O of the L1 Data Cache finalized for all intents and purposes, I decided to turn my attention to the Data Cache Manager. After asking the AMBA team about the format for memory access and reading over their Generic Bus interface, I was able to complete the outline of the Data Cache Manager fairly quickly. Since the module’s logic is purely combinational, implementing and testing it was rather simple.

I also learned this week that the person I had assigned to implement the general control module is no longer on the team since they missed the add/drop deadline to officially rejoin the team this semester. Normally, this wouldn’t present much of an issue as the project’s open-source nature but I have yet to get a response from them since the add/drop deadline. As such, I reached out to Rielle about taking over the responsibility of implementing the general control module. She ultimately agreed although she expressed a desire to work on it with a partner. Once the current batch of new students finish the onboarding labs and start to join teams I would like to assign one of them to help Rielle with the module considering it is rather complex. A similar situation occurred with one of the two people I had assigned to work on the Instruction Cache, so that is another position that needs to be filled by a new team member.

Week of March 4, 2024

Project Work:

• Finished Data Cache Connection Module Outline: Finished the Outline for the Data Cache Connection Module by including the I/O lines used to communicate with AMBA for memory access.
• Updated CPU Diagram with New Data Cache Connection Module I/O: Updated the CPU Diagram to reflect the I/O lines added to the Data Cache Connection Module to communicate with AMBA. Also updated the names of some I/O lines to reflect the updated names used by the Cache Connection Module.
• Updated the MEM Connection Module Outline with New Data Cache Connection Module I/O: Updated the outline for the MEM Connection Module to reflect the new AMBA communication I/O lines added to the Data Cache Connection Module.
• Updated the Top Module Connection Module Outline with New Data Cache Connection Module I/O: Updated the outline for the Top Module to reflect the new I/O lines added to the Data Cache Connection Module.
• Fixed Errors in Branch Manager Test: Fixed errors in the Branch Manager Module test that were preventing full coverage and resulted in test failures when changes were made to ensure full coverage.
• Merged Xingzhi’s PR for the Branching Control Connection Module: After helping to fix the errors in Xingzhi’s tests for the Branching Control Connection Module I merged his PR for the Connection Module and its test.
• Started Work on the L1 Data Cache Test: Start work on designing and implementing the Verilator test for the L1 Data Cache. I am reusing much of the testing logic from Surya’s testbench but I am further refining it and then translating it into a Verilator test.

I continued my work on the Data Cache-related modules this week. Since the previous outline of the Data Cache Connection Module did not account for the I/O lines used to communicate with AMBA for memory access, the outline for the Data Cache Connection Module, the MEM Connection Module, and the Top Level Connection Module all had to be updated to include the new I/O lines. These changes also meant I had to update the CPU block diagram with the new I/O lines. With the outlines updated, I started work on the test for the L1 Data Cache. I am basing my test off of Surya’s existing testbench but will be streamlining and refining the logic as I translate it into a Verilator test in C++.

In the course of my work this week I noticed that the codecov score for the Core Repo had dropped below 90% and tried to find the cause of the issue. It turns out that the loop for the pred_taken input was set to stop when pred_taken was 0 since I forgot to add the rest of the end condition. Since pred_taken started at 0, this meant that the test was never actually running which explained why the codecov score for that module was so low. Fixing the mistake, however, revealed another issue where I had set the npc variable to be a bool instead of an unsigned integer, meaning that any value greater than one was getting truncated to 1 and causing the test check to fail. I was able to diagnose and fix the test issues and the branch manager is now tested properly with much better codecov coverage.

It occured to me that the issues I was having with the branch manager tests might explain part of wht Xingzhi’s tests for the Branching Control Connection Module were failing despite him making all the changes I had suggested last week. I quickly let him know about the issue and found in the branch manager test and how to fix it for his test. After that, his test worked successfully and I was able to merge his PR meaning another module has now been implemented. With his work on the Branching Control Connection Module complete, I assigned him to help Kyle with the instruction cache related modules.

Week of March 11, 2024

Project Work:

• Continued Work on the L1 Data Cache Test: Continued work on the Verilator test for the L1 Data Cache.

This week I continued working on the test for the L1 Data Cache. This task has ended up being far more complex than I expected since I have to both reverse engineer Surya’s L1 Cache Verilog code and translate and augment his existing testbench logic into a fully-fledged C++ test. Because of how complex the cache is, I have found the best way to approach testing is to make a C++ cache object that simulates the expected behavior of the Verilog Cache Module and then compare the simulated cache with the module to ensure the module behaves as expected. At this point I have the first draft of the cache object implemented and need to finish the test functions so I can ensure both the test and the cache work as expected.

Week of March 25, 2024

Project Work:

• Continued Work on the L1 Data Cache Test: Continued work on the test for the L1 Data Cache.
• Updated Instruction Cache Related Outlines: Updated the outlines of modules related to the instruction cache to have the needed I/O to communicate with memory.
• Updated CPU Diagram with Instruction Cache Memory IO: Updated the CPU block diagram to add the necessary I/O to the instruction cache for communicating with memory.

Coming back from spring break I continued working on the test for the L1 Data Cache. The first iteration of the test is nearly complete but I fear I will end up having to rewrite significant portions of the L1 Data Cache module itself as it is currently set up as an FSM that transitions between states each clock cycle, whereas I need it to always be up to date every clock cycle since the data cache may be written to or read from every clock cycle. I also added some of the needed I/O lines to the instruction cache outlines that are needed to communicate with memory through AMBA.

Week of April 1, 2024

Project Work:

• Continued Work on L1 Data Cache and Test: Finished a first draft of the C++ test for the L1 Data Cache and fixed various data width mix-matches in the L1 Data Cache Verilog Module.
• Merged Uma and Rielle’s PR for Reorganization of the Getting Started Folder: Uma and Rielle asked me to merge their PR since it had been approved by Rishyak but he yet to merge it.
• Fixed Website Linking Issues: Fixed website linking issues that were created when Uma and Rielle’s PR was merged.

This week I finished the first draft of the L1 Data Cache test but when I went to run it I noticed that there were various data width conflicts and other errors in the Verilog Module. As such, I spent a good chunk of this week just going over the Verilog module and fixing all the errors. I have now gotten the test and module to a point where they will run on the GitHub simulation but the test is not producing the expected results so that will need more debugging. Unfortunately, I ran into a Verilator issue trying to run the test on my computer, preventing me from debugging. I talked to Vito about the issue during the weekly team meeting and he ultimately came to the conclusion that the issue is somewhere in the toolchain and not with my setup specifically. Unfortunately, this means that locating and fixing the bug will take some time.

Week of April 8, 2024

Project Work:

• Updated General Purpose Registers to Use rstn_h Reset Line: Updated the General Purpose Registers and the connection modules containing them so that the Registers use the primary rstn_h reset line rather than the rstn line so that the register data is not reset after a pipeline flush.
• Updated CPU Diagram with rstn_h Changes: Updated the CPU diagram to reflect the changes made to the General Purpose Registers module with regards to rstn_h.

Work on the Data Cache has stalled while I wait for Vito to figure out what in the toolchain is causing the errors I am encountering. I tried various things to fix the issue on my end such as switching compilers from Clang to GCC and forcing the use of different C++ versions but nothing solved the problem. As such I spent most of this week working on my report and presentation for the end of the semester. In doing so I realized that I had forgotten to update the CPU registers to use the rstn_h reset line and so I made those changes. I also talked to both Cameron and Xingzhi about jointly taking over the Core Czar role next semester which they seemed inclined to do.

Week of April 15, 2024

Project Work:

• Added Read After Write Hazard Detection to the General Control Module: Modified the hazard detection logic in the General Control Module to detected Read after Write Hazards.
• Updated the Workflow file: Updated the main.yaml workflow file to the latest version from the template repo.
• Updated DV CMake File to Enable Tracing to fix Verilator Issue: An update to Verilator make it so traces are always generated even if they are not explicitly enabled, resulting in our workflow crashing. As a temporary fix, I enabled tracing in the Core Repo.

We ran into another issue with Verilator this week that was caused by a recent update to Verilator that has it generate trace methods even when tracing is disabled, causing our workflow to crash. Vito created an issue on the Verilator repo but in the meantime, I have enabled tracing for the core repo to prevent the crash.

I also continued work on my presentation and report, and in working on them I realized that I had forgotten to add read after write hazard detection to the hazard detection logic so I fixed that.

Week of April 22, 2024

As the semester is wrapping up I spent most of my time this week finishing on my presentation which I gave Thursday as well as working on my report. Both the presentation and report should serve as detailed guides to the core design for Cameron and Xingzhi and help them run the Core team next semester.

The issue preventing me from building the repo and debugging the L1 Data Cache test is still no fixed and neither I nor Vito are any closer to finding a solution to it, as such the L1 Data Cache development has stalled.

Week of April 29, 2024

Project Work:

• Merged L1 Data Cache PR: Merged the improvements I made to the L1 Data Cache and the current draft of its test.
• Fixed Con_ID Tests Not Running: Fixed an issue where the Con_ID tests were not running since the CMake files had not been updated to include them.
• Optimized Core Tests to Run Faster: Made various changes and optimizations to the tests to bring the GitHub run time down from 4 hours to 30 minutes.

We finally figured out the Verilator issue with has_virtual_destructor, turns out they forgot to <type_traits>, so I had Vito walk me through manually modifying my Verilator installation to add the missing include. I then spent a good chunk of time trying to shard the core tests so they could run multithreaded only for Vito to tell me that I could just run ctest -j [number of threads] which was much simpler. Once that was figured out, I went through the various core tests and optimized them to reduce run time. I was able to get the test time on GitHub down from 4 hours to 30 minutes, and just a couple of minutes locally.

This will be my last design notebook entry as I am graduating, so I merged my changes to the L1 Data Cache and its test. I still plan to continue work on the core but at a much less frequent pace; I also plan to continue to be available in the Discord to help people and guide Camereon and Xingzhi through taking over the Core Czar role.

Pingchuan’s Spring 2024 Design Notebook

Feb. 5th - Feb. 11th

Work

• [AMBA] Writing the testbench for the AHB decoder

Comments

I met some difficulties trying to compile the testbench. After consulting Rishyak, I updated some of my packages and was able to get the executable. The tests weren’t successful so I’m trying to debug.

Feb. 12th - Feb. 18th

Work

• [AMBA] Fixing the testbench and the decoder

Comments

I was able to fix through the testbench with the help from Rishyak, got rid of some unnecessary lines of code and replaced them with more concise functions provided by nyu-util such as nyu::reset() and nyu::tick(). I’m currently fixing some bugs with the address calculation in the AHB Simple Decoder module.

Feb. 19th - Feb. 25th

Work

• [AMBA] Fixing the testbench and the decoder
• Readig AMBA specs for designing the AHB-APB bridge

Comments

Turns out that the problem with the decoder testbench was defect on ahb.addr instead of implementation of SimpleDecoder.sv, reported the problem to Rishyak. I’m currently reading the APB file and AMBA spec file to design the AHB-APB bridge.

Feb. 26th - Mar. 3th

Work

• [AMBA] Reading AMBA specs for deesigning the AHB-APB bridge

Comments

Still reading the specs.

Mar. 4th - Mar. 10th

Work

• [AMBA] Encountered trouble while reading the writing and reading procedures in interfacing between AHB and APB. Consulted Rishyak and Vito about the concepts, problem solved.

Comments

The similarity between reading and writing procedures is that they both include an INITIATE, SETUP, and ENABLE phase, which is what I’m aiming to implement.

Mar. 11th - Mar. 17th

Work

• Overwhelmed by midterm exams, didn’t do much work.

Mar. 18th - Mar. 24th

Work

• Spring break.

Mar. 25th - Apr. 1st

Work

• [AMBA] I started with a basic outline on designing the bridge with a state machine. Having IDLE, SETUP, and ENABLE states.

Comments

The state machine design accords with my outline.

Apr. 2nd - Apr. 8th

Work

• This week, I was held off by OS midterm, and continued to write the AHB-APB bridge; the write operation is almost complete, and I think the read operation will be very similar.

Comments

I am determined to finish the bridge by next week.

Apr. 9th - Apr. 16th

Work

• This week, I finished the module for AHB-APB bridge, and sent it to Rishyak for review.

Apr. 17th - Apr. 23rd

Work

• I had severe acid reflux and couldn’t get out of bed. Begining to recover.

Apr. 24th - Apr. 30th

Work

• This week I presented my semester progress, it was mainly about the SimpleDecoder testbench and the bridge.

Comments

I think I still need to revise my code for the bridge, and maybe write a testbench for it.

May. 1st - May 7th

Work

• No work has been done, I am focusing on my exams and final projects, and will be doing so till the end of term.

Uma Nachiappan’s Design Notebook

A confused Doc Czar and her Processor Designing adventures…

Week of 12 February 2024

Project Work:

• Documentation Revision: Outlined

After a month without motivation, I started reorganizing the Getting Started docs, since the team came to a realization that it was kind of out of order. Currently mostly outlined but need to commit and rewrite some of the git info. Need to restart core work (both development and some documentation issues from last semester, sorry Michael).

Week of 19 February 2024

Project Work:

• Documentation Revision: Outlined Part two

Rielle and I re-outlined the structure of the docs and delegated which pages we are going to edit/rewrite. Currently waiting on Rielle to reorganize the files themselves and merge that change before we start writing so we won’t deal with weird merge conflicts later. I also learned that we are no longer using interfaces in core, so the docs need Connection Module instructions instead of interface instructions. Also need to figure out what is going in the core wiki (I think it’s everything? but need to check with Michael).

Week of 31/1/2024

Project Work:

• con_branching_control: building test

Week of 6/2/2024

Project Work:

• con_branching_control: building test

Week of 7/3/2024

Finish Project Work:

• con_branching_control: building test

Week of 15/3/2024

Project Work:

• instructions cache: instructions cache

Week of 22/3/2024

Project Work:

• instructions cache: instructions cache

Week of 1/4/2024

Project Work:

• instructions cache: instructions cache

Week of 15/4/2024

presentation

Week of 22/4/2024

presentation

Fall 2023 Design Notebooks

• Auryn Yamamura

• Aneesh Maganti

• Carlos Perez-Guzman

• Suryachandra Malleswarapu

• Rielle Lim

• Krzystof Chciuk

• Kevin Yap

• Kyle Liu

• Michael Lippe

• Vito Gamberini

• Nathaniel Sehati

• Pingchuan Dong

• Qihang Wu

• Rishyak Panchal

• Thu Vu

• Uma Nachiappan

• Xingzhi Dai

Week of September 11, 2023

Project Work:

• Read up on GitHub functionality (mainly Repos, Branches, Forks, and Pull Requests)
• Created first design notebook entry

Admittedly I won’t have much time this semester, so my goal is to at least complete the onboarding labs. I aim to start (and ideally complete) Onboarding Lab 1 by the end of next week.

Week of September 25, 2023

Project Work:

• Started Onboarding Lab 1 in Anubis (don’t know how to link it yet)
• I made my first CML file using Anubis, and got “Hello World” to print in the terminal.

I created a folder for my onboarding labs in my personal copy before realizing that wasn’t what I was supposed to do. Got slightly overwhelmed trying to figure out how to delete it - I feel like a toddler. Currently trying to find a good YT series to walk me through the baby steps of GitHub. Also still don’t how to directly link my work in Anubis to the Github repository, will ask Vito about it this Tuesday.\

For this upcoming week, I want to finish Onboarding Lab 1. This week, I didn’t make the stupid mistake of grading multiple homework problems so hopefully I’ll have time.

Week of October 2, 2023

Project Work:

• Finished Onboarding Lab 1

I finally finished Onboarding Lab 1! I had to go to Rishyak and Vito’s office hours to wrap my head around GitHub, git, the whole shebang. I also downloaded VSCode which has improved my life significantly. Unfortunately I don’t think I’ll be able to start the next lab for a while since I’ll be super busy with dogsitting, midterms, and homework for Scientific Computing (T ^ T) . I’m hoping to get enough free time to finish Onboarding Lab 2 after my PDEs midterm on Oct 19th.

Week of October 9, 2023

Project Work:

• N/A

I accidentally deleted this entry because I realized I hadn’t gone through all the steps to merge it with upstream, oopsies. Anyways I was too busy with dogsitting so I didn’t get any work done this week. Next week I’ll have a ton of midterms, so I don’t anticipate being able to complete much.

(Side note: while I was napping the dog I watching pulled my coat off a chair into his crate and was chewing on it. He completely wrecked my headphone dongle, but I couldn’t help but think it was a little cute.)

Week of October 16, 2023

Project Work:

• Read about early processors developed by Intel in the 1970s
• Read about components of MCS-4

In 1971, Intel 4004 was the first 4-bit microprocessor chip and released it as part of a package called MCS-4 (Micro Computing System - 4 bit). MCS-4 consisted of the following:

• (4001): 2048-bit ROM (256 8-bit instructions) with a 4-bit programmable I/O port
• (4002): 4-registers x 20-locations x 4-bit RAM data memory (80 4-bit data words) with a 4-bit output port
• (4003): 10-bit parallel output shift registers
• (4004): 4-bit CPU chip

Staring at the diagram of Intel 4004 registers reminds me a lot of E15/E20 from Computer Architecture. That being said I have no idea what ths address call stack is, nor do I understand shift registers (and if they have any difference from the registers we cover in CompArch). For next week, I want to read up more on both of these things so I can better understand their significance to Processor Design.

Week of October 23, 2023

Project Work:

• Watched video on flip-flops at 1.5x speed

Notes on Flip-Flops:

Flip-flops are sequential logic devices; can use data from current and previous inputs/outputs. Terminology interchangable w/ “latch” (?)

SR Flip-Flop:

• SR = “Set-Reset”, outputs are Q and ~Q.
• SR Active-High: uses two NOR gates for implementation. Inputs generally low and considered “active” when inputs are high -> (think always @ posedge from Verilog) Once set == 1, Q is set to 1 until reset == 0.
• SR Active-Low: uses two nand gates for implementation (reverse of Active-High).
• Gated SR Flip-Flop: Two input and gates are added, with second inputs being enable. enable must be set for Q to be changed.

D-Type & JK Flip-Flops:

• Have additional input pin for clock signal (clk), allows flip-flop to be triggered according to clock signal (think sequential circuit).
• D-Type: Has data input, clk acts like enable pin for this.
  • If data signal goes high, then next clock cycle Q is set to 1 (vice versa for data signal going low).
  • set and reset now asynchronous -> can affect outputs Q and ~Q at any time. If both are active at the same time, flip-flop enters an invalid state -> outputs are unpredictable (BAD!)
• JK:
  • J ~ set; K ~ reset.
  • 2-input and gates swapped with 3-input nand gates. Since third input of nand gate connected to opposing output, invalid state eliminated.

It was interesting to learn about how sequential circuits are implemented using flip-flops, which heavily rely on logic gates. Back in CompArch, logic gates were used to transition into Verilog, but felt kinda divorced from the subject as a whole. Seeing how circuits diagrams are thoroughly planned using logic gates was a really cool connection for me. I’m curious to see if the Core team has any circuit diagrams that use logic gates.

Week of October 30, 2023

Project Work:

• Read about x86 call stack from Sruthi K’s “Cracking Assembly” series
• Talked to Vito about call stack implementation in x86

The call stack is a data structure used to store . In x86, the ESP points to last item added on the stack, EBP. Removing addresses from the stack, through the ret or pop instructions, can imply that we are exiting a function call and are returning.

In terms of Processor Design, this doesn’t apply since it’s an OS topic. I think designating some registers to be used to possibly keep track of a call stack would be useful if we wanted our CPU to be capable of recursive or multiple nestings of function calls.

Week of November 6, 2023

Project Work:

• Watched video on Shift Registers

Notes on Shift Registers:

Shift Register:

• Sequential logic device that can store multi-bit inputs from one or more inputs, and transfer that data to one or more outputs.
• Flip-Flops/Latches used to make stages; # of stages = # of bits
• Like flip-flops, shift registers also have some memory: a stage’s output latch is connected to the next stage’s input latch. Each internal flip-flop connected to external clock pin (clk).
• Flip-flops’ inputs only change outputs on next clock cycle (rising edge for active-high circuits). Value of bit stored in one flip-flop will shift to the next each clock cycle.
  • ex. In 4-bit shift register, takes four clock cycles to move single bit of data across all flip-flops

Modes of Shift Registers:

• Data either output in parallel or series (getting flashbacks to EM lol).
  • Series: Bits are processed one-by-one; requires only one input/output.
  • Parallel: Multiple bits are processed simultaneously; requires multiple inputs/outputs for each bit.
• Most chips are capable of 2 out of 4 modes:
  • Series in Parallel Out (SIPO) - One input, multiple outputs
  • Series in Series Out (SISO) - One input, one output
  • Parallel in Series Out (PISO) - Multiple inputs, one output
  • Parallel in Parallel Out (PIPO) - Multiple inputs, multiple outputs
• While clk is often used as steady pulse (like metronome), for shift registers it is used like an enable pin -> Data gets selectively shifted from inputs to outputs
• Most shift registers do left-to-right shifts (S0); Universal Shift registers have additional serial input so they can do right-to-left shifts (S1).
  • S0 == 1: DSR input enabled => any data input at DSR shifted left to right (serial).
  • S1 == 1: DSL input enabled => any data input at DSL shifted right to left (serial).
  • S0 & S1 == 1: D0, D1, D2, D3 inputs enabled => data shifted to corresponding outputs Q0, Q1, Q2, Q3 (parallel).

Some shift registers have two clock pins: one for the shift register and one for a storage register.

• Shift-clock acts like traditional pulse, has enable for outputs (must be low for any output to be enabled) -> clk for inputs
• Storage-clock acts like enable -> when storage-pulse is active, data is shifted in parallel to outputs -> clk for outputs

Even though I’m interested in software, I wanted to watch another video on the hardware implementation of chip design. I did this so I could further fill in the blanks between the early topics covered in CompArch. Also bit-shifts became one of my favorite topics this semester (after I spent nine hours grading homework problems for them lol), so it was cool to start getting an idea how they physically occur in the hardware. It was also cool to start seeing the connections to the single-cycle and multi-cycle implementations of E20. I wonder what the pros/cons of each mode are, and which ones are going to be implemented in the processor we’re building?

Week of November 13, 2023

Project Work:

• N/A

Had a Stats midterm and needed to grade projects, so I wasn’t able to get any work done this week. Will try to attempt onboarding lab 2 over Thanksgiving.

Week of November 20, 2023

• Reviewed methods to maintain Cache Coherancy (mainly bus snooping)
• Researched all lingo used in “Thrashing the snoopy bus”
• Read about False Sharing

I saw that the Core team was working on Caches and thought about a silly phrase Vito said in a previous recitation. I had heard of thrashing in the context of virtual memory back in CompArch (i.e. computer performance degrading due to frequent page swaps between physical memory and disk, which is meant to handle physical memory being overcommitted). I didn’t realize it could also apply to coherent (multiprocessor) caching as well.

After reading the wikipedia article on ‘False Sharing’, I thought would have been cool to take Distributive Systems with Jepst as my last CS elective,,, alas t’wasn’t meant to be.

Week of November 27, 2023

Project Work:

• Read basics of RTL code in Processor Design
• Skimmed the article for Verilator on Wikipedia
• Played Rishyak’s infuriating Virtual Memory game

I had a lot of work to do coming back from Thanksgiving so I just read a couple of short articles. I tend to get psyched out by terminology/tools I haven’t seen before so I wanted to get myself used to before doing the labs. I imagine that the ProcDesign frequently uses Verilator to double check the logic written for a circuit in C++. I originally joined the team to work on software, so I imagine this will be a tool I see frequently in the future.

Week of December 4, 2023

Project Work:

• N/A

I didn’t have any time this week because I had to actually study up on the x86 stack and also I was grading simcache projects. BTW students truly do suck at coding lmao ( T T)

Week of December 11, 2023

Project Work:

• N/A

I won’t anything this week since I have a paper due this week and finals. If I’m still on the team next semester, I’ll try to finish all the onboarding labs ASAP.

Aneesh’s Design Notebook

December 13th, 2023:

This will be my last entry for the semester; I will continue my research on the RISC-V architecture and how to integrate different components into our reimplmenetation; hopefully the RISC simulator will be done next semester so I can look into integrating the other components onto it.

December 8th, 2023:

I had a meeting with the main Core team - limited applicability to my specific work but useful to get a better understanding of the overall architecture.

November 29th, 2023:

Needed to scrap previous work since I know am working on the componentry that assists the simulator - in other words, continuing the research that I started on November 10th.

November 22nd, 2023:

Doing more research into the different componetry to be added to the simulator, still very WIP.

November 10th, 2023:

Looking into different componentry to be added - including “the memory model, input/output device models, ELF loader, etc” to work with the C++ Verilator models.

October 30th, 2023:

Currently waiting for RISC-V simulator to be developed - according to Vito Gamberini, “RISC-V32I is a fixed length instruction set with 47 instructions. It’s like 200 lines of code to write the CPU simulation in software. That’s the smallest part of this”.

October 23rd, 2023:

Project Work:

• Finished all labs

From here, I will now do research to see what I want to delve more deeply into; I’m leaning towards the simulators.

October 9th, 2023:

Project Work:

• Finished Lab 3 here
• Progress on Lab 4 here

I fixed this branch such that the changes are made on a separate working branch. I’m almost done with lab 4 now which is good; I also talked in the Discord earlier today on how I would continue on the project after I finish the labs.

September 30th, 2023:

Project Work:

• Started Lab 3 here

I started working through the exercises and was making progress on the second part; however, I wasn’t sure how to use the testing framework properly with the second test so I stopped for now. I’ll try to make progress on the rest of this lab throughout this week

September 24th, 2023:

Project Work:

• Did Lab 2 here

I brushed up on some basic verilog and was able to build the project. I then worked on this weeks lab (sometimes peeking at the implementations done by Siddharth and Nicky if I got stuck) and was able to pass all test cases. Note that I plan on shifting my processor design work to be done on the weekend for the rest of the semester.

September 18th, 2023:

Project Work:

• Set up GitHub fork to work on projects and submit pull requests
• Did Lab 1 here

I got my GitHub repo set up and worked on setting up my development environment. I also got through the first lab. I plan on getting through the rest of them throughout this week.

Carlos’s Design Notebook

Hello, my name is Carlos and this is my first design notebook.

I am a transfer sophomore pursuing a computer engineering major. Thank you for bringing me onboard this VIP group.

Week 1 (Sept. 11 - Sept.17)

Tasks:

• Onboarding Lab 1: Completed Lab 1

I spent this week working on the onboarding lab 1 which help me familiarize myself with the concept of the toolchain and its purposes as well as the structure of CMake and build systems.

As someone who has had minimal interaction with git and GitHub, I need to get accustomed to and improve my understanding of git and GitHub, so Thursday night I spent getting help from Rishyak and making my design_notebook, as well as practicing how to make repos, branches, forks, and the other basic of git and GitHub.

Week 2 (Sept. 18 - Sept. 24)

Tasks:

• Onboarding Lab 2: Completed Lab 2

Throughout the weekend I worked on the onboarding lab 2 and familiarized myself with Verilog.

Over spring 2023, I took Digital Logic and Computer Systems at my old university where I learned how to use VHDL, however I did not continue using those skills throughout the summer so this lab really helped me regain some of the proficiency I had. I still had trouble learning the syntax and logic behind Verilog, and I still have to learn more to be able to actually contribute to this team, but this lab helped me take my first step.

Suriya’s Design Notebook

Week: Sep.10 - Sep.16 /2023

work:

• completed lab1 onBoardingLab1
• completed lab2 onBoardinglab2

comments:

• already had the WSL on my laptop so installing the required softwares wasn’t a hassle.
• had the github for long but never worked on team, so looking forward to it.
• cmake was new for me, did take some time to install and get to know the stuff.
• the answers for the exercise are in Readme.md files of the respective labs
• had to look up LFSR, did some problems on it previously. Everything else is straight Forward brushing up basics.
• completed the verification and encounterd a problem in exercise 2, rectified it.
• starting on verification.

Week: Sep.17 - Sep.23/2023

Work:

• worked on lab3, not attaching the link yet

comments:

• completed exercise 1,2 working on 3 and 4
• in next week will complete the lab3 and maybe 4 too
• researching on teams

Week: Sep.24 - Oct.1/2023

Work:

• Completed lab3 lab3

Comments:

• brushed upon C++; working on lab4
• researching on which to join after the onboarding labs.
• encountered a build issue, cleared it

Week: Oct.2 - Oct.8/2023

Work:

• Completed lab4onboarding-lab-4

comments:

• got to use some macros from catch2 dependecny
• got hang of how all the packages work in the onboarding labs that we did
• doing somemore work on them to get good hang of it.
• planning on joining core team
• don’t know the process but will text in the group.

Week: Oct.9 - Oct.15/2023

comments:

• completed the onboardingLabs
• revised the RV32 from ComputerOrganization&Design textbook.
• worked on some modules and tried to implement a singlecycledatapath version of rv32
• completed the design of the moudles, excpet topModuleWrapper and testbenches
• will contact the core czar and start work on the assigned work

Week: Oct.16 - Oct.23/2023

Work:

• got assigned to cache design

comments:

• started working on it, after L1, will continue with others,
• had the midterms couldn’t work on it good,
• will complete this week

Weeks: Oct.23 - Nov.5/2023

Work:

• completed the L1_data_cache documentation.
• implemented the L1_data_cache module upto write and read hits
• misses should be implemeted

comments:

• no specifications for tha cache were there, so chose typical
• write back, with write allocate and write through cache
• LRU replacement policy, only implemented in L1, brainstorming on how to do the L2
• opened a PR, and micheal gave some suggestions,
• going to work on them and inorder to test the module i have complete datapath
• haven’t worked with heirarchy caches so looking for resources

Weeks: Nov.6 - Nov.18/2023

Work:

• Coded the typical version of a L1 cache,
• tested the l1 module with a L2 simulation of different parameters

Comments:

• should look for better way to test this module
• and also this was implemented using registers directly
• for simulating representing this in regsiters is good enough but SRAMs should be preferred
• once testing is done will implement the SRAM version

Weeks: Nov.19 - Dec.2/2023

Work:

• testing is successful for L1, tested for 2 types of various sets and LRU counter
• need to implement ECC and improve the block size to reduce the miss rate

Comments:

• tested with the same L2 simulation module, need to improve that. looking for various options
• implemented the SRAM version, testing will be completed in 3 days, after that i will PR it
• and look for suggestions in the similar way i am coding L2 with 4 way
• havent tested for miss rate and penatly, need to check them and use optimization techniques as per the req.

Weeks: Dec.3 - Dec.17/2023

Work:

• completed the testing for L1 Module, and started on L2
• updated the documentation for overview and structural overview
• made some changes to the module and tb for PR

comments:

• as i was not comfortable in c++, i used sv for testing and after the testing is completed i started to convert it into c++, but i confirmed with michael and he’s fine with any testing as long its good.
• Created Pull requests for all the work today and messaged micheal about this.
• have 3 exams back to back so completely packed that why creating PR today.

Rielle’s Design Notebook

This is Rielle, finance czar and chequebook person.

If you ever need to find me on campus, look for the short Asian with a pink cane.

Week of September 10, 2023

Project Work

• Filled out Rising Violets forms to get extra money (maybe) and sent follow-up emails to Sam to figure out what in heck is happening with monthly meetings (still pending response…)

Comments

Taking note that this will be a super McFkn busy sem for me as leadership of another club and a having part-time job, I’m going to put a lot of upcoming deadlines directly in this notebook so in the event that I forget to tell anyone verbally we won’t just miss important dates :)

With that said, the budget forms are due 9/20 and thus I need to follow up on that sometime this upcoming week

This coming week I’m also going to try to resume core work and not just be a finance person that contributes nothing else :p

Week of September 17, 2023

Project Work

• Reviewed a bit of core to remember wth I’m doing bc I swear brain cells died over the summer. Will begin to make time to complete Core implementation for the branch address calculator :) (sorry for the wait Michael sob)

Week of September 24, 2023

Project Work

• Finished writing test cases for branch address calculator
• Looking to write the rtl part of this this coming week and maybe taking another core module

Comments

Had to review how to even run a cmake file LOL but we have gotten the ball rolling !

Week of October 1, 2023

Project Work

• Finished rtl for branch address calculator

Comments

I’m having some trouble with how to run the tests because my brain has been burning with a fever, so I’ll be reaching out to someone to correct any silly mistakes I’ve most definitely made soon so that I can actually test this thing.

Krzysztof’s Design Notebook

Founding member, project manager, bald guy

Since I was not maintaining this notebook over the course of the semester, I will simply summarize the work done for the team this semster:

September 3rd to Decmber 22nd, 2023

Project Work:

• Simulator Created a single cycle pyhton simulator for RISCV assembly. It’s a private repo since it’s a part of a Computing Systems Architecture course at NYU, freely available upon request.
• Multi Cycle Verilog RTL Created an RTL design in verilog for a multicycle RISC-V 32I ISA. It’s a Xillinx Vivado project, however parts of it could prove useful to the core team. It’s a private repo since, it’s a part of an Advanced Hardware Design course at NYU, freely available upon request.
• Faculty Reachout Reached out and established contact with NYU’s faculty members in the ECE department with expertise in Computer Architecture and Design. Among notable names willing to help the team are Prof. Azeez Bhavnagarwala, and Prof. Ramesh Karri.
• Coins! Facilitated design and production of this semsters “challenge coins”(more coaster-sized) with one of the team members (Nathaniel Sehati, big props)

Comments:

I should make time to update the design notebook weekly next semester. Will I?

Kevin’s Design Notebook

Week of 11 September 2023

• Refreshed my knowledge on the AHB and APB
• Discussed plans for AHB and APB issue ordering with Rishyak, Krzysztof, and Vito
• Created some APB issues that need to have more descriptions eventually

This week was spent getting reacquainted with the AHB and APB specifications and discussing the roadmap for AMBA in general with the leadership. We have decided that the APB should be pushed back a little but until more work is done with the AHB since the APB is very similar to the AHB. Next week will be spent looking over code that we have already and maybe adding more unit tests to the subordinate module.

Week of 18 September 2023

• APB GPIO Subordinate: Started working on interfaces and test files for GPIO

This week I spent creating the basic files and figuring out which signals are necessary for the APB and how they are different from the AHB. Both protocols are very similar but the APB lacks a lot of the fancy features of the AHB. This behavior also changes how the subordinate works (also called the Completer in the documentation ) so I decided it might be better to start from scratch while loosely referencing the AHB subordinate.

Week of 25 September 2023

• APB GPIO Subordinate: Continued work on GPIO files

I parameterized as much of the GPIO modules as I could and set up the CMake files to do some tests but I realized that the issue of nyu-util failing when I try to build it was still causing problems. I spoke a bit with Rishyak and ended up resetting my WSL installation to see if it would help but that didn’t help. I plan on working on my laptop from here on out since we were unable to figure out why my desktop can’t seem to build nyu-util.

Week of 2 October 2023

• APB GPIO Subordinate: Worked on environment problems.

My development environment continues to cause issues for me. Upon talking with Rishyak some more I attempted to build using my laptop which ended up having the same problem as my desktop with being unable to build nyu-util. I attempted resetting my wsl setup on my laptop but it also had no affect. I’m going to see about creating a dual boot on my desktop to see if its just an issue with Ubuntu or something.

Week of 9 October 2023

• APB GPIO Subordinate: Created basic write test for GPIO module

I ended up asking Vito to look at my environment issue and we found out that the Verilator version was a major update behind and no longer worked. To fix this we had to upgrade my Ubuntu version to the latest one. Once that was done I was able to start creating some tests.

Week of 16 October 2023

• APB GPIO Subordinate: Created read and write tests
• WSL Install Documentation: Updated WSL documentation on how to update to lunar.

I added some more tests to the GPIO module and fixed an assortment of issues with reading and writing. I also updated the WSL installation documentation to include updating to lunar from the LTS since nyu-util requires a more up to date verilator than what the LTS provides.

Week of 23 October 2023

• APB GPIO Subordinate: Fixed error with read and write and switcheed to inout pins.
• Started work on increasing coverage on SubDummy tests

I modified the GPIO module to use inout pins which means that the input and output functionality only use one wire which is more like what it would be in real life. I also started working on increasing the code coverage of the subDummy module.

Week of 6 November 2023

• Dummy Subordinate: Fix poor coverage in tests for AHB dummy subordinate

I wasn’t able to do much work last week but this week I worked on increasing the code coverage of the tests for the dummy subordinate module. After looking through the module code I wanted to experiment with redoing it based on what I learned from the GPIO subordinate.

Week of 27 November 2023

• Dummy Subordinate: Fix poor coverage in tests for AHB dummy subordinate

Forgot to update my design notebook for the last two weeks. Since the last time I worked more on re-doing the SubDummy but scrapped the idea because it was less readable and I don’t think it was any better than the original. I also added several tests for the SubDummy that should improve the code coverage. The tests included busy cycles, error handling, and idle states.

KL’s Design Notebook

Week of 11 September 2023

• This week’s work was done on creating the first design notebook.

Week of 18 September 2023

• This week’s work was done on Lab 1. Lab 1 was started and almost completed.
• Another thing completed was Commit message using Conventional Commit Syntax

Week of 25 September 2023

• This week’s work was done on Lab 1. Lab 1 was completed.
• Another thing that was verified complete was the Commit message using Conventional Commit Syntax

Week of 2 October 2023

• This week’s work was done on Lab 2.

Week of 9 October 2023

• This week’s work was done on Lab 3.

Week of 16 October 2023

• This week’s work was done on Lab 3.

Week of 23 October 2023

• This week’s work was done on Lab 3. Lab 3 will be completed soon.

Week of 30 October 2023

• This week’s work was done on studying the core design team’s projects.
• This week’s work was done on finishing the remnants of lab 3 and starting lab 4.

Week of 6 November 2023

• This week’s work was done on Lab 4.
• Lab 4 was studied carefully.

Week of 13 November 2023

• This week’s work was done on Lab 4.
• Lab 4 was studied carefully.

Week of 20 November 2023

• This week’s work was done on Lab 4.
• Lab 4 was studied carefully.

Week of 27 November 2023

• This week’s work was done on Lab 4.
• Lab 4 was studied carefully.

Week of 4 December 2023

• This week’s work was done on the core team’s microprocessor project.
• Specific work done was the instruction cache and instruction cache manager outlining.
• Collaborative efforts with Thu Vu on the outlining were completed.

Week of 11 December 2023

• This week’s work was done on the core team’s microprocessor project.
• Specific work done was on furthering the development of the instruction cache and instruction cache manager design.
• Collaborative efforts with Thu Vu on the outlining were completed.

Week of 18 December 2023

• This week’s work was done on the core team’s microprocessor project.
• Specific work done was on furthering the development of the instruction cache and instruction cache manager design. Specifically, the code was worked on and further developed on github commits on a separate fork created by the collaboraters, me and Thu.
• Collaborative efforts with Thu Vu on the outlining were completed.

Michael’s Fall 2023 Design Notebook

Week of September 11, 2023

Project Work:

• Implemented MEM/WB Latch Module: Implemented the module and tests for the MEM/WB Latch Module.
• Control Module Design: Started a detailed outline of how the control module will work.

This week was spent mostly working on the MEM/WB latch module as well as starting the detailed outline describing how the general control module will work. I also spent some time cleaning up the repository by fixing spelling mistakes, removing old assignments, and more so that it is ready for the new semester and new students. Overall, the Core repo is now in a place where new students can easily be on-boarded into Core and given a task to work on.

At this point all the outlines for the simpler modules are completed, which means I need to start finalizing the designs of things like the branch predictor, caches, and more. For very complex modules like the general control module, I plan to have more detailed descriptions of their functionality in addition to the standard outlines. As mentioned, I have started the one for the general control module and others will hopefully follow soon. I am also hoping this semester that one or two of the students on the Core team will have enough experience to be able to help me with design decisions and outlining; this is especially true regarding double-checking work and troubleshooting. As more of the core is completed, fixing bugs in module interaction or instruction execution will require someone with detailed knowledge of the overall design, and I’d like to be able to delegate bug fixing and troubleshooting to other people so that it doesn’t take up all my time and slow down our progress.

Week of September 18, 2023

Project Work:

• Added More Instruction Decoding Detail to General Control Module Documentation: Added more specified output details to the different instruction types.
• Merged Hazard Detection Module into General Control Module: Decided to merge the hazard detection module into the general control module to reduce redundant inputs and registers, since both modules would have had very similar inputs and internal registers. Started documenting the hazard detection functionality in the general control module functionality document.
• Added NOP instruction description to General Control Module Documentation: Added the decoding steps for the NOP instruction that will be used to stall the pipeline to prevent data hazards.
• Updated ID/EX Latch Docs: Updated the ID/EX Latch Documentation with the new a_sel line and new values for b_sel line to allow the Load Upper IMM and Add Upper IMM to PC instructions to work.
• Fixed Branch Evaluator Docs: Fixed the way the ALU output for branch conditions 1 and 2 is evaluated. Instead of taking the full output, it is now bitwise ORed together to get either a 1 or 0.
• Moved Branch Prediction to ID phase: Updated the Branch Address Calculator to output the predicted next program counter value so that it can be immediately fed back to the program counter, making branch prediction happen in the ID phase rather than the EX phase.
• Updated CPU Block Diagram: Updated the CPU Block Diagram in the ReadMe to reflect the changes made to the general control module, merging the hazard detection module into the general control module, the new inputs for the branch address calculator module, the new a_sel line for the ID/EX latch, and the new pc_en line for the program counter.
• Merged Uma’s General Purpose Register Module: Worked with Uma to remind her of the changes she needed to make to the register module and then merged her completed module and test into the core repo.

This week was primarily spent working on the documentation for the General Control Module. I added more specific output details to each instruction type as well as merged the hazard detection logic into the General Control Module. Most of the details for the instruction have now been added and what remains should be added shortly. In terms of the complete documentation for all functions of the General Control Module, I’d give a rough estimate that we are 40% complete, as while instruction decoding is almost fully documented, I have only just started on the data hazard detection portion of the documentation and have not yet started on handling branch prediction hazards, how the branch manager and control module will interact to deal with branching hazards and flushing the pipeline, or how to handle initialization of the core on startup.

While updating the Control Module Documentation, I discovered several oversights I made in the overall core design regarding the execution of specific instructions and branch prediction. To fix the instruction oversights, I added a few more control lines to select new parameters that would allow instructions such as Load Upper IMM to function properly. I also realized that if I moved branch prediction handling from the branch manager to the branch address calculator, we could save an entire clock cycle and predict in the ID phase rather than the EX phase.

Finding and fixing various oversights in the core design reinforced the idea that I need to find one or two knowledgeable Core Team members to meet with and give a detailed overview of the RISC-V ISA and current core design so that they can help make design decisions, help troubleshoot, and most importantly, double check my work so that mistakes are caught and correctly early on. Thankfully, we have a much larger team this semester so I am hopeful I’ll be able to find one or two students with enough initiative and aptitude to take on this responsibility.

Week of September 25, 2023

Project Work:

• Added NPC to Outline of Branch Manager Module: Added npc output the outline for the Branch Manager Module.
• Updated wbs numbering: Updated the numbering for the wbs input to the MEM/WB Latch Module so that we can just use the func3 directly from the instruction to determine wbs for the different load sizes.
• Updated General Control Module Complex Functionality Document: Updated the complex functionality document for the General Control Module with more outputs for the I instructions, NPC input, and pc_en output.
• Started Complex Functionality Outline for Branch Prediction Module: Started the basic outline for the Complex Functionality document for the Branch Prediction Module.

This week was spent on a variety of things, most of which were design documentation-related. I continued my work on the functionality documentation for the General Control Module, adding missing inputs and outputs and continuing to fill in the various instruction decode outputs. I also started work on the functionality documentation for the Branch Prediction Module as I now have most of the components surrounding it finalized so I can begin working on its functionality in more detail.

I also did some optimization to the MEM/WB latch’s wbs input. This input determines the source of the data written to the destination register and my initial numbering system proved to be inefficient when trying to decode the load instructions. While adding the General Control Module outputs for the load instructions, I realized that the func3 of the load instruction could directly correspond to the wbs, and so changed the wbs numbering scheme to be a direct 1-1 with the func3 numbering of the Load instructions, with the wbs number corresponding to the ALU, something not used by the load instructions, neatly corresponding to the unused load func3 value of 3.

The new members who joined this semester should hopefully start finishing their labs next week, meaning implementation of the already outlined modules and the needed interfaces should pick up. On-boarding people to Core should be relatively smooth as there is plenty of detailed implementation work they can go ahead and start.

Week of October 2, 2023

Project Work:

• Updated Branch Prediction Complex Functionality Document: Updated the complex functionality document for the Branch Prediction Module with additional sub-headings, the branch_taken output, and branch_occr input.
• Added Folder and Draft Outline for Connection Modules: Added a folder for and started the general outline template for connection modules that will be used to connect the various modules that make up the core.
• Added Folder and Draft Outline for Interfaces: Added a folder for and started the general outline template for interfaces that will be used to help connect the various modules that make up the core.
• Added New Issues for Interfaces and Connection Modules: Started adding issues for the various interfaces and connection modules that need to be outlined and built.
• Created General Core Tasks Project: Created the General Core Tasks project to keep track of and document the various broad and generalized tasks that need to be accomplished.
• Updated CPU Block Diagram: Updated the CPU block diagram to have more room at the edges so wires at the edges don’t disappear when using dark mode, and increased the resolution of the diagram.
• Added Core Info to Lab 7: Added Core Team information to Lab 7.
• Merged Uma’s EX/MEM Latch Module: Worked with Uma to troubleshoot her EX/MEM Latch module and then merged her completed module and test into the core repo.

This week was another documentation-heavy one, with much of the focus being on adding outlines and issues for interfaces and higher-level modules used to connect the base modules, which I’m calling connection modules. Dedicated folders were added for interface outlines and connection module outlines respectively, and I made draft outline templates for both. With the groundwork for that documentation laid down, I’ve delegated the task of refining and finishing the outline templates to Uma, as she is the Doc Czar. Once the templates are complete, I can start filling out the information for individual interfaces and connection modules. I also created issues for various interfaces and connection modules and added them to the Core Design and Implementation project. There are still many interfaces and connection modules that need to be solidified and turned into issues, something I’m hoping the eventual new Core Team members will be able to help with.

I also continued my work this week on documenting the functionality of the various complex modules, with most of the work going into the Branch Prediction module. However, I did not get much done with it other than improving the general outline and finishing the current inputs and outputs as the interface and connection module documentation took up most of my time this week.

As it stands, we are still waiting for the new members to finish the onboarding labs. Hopefully, I can get some interfaces outlined for easy implementation, as many of the simpler core modules have already been implemented. There is still a lot of design work that needs to be done however, so I am hopeful that one or two students will be up to the challenge and be able to help work on things like the cache and various interfaces needed.

Week of October 9, 2023

Project Work:

• Outlined ID Interface: Outlined the ID Interface which connects the IF/ID Latch module to the ID/EX Latch module.
• Outlined MEM Interface: Outlined the MEM Interface which connects the EX/MEM Latch module to the MEM/WB Latch module.
• Updated General Control Module Docs: Updated the Complex Functionality Document for the General Control Module with the output decode information for I Type 3 instructions and added a section for hazard detection logic.
• Merged Uma’s EX Interface Outline: Merged Uma’s outline for the EX Interface connecting the ID/EX Latch and EX/MEM Latch modules.
• Changed Documentation Folders Names: Changed the name of the documentation folders to align with the formatting used for the documentation files they contain.

This week was spent mostly working on outlines for interfaces. I’m trying to get some more ready-to-implement tasks ready for when new students join so there is plenty for them to work on. We were able to get the outlines for all the latch-to-latch interfaces done this week so that is a good start. I also continued the work on the complex functionality outline for the General Control Module which is making good progress. I’m hoping the new members are going to be ready to join teams soon as progress has been slow with just me, Uma, and Rielle working on Core, especially when Uma and Rielle also have documentation responsibilities.

Week of October 16, 2023

Project Work:

• Added Pipeline Reset Module Outline; Changed the Processor State Module to the Pipeline Reset Module, which handles flushing the pipeline after an incorrect branch prediction. I also finished the outline for the Pipeline Reset Module.
• Updated General Control Module Docs: Removed the P-State, npc, and flush inputs as flushing is now handled by the Pipelijne Reset Module which has replaced the Processor State Module.
• Completed Several Interface Outlines: Completed the outlines for the Branch Manager Input Interface, Data Cache Manager Control Interface, ALU Operands Interface, Destination Register Info Interface, Source Register Numbers Interface, and Source Register Data Interface.
• Onboarded Surya: Onboarded Surya to the core team and assigned them the L1 Cache design.
• Added Issue and Start of Outline for CSR Counters and Registers Module: Added an issue and blank outline document for the CSR Counters and Registers module that is needed for some of the system level instructions.
• Added Issue Start of Outline for Flush Bus Interface: Added an issue blank outline document for the Flush Bus Interface.

The majority of this week was spent creating and finishing outlines for various interfaces and replacing the Processor State Module with the Pipeline Reset Module. Most of the major ready-to-implement interfaces are now fully outlined and can be implemented, meaning there is plenty of work for new students to do once they are onboarded. I also finally decided what to do with the Processor State Module, opting to replace it with the Pipeline Reset Module which will handle forwarding the next program counter address to the program counter and handle flushing and resetting the pipeline.

Core Team onboarding finally started this week, with people finishing the labs. Surya was the first new member to be onboarded this semester and they expressed a desire to work on designing the caches. I’ve assigned Surya the task of designing the L1 cache and we will see how that goes. I also communicated with Charan who expressed a desire to join the Core Team after they finish the onboarding labs.

Week of October 23, 2023

Project Work:

• Finished Flush Bus Interface Outline: Finished the outline for the Flush Bus interface.
• Helped Rielle with Branch Address Calculator: Reminded Rielle of how to test her Branch Address Calculator module.

Due to being in the midst of several midterm projects, I was not able to get a lot done this week. However, I did manage to make time to finish the Flush Bus interface outline and to help Rielle with her module testing. We now have quite a few modules and interfaces ready and waiting to be implemented which is good for when more people start to join the Core Team.

Speaking of people joining the Core Team, I did expect we would have more people finished with the labs and joining teams at this point in the semester. I have had two people reach out so far, which is good, but we are going to need a lot more people soon so we can start working away at implementation and the rest of the design work.

Week of October 30, 2023

Project Work:

• Finished Branch Prediction Outline: Finalized the method of branch prediction and finished the functionality document and outline for the Branch Prediction Module.
• Removed Branch Taken Input and Output from EX/MEM Latch: Removed the Branch Taken Input and Output from the EX/MEM Latch Module since changes made to the Branch Manager Module made latching the branch taken value redundant.
• Removed Combinational Logic From Branch Manager Outline: Removed the combinational logic that handled setting the flush signal from the Branch Manager module outline and replaced it with clocked sequential logic that should be less prone to errors and timing issues.
• Updated CPU Block Diagram: Updated the CPU block diagram to reflect the various changes made to modules such as removing Branch Taken from the EX/MEM Latch and the new inputs and outputs needed for the completed Branch Predictor.
• Helped Troubleshoot and Merged Rielle’s Branch Address Calculator Module: Helped Rielle troubleshoot some Codecov issues and then merged her completed Branch Address Calculator Module.

The majority of this week was spent on finalizing the branch prediction module. I decided to go with a 2-bit branch predictor which required a few new inputs to be added to the module. Both the functionality description and the module outline are now completed for the branch predictor so it is ready to be implemented. While finalizing the branch predictor, I also made some changes to the Branch Manager and EX/MEM modules. Originally, the branch_taken signal was latched into the EX/MEM Latch and then passed to the Branch Manager in the MEM phase where combinational logic would control the flush signal. However, I realized I could instead pass the branch_taken signal directly into the Branch Manager in the EX phase and then use sequential logic for the flush signal rather than combinational to achieve the same result of flush being set in the MEM phase without the timing issues of the combinational approach. Rielle was also able to finish her work on the Branch Address Calculator which was good so I was able to merge that into the main repo.

Week of November 6, 2023

Project Work:

• Implemented ID/EX Latch Module: Implemented the module and tests for the ID/EX Latch Module.
• Implemented Branch Predictor Module: Implemented the module and tests for the Branch Predictor Module.
• Started Work on the Branch Manager Module: Started work on the implementation of and tests for the Branch Manager Module.
• Commented on Surya’s initial L1 Cache PR: Reviewed Surya’s initial PR for the L1 cache and reminded them to fill out the L1 Cache outline and design a test for the L1 Cache.

This week was mostly spent on implementing the ID/EX Latch and Branch Predictor modules as well as starting work on the Branch Manager module. After not touching implementation for several weeks in the hopes that easy implementation tasks would encourage new members to join the team and quickly get to work, it is clear that approach was unsuccessful and we’ll need to go full steam ahead with the 4 current members, hopefully soon to be 5, committed to Core Team work. In terms of implementation, Uma has started work on the EX and Source Register Data interfaces so those should hopefully be complete soon. Once we get several interfaces complete we’ll be able to tackle all the otherwise fully functional modules that still need to be interfaced and then test the functionality of several modules together. Surya has also continued work on the L1 Cache, completing the Verilog implementation and complex functionality description. Once Surya finishes the L1 Cache outline and tests that should be another module implemented.

At this point in the semester, I am quite concerned that I have only had 2 new students reach out to work on Core, one of which has yet to complete the labs. At this point in the semester, everyone should have finished the onboarding labs quite a while ago and be well integrated into a repo team to work on implementing and/or designing components. I’m going to make the best of the current situation as I have no other choice, but I’d like to find a way to get more of the new students engaged and joining teams.

Week of November 13, 2023

Project Work:

• Added Warning to Lab 5: Added a warning to onboarding lab 5 that it is currently incomplete, missing both the corresponding repository and exercise, and for now members should just read it over and move on to Lab 7 since Lab 6 is currently blank.
• Made the Fence Instruction a NOP: Added the opcode for the Fence instruction to the list of NOP instruction opcodes as Fence does not have a use for our single core CPU.
• Made SYSTEM instructions NOPs: We don’t really have a use for ecall and ebreak so they will be treated as NOPs. As such, the SYSTEM opcode was added to the list of NOP instruction opcodes.
• Implemented Branch Manager Module: Implemented the module and tests for the Branch Manager Module.
• Implemented Pipeline Reset Module: Implemented the module and tests for the Pipeline Reset Module.
• Finished Complex Functionality Doc and Outline for General Control Module: Finished the complex functionality document for the General Control Module by finalizing the hazard detection logic and the instruction control signals. Also finished the outline for the General Control Module.
• Updated CPU Block Diagram with cache_clk: Changed the clk inputs for the caches on the CPU Block Diagram to use a separate cache_clk.

This week was spent on two main tasks, implementing the Branch Manager and Pipeline Reset modules, and finishing the functionality documentation and outline for the General Control Module. This week continues the work I started last week on moving through implementation tasks by implementing two more modules. With the Branch Manager and Pipeline Reset modules implemented, the only unimplemented base-level modules left are the General Control Module, which I finished the outline for this week so is ready to be implemented, the Data Cache modules, which Surya is working on, the Instruction Cache module, and the Cache Manager modules, which can’t be outlined or implemented until all the caches are finished. I would like to have all the base-level modules outlined and implemented by the end of the semester and that is certainly doable at this point.

This was also the week I also finally finished the functionality documentation and outline for the General Control Module. No one seemed to be interested in working on the hazard detection logic when I asked, and given it was really the only thing left incomplete with this module, I decided to just tackle it myself. Working on the hazard detection logic revealed some timing issues with how the General Control Module stored instructions in registers, namely that the IF_ins register through everything off by a clock cycle. As such, I removed the IF_ins register, using the ins input to determine the instruction in the IF stage instead. I also realized that I have duplicated the pc_en output by having it both in the instruction decoding outputs and the hazard-related outputs. This was easy to fix as I also realized that pc_en didn’t work as part of the decode signals anyway since having it always disabled by a NOP instruction would cause NOPs to freeze the pipeline, so it was entirely removed from the decoding outputs and left solely as a hazard related output.

I also asked Vito this week whether we needed to implement the privileged part of the RISC-V ISA, which thankfully we don’t meaning we don’t need to implement the CSR registers or instructions. My conversation with him also cleared up my confusion about how ecall and ebreak would work in the unprivileged version of the ISA in that we can just treat both as NOPs.

Week of November 20, 2023

Project Work:

• Implemented ID Interface: Implemented the ID Interface module.
• Implemented MEM Interface: Implemented the MEM Interface module.
• Implemented Data Cache Manager Control Interface: Implemented the Data Cache Manager Control Interface module.
• Implemented Branch Manager Input Interface: Implemented the Branch Manager Input Interface module.
• Implemented ALU Operands Interface: Implemented the ALU Operands Interface module.
• Implemented Data Register Info Interface: Implemented the Data Register Info Interface module.
• Implemented Source Register Numbers Interface: Implemented the Source Register Numbers Interface module.
• Outlined MEM Connection Module: Finished the outline for the MEM Connection Module.

Most of this week was spent on implementing various interface modules in Verilog. I also looked into how to test modules once their inputs are converted to interfaces and realized that we can’t have interfaced inputs in a Top Level Module so the relevant connection modules will need to be implemented before testing of interfaced modules can occur. I also added issues for various connection modules and finished the outline for the MEM connection module.

Week of November 27, 2023

Project Work:

• Put Interface Development on Hold: Put the development of interfaces on hold and moved the previously completed interface modules to a new on-hold folder.
• Updated the Connection Module Outline Template: Updated the template for connection module outlines to remove reference to interfaces and clean up the template overall.
• Updated MEM Connection Module Outline: Removed the MEM/WB Latch Module from the MEM connection module outline and made the necessary changes to the outline to accommodate that change.
• Moved IO from Cache Managers’ Outlines to Respective Change Connection Module Outlines: Moved the IO that had been specified for the Cache Managers in their outlines to the respective Cache Connection Module Outlines.
• Removed the WB Component of the ID WB Connection Module: To simplify the designs of the connection modules, the WB component of the ID WB Connection Module was axed and the module was renamed to the ID Connection Module.
• Updated CPU Block Diagram with Cache Connection Modules: The Cache Manager Modules in the CPU block diagram were replaced with their respective Cache Connection Modules.
• Outlined IF Connection Module: Finished the outline for the IF Connection Module.

A major decision was made this week to put the development of interfaces on hold until the CPU core is completed and fully functional. The interfaces are not required for full functionality and while they do provide a cleaner way of connecting modules together and make updating connections between modules easier, those benefits were overshadowed by the lackluster handling of interfaces by Verilator, making testing needlessly more complex, and by the mistake I made of designing the interfaces before the connection modules, which ended up making designing the connection modules way harder than it had to be. Once the CPU core is fully functional, the interfaces can be redesigned and reimplemented as they do provide benefits, but that implementation is better left till after the CPU core is working and we have time to spare.

Putting interface development on hold allowed me to come up with a general template for the connection modules, as I didn’t have to worry about how I would work around the existing interface designs that were often at odds with my preferred design for the connection modules. The connection modules as now split into 4 major categories: Caches, Pipeline Stages, Controls, and Top Level. The Cache Connection Modules are self-explanatory; there are two of them, Data Cache and Instruction Cache, with each containing the cache modules and cache manager module for their respective cache. As such, the CPU will now communicate with the cache manager and caches via these connection modules, rather than directly with the cache manager as was the case before. Combining the various cache modules like this should make testing the caches easier. The Pipeline Stage category is the largest, consisting of the connection modules for the IF, ID, EX, and MEM pipeline stages. Each stage’s connection module contains the starting latch module for that stage, e.g. IF/ID for ID, along with all non-control-related modules contained in that stage. Notably, the IF Connection Module does not contain any latch module since there is no preceding latch for the IF stage; there is also no connection module at all for the WB stage as its only relevant module is the CPU Registers Module which is already claimed by the ID stage, as such, the MEM/WB latch outputs are simply inputs to the ID Connection Module. The final two categories contain a single connection module each. The control category houses the Branching Control Connection Module which contains the Branch Manager, Branch Predictor, and Pipeline Rest modules, as they are not cleanly tied to a single pipeline stage and have many interconnections between each other. Finally, the Top Level category contains the aptly named Top Level connection module which connects all the connection modules together alongside the General Control Module.

I have also had a number of people reach out this week about joining the Core Team. Kyle and Thu have taken on the Instruction Cache which now means at least one person is working on the design and implementation for all yet-to-be designed and/or implemented lower-level modules. Xingzhi also reached out and he is currently deciding what task he wants to take on. With several people now new to the Core Team, I plan to hold a Core Team and Core design overview meeting sometime next week for those interested. While I would have liked to reach this point much earlier in the semester, I am relieved that people are finally started to join the Core Team in decent numbers.

Week of December 4, 2023

Project Work:

• Changed IO Line Names: Changed the names of some IO lines on the CPU Block Diagram to make their functionality clearer and keep them more consistent between different modules.
• Outlined ID, EX, and Branching Control Connection Modules: Finished the outlines for the ID, EX, and Branching Control Connection Modules. Also updated the Connection Module Template.
• Implemented EX Connection Module: Implemented the EX Connection Module and tests. Also fixed the mechanism for randomization in all the various tests as we had been moduloed by the max value instead of the max value + 1.
• Updated Randomization Example in Dev Test Process Doc: Updated the development and testing guidelines document to fix the modulo part of the randomization example.
• Held Core Team Overview and Q&A Meeting: Held a meeting with the new members of the Core Team where I went over the Core repo, our development process, the Core design, and answered questions people had.

This week I finished the outlines for various connection modules and implemented the EX Connection Module. At this point, the only module that has yet to be outlined and is not currently assigned to someone to be outlined is the Top Level Connection Module. Since the Top Level Connection Module is essentially the final step, as it contains all other modules, it will likely remain unoutlined until more progress is made on the cache outlines. In terms of the caches, I spoke to Surya and he is making good progress on the data cache modules. We have decided to leave the L3 cache for later as it is more of a nice to have than anything and not necessary to get the Core functional. I also held a meeting this week for new members of the Core Team as many people were asking me similar questions so I wanted to address them all at once. I went over the organization of the Core repo and our development process as well as the design of the Core and how each component worked together.

Week of December 11, 2023

Project Work:

• Started Implementing ID Connection Module: Started working on the implementation and tests for the ID connection module.
• Requested End-of-Semester PRs from Core Team: To wrap up the semester, I requested members of the Core Team make PRs for their current tasks so I could review their progress and any issues they were facing.

This week I started work on implementing the ID Connection Module. I was able to finish the initial verilog implementation of the module and start working on the tests. Given that this is the last week of classes, I also requested that Core Team members create PRs with their work, even if unfinished, so that I could review it. Given that next week is finals and the semester is over, this is likely the last weekly design notebook entry I’ll make until the spring semester starts in late January. I may make a few sporadic entries here and there over break, however.

Vito’s Design Notebook

This is a teamleiter, it leiters the team

Nathaniel’s Design Notebook

This is Nathaniel, a tech hobbyist and tinkerer.

Pingchuan’s Design Notebook

Hello! This is Pingchuan’s Notebook.

Week 1 (Sept. 18 - Sept.25)

Tasks:

• Onboarding Lab 1: Completed Lab 1

Comments

This week, I installed vm for linux system, completed the cmake lab in the linux environment. Ran into a few issues during the building process, and mistook CML as commandline instead of CMakeLists. Pay more attention to commit message conventions. Starting to do lab 2 and will finish it by the end of week 2.

Week 2 (Sept.25 - Oct.2)

Tasks:

• Onboarding Lab 2: Completed Lab 2

Comments

This week, I refreshed my memory on verilog, and got a bit confused about the different variable names, namely logic, reg, and wire. logic is often used to represent individual bits or signals in digital circuits, and it represents a single binary value that can be either 0 or 1. reg is a data type used to declare registers or storage elements in Verilog. Registers can store and retain values over time. wire is a data type used to represent a continuous signal or connection between logic gates or components. It carries values from one point in a circuit to another. Starting to do lab 3 and will finish soon.

Week 3 (Oct.2 - Oct.9)

Tasks:

• Still finishing up lab.

Comments

This week, I was caught up in a busy work schedule, and was confused about writing verification codes. Aiming to finish lab 3 by the end of next week.

Week 4 (Oct.9 - Oct.16)

Tasks:

• Onboarding Lab 3: Completed Lab 3

Comments

This week, I continued to work on verification codes. The idea of verification code is new to me so it took me some time to understand. Strategy of writing verification tests: implement the verilog modules as c++ functions first, then come up with a testing strategy to verify. For Don’t Care variables, the test needs to show that it really is irrelevant by testing an amount of possible values for it. Starting to do lab 4 and will finish soon, but may be a bit late because of the midterms.

Week 5 (Oct.17 - Oct.23)

Comments

• Working on Lab 4, but caught up in midterms

Week 6 (Oct.24 - Oct.30)

Comments

• Continuing to work on Lab 4.

Week 7 (Oct.31 - Nov.6)

Comments

• Finished writing the verification codes for lab 4, but couldn’t get them to run.
• After updating wsl and everything, read from the log that there were additional packs that it wants me to download; the verification codes worked eventually.

Week of Nov.6 - Nov.13

Tasks:

• Onboarding Lab 4: Completed Lab 4

Comments

I was slow on the onboarding labs due to midterm preparations last week, and am destined to finish lab5/get started on actual work next week. This week, I learned more about verification using catch2 and nyu-cmake. I also learned about interface libraries, they are different from normal libraries in that they can consist of and files that aren’t compiled immediately.

Week of Nov.14 - Nov.21

Tasks:

• Completed Onboarding Lab 5

Comments

This week I went through the tutorials in lab 5, learned about when to use wire, reg, and logic. Wire: for multiple driver circuits; logic: for single driver circuits(most things); reg: there are tricky restrictions, rarely used. Also learned how to use interfaces to simplify things when modifying interconnections between modules. After implementing the interface, we only need to modify the modports if we need to change the interconnections. Lastly, I learned about the #() syntax, with a parameter list inside. The list givea default values to corresponding parameters, which can be changed later.

Week of Nov.21 - Nov.27

Tasks:

• Looked into the team descriptions and decided to work on AMBA. Reached out to Rishyak for instructions.

Week of Nov.28 - Dec.4

Tasks:

• Still reading through the AMBA repo, got assigned the AHB decoder.

Week of Dec.5 - Dec.11

Tasks:

• Talked to Rishyak about designing the AHB decoder.
• Note: the decoder is meant to receive the address signal from the manager, and deliver the selX signal to the corresponding subordinate.
• Wil read further into the AHB pdf.

Week of Dec.12 - Dec.18

Tasks:

• This week I mainly focused on final exam preparation, so I will continue to design the AHB decoder next semester.

Summary of Fall Semester

• Learned a lot from the onboarding labs, especially about writing verification codes, which was what created a lot of trouble for me.
• Spend more time than I expected on the onboarding labs, and I am currently working on the AHB decoder.
• I will find time to work on the decoder during the holiday, and hopefully have something done by the start of next semester.

Design Notebook - Charlie Wu (qw2246)

Week of 10 September 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1

Week of 24 September 2023

Project Work:

• Onboarding Lab 2: Completed Lab 2

Last few weeks were all over the place. This week tried finish lab 2 and had some issue with testing exercise 4, but magically fixed it by re-running ninja build.

Week of 1 October 2023

• Onboarding Lab 3: Completed Lab 3

Had some problem with exercise 3, due to the bitwise shifting, and could not use the gdb debugger since my mac only has lldb. However, with the help from Rishyak, I was able to figure out the problem and finish the lab.

Rishyak’s Design Notebook

This is Rishyak again, he does processor-designer-ey things.

This is also Rishyak’s last design notebook.

Week of September 3, 2023

Project Work

• Finance: Filling and submitting budget proposal forms with out finance team

Comments

Spent the week trying to get our budget proposal out so we have funds for tapeout next semester.

Week of September 10, 2023

Project Work

• AMBA Organisation: Brainstormed action items for AMBA for the semester

Week of September 17, 2023

Project Work

• Lots of git lectures, I think I have explained how git works a double-digit number of times by now

Week of September 24, 2023

• Fixed Kevin’s compilation issues with Vito
• Realised we need the latest Ubuntu

Weeks of October 1 and 8, 2023

• Midterms got me

Week of October 15, 2023

• Spoke to Kevin and Krzysztof about burst transfers
• Made significant progress getting simple transfers set up

Week of October 22, 2023

• Hit a snag with testing simple transfers
• Also PC troubles, had to recompile the kernel

Week of October 29, 2023

• Spoke to Vito about the generic interface
• Job interviews got to me
• Helped a few people with orientation labs

Week of November 6 and November 13, 2023:

• Didn’t learn my lesson, midterms got to me again
• Bought spools for coins

Week of November 19, 2023:

• Spoke to Kevin about coverage, subordinate, and APB stuff

Week of November 26, 2023:

• Got to debugging my test suite

Month of December 2023:

:tired_face: :nomouth:

Semester Review

Definitely didn’t get as much done as I wanted to. I didn’t expect job hunting to take up as much energy as it did

Thu’s Design Notebook

Hello, World! Welcome to my notebook.

Week of 11 September 2023

Project work:

• Onboarding Lab 1: Completed Lab 1

This week was spent getting used to using Git on command line, learning and settting up virtual environments, installing the required tools for the labs, and completing onboarding lab 1.

I think the lab was a good introduction to toolchain. The document was very detailed and super helpful. I just learnt about CMake and Make during OS this same week so it was nice to get to chance to put some of my new knowledge to use!

Week of 2 October 2023

Project work:

• Onboarding Lab 2: Completed Lab 2

Last week I was away on a conference so I didn’t get a chance to work on Lab 2. This week was spent reviewing Verilog, running the tests from Onboarding Lab 2.

I realize I’ve forgotten quite a bit (lot) of Verilog, but I’m now more confident after completing the lab. Next week, I’ll catch up on Lab 3+4.

Week of 9 October 2023

Project work:

• Onboarding Lab 3: Working on Lab 3

Struggling a bit with the first few exercises, will review some concepts and finish the lab next week

Week of 16 October 2023

Project work:

• Onboarding Lab 3: Completed Lab 3

Finished Lab 3. Took quite some time at first but after I got through the first 2 exercises the rest was straightforward. Felt a lot more comfortable with testing now.

Week of 23 October 2023

Project work:

• Onboarding Lab 4: Started Lab 4

Working on Lab 4. Have been pretty busy with work so will be updating the notebook a bit late…

Week of 30 October 2023

Project work:

• Onboarding Lab 4: Completed Lab 4

Finished lab 4.

Week of 6-13 November 2023

Project work:

• Lab 5: Advanced System Verilog
• The Realm of Confusion: Object Kinds in SystemVerilog: Further reading

Read through Onboarding Lab 5 and blog post on SystemVerilog. Was super helpful, I realized there’s a lot about Verilog I didn’t know since I just naturally picked up on the language. No exercise for this lab.

Week of 20 November 2023

Finished the onboarding labs. Reached out to Michael to join core. I’ll be collaborating with Kyle to work on the outlines for the instruction cache and instruction cache manager. This week was spent mostly on reviewing module concepts from Comp Arch.

Week of 27 November 2023

Project work:

• Instruction Cache Manager Outline: Started the outline

Started outlining the instruction cache manager. Worked with Kyle to figure out inputs, outputs, and registers for the manager.

Week of 4 December 2023

Project work:

• Instruction Cache Manager Outline: Almost finished
• L1 Instruction Cache Outline): Started on L1 cache

Met with the core team to clarify a few features for instruction cache. For a prototype, this module should be sufficient. The instruction cache manager outline is basically done, will continue with L1 cache next week.

Week of 11 December 2023

Project work:

• Instruction Cache Manager Outline: Needs review
• L1 Instruction Cache Outline: Almost done

Finals week so a little busy but I’ll be making pull requests for the outline this weekend. Both are almost done, just need a little refining.

Uma Nachiappan’s Design Notebook

A Doc Czar doc czarring and processor designing…

Week of 11 September 2023

Project Work:

• CPU General Registers Implementation no longer complete

This week was realizing I did not finish the General Registers from last semester, and also discovering that it was unfortunately un-committed - completely slipped my mind to finish it this week, but I found my old module/test files and I’m hoping to actually wrap it up by next week.

Week of 18 September 2023

Project Work:

• CPU General Registers Implementation complete :)

After being reminded of old Discord conversations and making silly code typos, I finished the implementation of the registers by adjusting how Register 0 worked, and testing accordingly (with three different commits, sorry Michael). Next week, I want to fix an additional issue with the program counter and also start developing a new component.

I also need to resume Docs work so I’m not slacking on my Czar responsibilities.

Week of 25 September 2023

Project Work:

• Core Program Counter Added PC Enable
• Onboarding Need to edit Docs section!
• Core EX/MEM latch Claimed another component :)

Fixed the program counter issue by adding an enable input and rewrote test file with multiple test cases and more comments (waiting to be merged) while making more silly typos. Considered dropping out of CS after using a / in the name of a test case which failed the Verilator check :)

I have a Docs task to update the Paths onboarding doc - going to finish it asap before people finish their labs.

While waiting for the PC to be merged, I claimed another Core component - EX/MEM latch. Hopefully I will not be writing “even more silly code typos” to next week’s DN.

Week of 2 October 2023

Project Work:

• Core EX/MEM Latch Implementation completed
• Onboarding Figuring out how to word this…

I don’t want to talk about the EX/MEM latch but I suppose I have to. It took me 10 commits (TEN!) to fix all the tiny mistakes and bugs that the Verilator check kept finding. I was incredibly frustrated with myself and my apparent inability to notice code details, that I completely forgot about Michael’s request for me to write a template for Core interfaces, but at least the latch is finally completed and merged. I also pushed back my documentation tasks (especially the Paths doc) because of the latch as well, but I’m determined to finish it this long weekend, as well as implementing some interfaces this week for the core modules I’ve implemented. Let’s see if I can finish these and maybe get another Core component.

Week of 9 October 2023

Project Work:

• EX Interface Interface completed
• Onboarding Updated

Midterm season! Anyways… looked over the current interface docs/template, and created/committed an interface for the EX stage. I also updated my part on the Onboarding Paths doc. AND forgot to do my DN :)

Week of 16 October 2023

Project Work:

• Core Documentation Fixed broken links
• More Core Documentation Need to update guidelines

Midterm season continues and gets worse :) I was only able to fix some documentation stuff for Core, but hoping to get moving again after this week in terms of implementing components/interfaces. Going to grab another Core Issue, but we’ll see how much sanity I have after my OS and Databases midterms.

Week of 15/9/2023

Project Work:

• Onboarding Lab 1: Completed Lab 1

• [Developement Environment setup]: set up required environment

This week I go through the Introduction of NYU Processor Design, create repo and install required tools. Complete the Onboarding Lab1.

Week of 22/9/2023

Project Work:

• Onboarding Lab 2: Completed Lab 2.

This week I finished Lab 2.

Week of 30/9/2023

Project Work:

• Onboarding Lab 3: Working on Lab 3

This week I stuck on Lab 3. Can’t figured out how to determine whether the output is right and confused of uint8_t logic.

Week of 5/10/2023

Project Work:

• Onboarding Lab 3: finish Lab 3

This week I finished Lab3. Working on Lab4.

Week of 14/11/2023

Project Work:

• Onboarding Lab 4: finish Lab 4

Finally work out Lab 4! for the past weeks:

1. vcpkg does not download nyu-cmake automatically. (I thought it should). git clone and place it in Lab4 folder, set(nyu-cmake_DIR /nyu-cmake)
2. fix the ex3 and ex4 in dv
3. figure out code “cmake -DNYU_BUILD_TESTS=TRUE .. ctest –output-on-failure .” is missing “make”.

Week of 28/11/2023

Get in touch with the core leader. Started reading the The RISC-V Instruction Set Manual and look at the Documentation.

Week of 7/12/2023

Working on con_branching_control

Week of 14/12/2023

Working on con_branching_control

Spring 2023 Design Notebooks

• Aniket Kriplani

• Rielle Lim

• Krzystof Chciuk

• Kevin Yap

• Michael Lippe

• Vito Gamberini

• Rishyak Panchal

• Swarnashri Chandrashekar

• Siddharth Kandpal

• Sean Doyle

• Uma Nachiappan

Week of January 23 2023

Project Work:

• Took a quick look at the Week 1 onboarding lab, but wasn’t able to make much progress yet. Will definitely spend some time during week 2 getting ahead as I have more time.

Week of January 30 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1
  • Opened an issue on Lab 1 (cmake and toolchain) to describe some trouble that I had with cmake.
• Attempted Lab 2, but was unable to make progress as I’m on Anubis.

Github Desktop:

Here’s a quick summary of where Github Desktop slots into my personal tech stack. Personally, I like to use the browser version of Github for forks, etc., probably just because I’m used to it and haven’t had to do anything sufficiently complicated to where I’d need to change that. Github Desktop is convenient for linking my files to Github, specifically because, right after I’ve forked a repo, there’s a button to swap over to Github Desktop. This copies all the files directly to my machine, and Github Desktop has functionality to open those files in VSCode. Once there, I can edit the files as I please, click back to Github Desktop, and commit the files to Github in one or two clicks. This is especially useful when a project is organized in a complex manner, eg with a lot of directories. One button, and it’s all uploaded. Once I’m done uploading/updating whatever I need to, there’s a convenient button to open the repository in a browser. You can also do pulls, etc. from Github Desktop, but I prefer to do those from the browser version, so being able to get the linking done and return to the interface that I’m more familiar with is a nice feature.

Week of February 6 2023

Project Work

• Still wasn’t able to work on lab 2, but went venturing around for small mistakes and such.
  • Noticed a small grammatical error, so created a pull request

Week of February 13 2023

Project Work

• Installed VirtualBox VM and got full development environment up and running
• Onboarding Lab 2: Completed Lab 2
• Onboarding Lab 3: Began Lab 3
  • No commits yet because wasn’t able to build files properly, will figure out later
• Pull request on spelling error

Week of February 20 2023

Project Work

• Onboarding Lab 3: Fixed build errors and completed half of Lab 3
• ChatGPT Sample Created a quick summary of how ChatGPT fared for the assignment.

Week of February 27 2023

Project Work

• Onboarding Lab 3: Finally finished Lab 3!
• Helped Rielle out with some build errors she was facing with Lab 2

Week of March 6 2023

Project Work

• Onboarding Lab 4: Finished lab 4
• Issue with Lab 4: Opened an issue about some brief confusion I had with lab 4
• Grammatical Error Pull Request: Made a quick pull request about an error I spotted

Week of March 13 2023

Project Work

• Labs are done, so now I have to decide which team to work on. Leaning towards memory, but am doing more research.

Week of March 20 2023

Project Work

• Successfully joined Memory team under Sean, am now waiting for an assignment.

Week of March 27 2023

Project Work

• Started work on the Hex-to-Verilog Parser

Week of April 3 2023

Project Work

• Finished Hex-to-Verilog Parser

Week of April 10 2023

Project Work

• Did testing for ROM generation with OpenRAM, both on Windows and a Linux VM (rip my computer :cry:). Failed on the last step with the Linux VM…

Week of April 17 2023

Project Work

• Built end of semester presentation

Week of April 24 2023

Project Work

• Presented end of semester presentation!

Week of 23 January 2023

Updates: Made a Github account Began learning how to use Github and how to forks, branching, and pull requests Started looking through lab 1 without making significant progress

To Do: Continue becoming more comfortable with Git Complete lab 1 and begin lab 2

Week of 30 January 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1

This week was used to complete the onboarding lab for week 1.

I am a bit behind on labs and may have to speed up, but I got a bit stuck on part 2 and 3 because the separate include and src directories caused some sort of error that I couldn’t figure out. I was also confused on how to see any output. Below are some other notes I took during the lab.

Lab 1 notes

• had difficulty figuring out what directory was at first and then was confused on what exactly to do to have the directory show up in the console, but I figured it out eventually!! successfully printed out “Hello World”
• for part 2 I learned:
  • add_executable() will introduce a new program to be created
  • target_sources([new name] PRIVATE [file used.cpp]) will be the source file used with this new program
• had some trouble figuring out how to actually run the new files that I made with name.hpp and name.cpp …
• Questions I had:
• when would you need a meta-build system?
• is part 2 supposed to produce any output?

Week of 20 Feb 2023

Had a busy week so only had time to read through lab 3 and brush up on more verilog. Might plan to come up with a list of topics I’m unsure of and run through them with someone soon!

Week of 27 Feb 2023

Project work:

• Onboarding Lab 2: Completed Lab 2

I actually finished this lab a while ago and literally just forgot that I didn’t test it… This week I sat down, installed homebrew, and had LOTS of fun learning how to properly use homebrew and how to test this lab. I didn’t realize that I didn’t have cmake installed or whatever is needed to run verilog stuff locally. Thankfully, Nicky K helped me out with the testing stuff using cmake and a friend from home helped yell at me until I learned homebrew and cmake fully (thumbs up, def wasn’t abused into obtaining knowledge) :)

I feel much more comfortable with github and verilog, as well as just identifying what exactly it is I struggle with/how to explain what I need help with to people!!

Week of 6 Mar 2023

Project work:

• Onboarding Lab 3: Completed Lab 3

Lab 3 consisted of me staring at the test cases from lab 2 and trying to learn and implement them myself. I think I have a good handle on how to start a test case, but I think I may need a little bit more time to understand how to make sure when the test case is messed up vs when the program is messed up.

Week of 20 Mar 2023

Project work:

• Working on lab 4 and finishing up last portions
• Reading up on core and CPU

Took a bit of a break last week and so forgot to pull request literally anything. Getting back on track this week but getting slightly behind due to some personal stress and work overload.

Week of 27 Mar 2023

Project work:

• Onboarding Lab 4: Completed Lab 4 (finally…)
• Began taking note of documentation issues raised in the nyu-core and connecting with Uma and Michael to know what to do.
• CPU General Purpose Registers documentation completed.
• IF/ID Latch documentation completed.

I’m starting to work on documentation issues with Uma and Michael and figuring out what exactly I have to do now that I’ve finished uploading and fixing all my lab work. I also fixed up the formatting of my design notebook because it was ugly :) I had to review markdown to make everything pretty but overall I would say it’s actually really fun to do and organizing everything helps me review how the processor works as well.

Week of 3 Apr 2023

Project work:

• ID/EX Latch Documentation completed
• Planned out to work on a presentation with Uma for Markdown, Github stuff, and documentation
• Edited CPU General Purpose Registers and IF/ID Latch docs with some tables to improve readability. (I learned how to do tables for Markdown while doing this!!)

Lowkey a slower week because I was swamped by my club’s events, but I still got some stuff done and I know exactly what to do for the following week at the very least! I’ll be working on the presentation with Uma, working on more NYU Core docs, and I might look more into doing core implementations as well because I don’t exactly know how to get started with it :D

Week of 10 Apr 2023

Project work:

• Docs Template Documentation template completed
• EX/MEM Latch Documentation completed
• MEM/WB Latch Documentation completed
• General Control Module Documentation file created; not completed as there is not yet a formal outline
• Branch Evaluator Documentation completed

As per Michael’s genius suggestion, I created a documentation template that, as you can see, really sped up the documentation flow. I’m pretty sick as I’m writing this so I’m looking to a pretty low work week as I recover from the excrutiating joint pain that is making even typing hard for me. But in between the ouch I will try to work on the presentation with Uma and begin looking/working on the branch address calculator that Michael has recently assigned to me! All in all, despite my own health issues, I would say that I’m really proud of the work I was able to do this past week!

Week of 17 Apr 2023

Project work:

• Edited some module documentation for extra consistency after Michael did a little updating
• Created files for unoutlined modules:
  • Hazard Detection,
  • Processor State,
  • L1 Data Cache,
  • L2 Data Cache,
  • L3 Data Cache.
  • Instruction Cache Manager,
  • L1 Instruction Cache,
  • Branch Predictor
• Complete documentation for modules:
  • ALU,
  • Program Counter,
  • Branch Address Calculator,
  • Branch Manager

As a lot of the files made were basically empty files, I got a lot more work done than I had anticipated given that I’m in excruciating pain LOL. Looking to start the branch address calculator soon and finishing up the presentation with Uma.

Week of 24 Apr 2023

Project work:

• Finished Markdown/Github presentation with Uma
• Began to read about branch address calculator and what needs to be done to try and get started.

I talked to Michael about working on the branch address calculator, and I don’t quite think that I’ll have it done amidst finals and projects running full speed at me. However, I will continue to be editing docs and outlining what I need to do with it in between study time!

Krzysztof’s Design Notebook

Founding member, project manager, bald guy

Week of 23 January 2023

Project Work:

• Onboarding Lab 1 Completed Lab 1
• Design Notebook Started repo for the design notebook

Comments

Completed Oreintation Lab 1, configured git and GitHub access for use with Anubis because my computer recently had a stroke and I don’t trust it to hold anything even remotely resembling anything that could be somewhat important.

Also started a secondary VIP repo for my work and notebook, I’m a little bit paranoid since my PC had the aforementioned stroke.

Week of 30 January 2023

Project Work:

• Onboarding Lab 2 Completed Lab 2
• Onboarding Lab 3 Completed Lab 3
• New Job Project Manager of our VIP team
• Design Notebook Updated the design notebook

Comments:

Playing a little bit of catch-up-ahead, because my availability may get spotty over the next few weeks, turns out that getting married takes up a lot of time before it actually happens!

Completed Orientation Labs 2 & 3, went fairly smoothly, although I did have to do what is called a PRO-proGrAMmER-MOVE and did google a lot for syntax and basic terms reasons, because I never remeber things when I need them (obviously).

Also have been appointed Project Manager, as the other more different bald person on the team, I think there’s a pattern emerging here…

Another interesting side effect of my computer’s near death experience is that my minus key is very dead. I found out when I had to fix code, because none of the keystrokes on the - key registered (I hope insert key will not be required moving forward in my life, because it’s now rebinded to -). And the speakers stopped working. And the screen has a purple smudge in the middle, because red and blue subpixels dont turn off properly.

Week of 6 February 2023

Project Work:

• Onboarding Lab 4 Completed Lab 4
• Project Management Completed bi-weekly PM rounds
• Design Notebook Updated the design notebook

Comments:

Completed Orientation Lab 4, all seemingly straightforward, however (disclosure), I did not test/compile the code, because Anubis was having none of it at the time I was doing the lab, and I did not have time to come back to it this week.

Completed bi-weekly PM rounds to make sure all team members have everything they need to complete their tasks for the week.

Updated my design notebook, and that was it for the week. Getting married really does take up a lot of one’s time - will do my best to catch up after next two weeks pass.

Week of 12 Februrary 2023

Project Work:

• Project Management Completed one round of PMs on Monday
• Design Notebook Updated the design notebook, minor formatting changes

Comments:

The week of getting married, busy with everything outside of school, only had time to complete one round of PMs. Had a quick meeting with Vito, then Rielle to help get everyone on the same page when it comes to documentation. Made some minor formatting changes to my Design Notebook.

Week of 20 February 2023

Project Work:

• Project Management Completed rounds of PMs.

Comments:

The week after I got married, completely slammed with starting midterm season and overdue school work. Creating this entry more than a week later than the date above.

Week of 27 February 2023

Project Work:

• Project Management Completed rounds of PMs.
• Onboarding Lab 5 Completed the reading assignment.
• Design Notebook Updated the design notebook

Comments:

Completed lab 5 reading portion, inicluding the blogpost, and my rounds of PMs. A few people had difficulty when navigating github, especially when it comes to all the naming (forks, branches, upstream, origin, and all the other lingo software people use). Had the first team leadership meeting, and attended my first general team meeting, because my class I usually have at 5 got moved( but only this time I’m afraid).

Week of 10 April 2023

Project Work:

• Project Management Completed rounds of PMs.
• The Anti-Presentation Given the presentation on how not to do presentations.
• Design Notebook Updated the design notebook, minor formatting changes.

Comments:

A first entry in a while, but the previous ones would have been repetitive. I completed my rounds of PMs, made sure everyone finished their onboarding labs, helped divide team mebers into subteams working on specific modules and components, kept track of what everyone needs. Rinse and repeat for every week since last update.

This week I gave a presentation on every pet-peeve I’ve ever had with bad presentations over the years, hoping it will help some people avoid the very common mistakes I have seen. The recording of the presenation is above, slides can be shared upon request.

Also made minor formatting changes to my DN, making sure it’s viable to serve as an example of standard formatting for the team.

Kevin’s Design Notebook

Hello, this is my design notebook

Week of 20 January 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1 CMake and Toolchains

This week was spent attending the orientation meeting for all members and starting with Onboarding Lab 1. I learned the specifics of what CMake does and how it is used. I have interacted with CMake before but I’ve never fully understood or interacted with it until now.

I was having some indecisiveness about how to submit the lab report. In particular I wasn’t sure how I should submit the lab itself. I decided to create one repository for all of the onboarding labs that I will do in order to keep all my work in a single repository.

Week of 27 Feburary 2023

Project Work:

• Onboarding Lab 2: Completed Lab 2 System Verilog

This week I completed the second onboarding lab. I got my first introduction to System Verilog and learned more about how unit tests are made and run. The lab itself didn’t take that much time. Instead I spent most of my time trying to figure out how the testing environment worked.

Week of 6 Feburary 2023

Project Work:

• Windows WSL Documentation: Completed first verison of Windows WSL documentation

This week I focused on creating the WSL documentation. I struggled for the first few days because I misunderstood the purpose of this documentation but after a discussion with Vito I was able to finish it in a couple of days. I was slowed down because I did not have a good way of testing my guide since all of my computers already have WSL installed so Vito will be going through this guide and providing feedback on what does and doesn’t work.

Week of 13 Feburary 2023

Project Work:

• Onboarding Lab 3: Completed Lab 3 Verification

This week I was planning on completing both labs 3 and 4 but was only able to finish lab 3 because I got stuck on some undefined behavior for C++ with bitshifts and modulus. Michael helped a lot by reminding me of an old message he sent about this issue a few weeks back. After he helped me I was able to finish the lab in a couple days without much issue.

Week of 20 Feburary 2023

Project Work:

• Onboarding Lab 4

This week I finished Lab 4 which was fairly straight forward. I had some trouble finding time to work on lab work before this weekend so I will be submitting this design notebook a little late.

Week of 27 Feburary 2023

Project Work:

• Windows WSL Documentation: Updated CMake installation section to get a more updated version of CMake.

This week I spent most of my time studying for midterms but I fixed the WSL documentation to install the correct version of CMake after Rishyak notified me that the normal install method doesn’t install the version that we use in our toolchain.

Week of 6 March 2023

Project Work:

• AHB Subordinate: Started reading up on the AHB Subordinate module.

This week I read up on the AMBA AHB module and familiarized myself with interfaces in system verilog. I initially thought the task would be fairly simple but its taking me a little longer than I thought to understand how it works.

Week of 13 March 2023

Project Work:

• AHB Subordinate: Setting up tests for subordinate.

I did not spend much time working this week due to Spring break but I switched from working on the System Verilog part in favor of working on the tests first but I was slowed down by my limited understanding of CMake.

Week of 20 March 2023

Project Work:

• AHB Subordinate: First draft of subordinate.

I made a lot of progress on the subordinate and pushed a first draft on the dummy subordinate to feature-11-DummySub and will be continuing test creation and refining of the subordinate.

Week of 27 March 2023

Project Work:

• AHB Subordinate: Creating tests for Dummy Subordinates

This week I had a little trouble getting the tests to build. It ended up being an extra include statement that was causing issues. Once that was fixed I started drafting up simple tests and fixing some aspects of the dummy subordinate as I went. Next week I will be adding more tests and implementing additional features described on the AHB documentation.

Week of 3 April 2023

Project Work:

• AHB Subordinate: Finished basic write and read test

Slow week this time due to other work and school but I was able to finish a basic read and write test for the dummy subordinate. I had a decent amount of trouble getting the project to build on my main computer so I gave up and did the work on my laptop instead. Currently working with Rishyak to figure out the issue.

Week of 10 April 2023

Project Work:

• AHB Memory Controller Subordinate: Started work on subordinate for memory controller.

Started work on the subordinate for the memory controller. I felt that since the dummy controller had basic reads and writes done, having an actual target component like the memory controller would be good for developing the more complex functions of the subordinate like bursts and transfer sizes.

Week of 17 April 2023

Project Work:

• AHB Memory Controller Subordinate: Continued work on subordinate.
• End of Semester Presentation: Started work on end of semester presentation

Continued work on the memory controller subordinate. I’m beginning to think that the state fields that I made on the dummy subordinate aren’t useful so I will see if I can finish the memory controller without the state.

Week of 24 April 2023

• End of Semester Presentation: Finished end of semester presentation

Unfortunately we weren’t able to present this week due to time constraints but I was able to watch the presentations for the other teams which were very interesting. I didn’t do any work otherwise due to final projects.

Michael’s Spring 2023 Design Notebook

Week of January 23, 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1.
• Onboarding Lab 2: Completed Lab 2.

This week was spent mostly on completing onboarding labs 1 and 2. I worked by myself to complete these onboarding labs. I also opened two issue reports about mistakes in the labs and they were resolved.

Both labs were a good post-break refresh on the basics of CMake, make, and Verilog.

Week of January 30, 2023

Project Work:

• Onboarding Lab 3: Completed Lab 3.
• Docs for Homebrew: Created documentation for using Homebrew on Mac to install the required dependencies for the onboarding labs.

This week was spent mostly on completing onboarding lab 3 with some time also spent on creating the Homebrew documentation. Overall, Lab 3 was very informative and helped me to better understand how to use C++ to test verilog modules.

For the Homebrew documentation, I had previous experience using Markdown but this was a good review and it was very helpful in understanding the structure of the website as I had to create a new section to add the documentation to (after trying to simply insert it into the lab section with poor results).

In the future, I want to add more explanations to the Homebrew guide about what the commands do as well as other useful features of Homebrew that may be relevant to this project.

Week of February 6, 2023

Project Work:

• Onboarding Lab 4: Completed Lab 4.
• Fixed Spelling Errors: Fixed spelling errors in onboarding documentation.

This week was spent mostly on completing onboarding lab 4. Lab 4 introduced a lot of new concepts and was very helpful in getting a better understanding of the toolchain we will be using. I did run into a few issues with CMake but Vito was able to help me out with the first issue and I resolved the other issues by switching from the GCC 12.2.0 kit to the Clang 14.0.0 kit.

I also took time this week to fix formatting errors and spelling mistakes in the onboarding documentation.

Week of February 13, 2023

Project Work:

• ALU Design: Created, implemented, and tested a design for a RISC-V-32I ALU.

This week was spent learning more about the RISC-V-32I instruction set and then designing an ALU to work with the instruction set. I designed the ALU in Verilog and used our toolchain to test the design. After several iterations, it passed the tests I designed and so should be fully functional.

Week of February 20, 2023

This week was mostly spent further reading up on the RISC-V-32I instruction set and thinking about what to implement next for the core. I already plan to implement a sign extension module to be able to feed the 12-bit immediate values into the 32-bit ALU module as I had decided against including sign extension functionality in the ALU module for ease of testing and simplicity.

Week of February 27, 2023

Project Work:

• Sign Extension Module: Created, implemented, and tested a design for a sign extension module for the 12-bit immediates.
• Module Paramertization Plans: Made plans to update the existing core modules to use parametrization and other applicable concepts from Lab 5.
• Core Design Project Plan: Created a project to organize and keep track of the progress of all the component modules that will make up the core.

This week was spent figuring out the future direction of the core design. I met with Vito to discuss the core and he provided me with some additional resources to look into for specifics on RISC-V core design. So far, we have decided to use a 5 stage pipeline design that people who took Computer Architecture should be familiar with.

We also discussed how to handle assigning modules to people to implement. To make it easier on people we plan to make outlines for the modules we need implemented so that when someone wants to implement a module they have a clear idea of what that module needs to do, what interfaces it uses, etc.

Week of March 6, 2023

Project Work:

• Parameterized ALU and Sign Extension Modules: Updated the ALU and Sign Extension Modules with parameterization for the word size.
• Created Issues for Core Modules: Created issues for each of the core modules that need to be implemented.

This week was spent adding parameterization to the ALU and Sign Extension modules as well as organizing and creating issues for the core modules that will need to be implemented.

Week of March 20, 2023

Project Work:

• Outlined Program Counter: Outlined required functionality of the Program Counter Module.
• Outlined General CPU Registers: Outlined required functionality of the General CPU Registers.
• Outlined IF/ID Latch: Outlined required functionality of the IF/ID Latch.
• Outlined ID/EX Latch: Outlined required functionality of the ID/EX Latch.
• Outlined EX/MEM Latch: Outlined required functionality of the EX/MEM Latch.
• Outlined MEM/WB Latch: Outlined required functionality of the MEM/WB Latch.
• Updated README with CPU Core Diagram: Added a work-in-progress CPU core block diagram to the core repo README.

This week was spent outlining various core modules so that people who want to start working on the core have specific and clear instructions for what each module needs to do and how it needs to do it. An outline for individual core modules that will interact with each other in the 5-stage pipeline was created and turned into a block diagram for the core.

Week of March 27, 2023

Project Work:

• Branch Evaluation Module: Created, implemented, and tested a design for the branch evaluation module.
• Outlined Branch Address Calculator: Outlined required functionality of Branch Address Calculator Module.
• Cancled Sign Extension Module: Cancled the Sign Extension Module since its functionality will now be included in the IF/ID latch module so it became redundant.
• Updated README with Updated CPU Core Diagram: Updated the work-in-progress CPU core block diagram in the core repo README.
• Assigned Program Counter Module to Uma: Assigned the task of implementing the program counter module to Uma.
• Assigned Module Creating and Testing Documentation Work to Uma: Assigned the task of creating clear documentation for designing and testing core modules to Uma.
• Assigned Module Functionality Documentation Work to Rielle: Assigned the task of creating clear documentation for the functionality of the core modules to Rielle.
• Started Outline For L1 Data Cache: Started the outline for the L1 Data Cache.
• Started Outline For L1 Instruction Cache: Started the outline for the L1 Instruction Cache.
• Started Outline For Branch Manager : Started the outline for the Branch Manager.

This week was spent outlining more modules and implementing the Branch Evaluation Module. I also started assigning module issues to members of the core team and reviewed pull requests from Uma for the program counter which eventually led to a fully functional program counter.

I also assigned some documentation issues as I want to get the documentation on how we create and test modules to the point where someone coming into the core team for the first time doesn’t have to go through the process of submitting a pull request only to be told they did not add their tests to the Cmake file or something similar.

I am very happy with where the core repo is as of now. However, there is still a lot of outlining work to be done and much of it is for the more complex modules like the general control and cache modules.

Week of April 3, 2023

• Rebased and Merged Documentation Pull Request: Rebased and merged Rielle’s documentation pull request.

This week was spent looking over and discussing the core repo documentation for the module functionality and development and testing process. This documentation should hopefully help onboard people quicker and make it easier for them to start implementing modules.

Week of April 10, 2023

• Created Module and Tests for IF/ID Latch: Created the module and tests for the IF/ID latch and verified functionality. Also updated the outline of the module to fix mistakes found in it.
• Split Cache Manager Module into Data Cache Manager and Instruction Cache Manager Modules: Split the idea of the cache manager module into two, having one for the instruction cache and one for the data cache.
• Updated CPU Block Diagram: Added the data cache manager and instruction cache manager to the CPU block diagram.
• Merged Module Documentation Pull Request: Merged another of Rielle’s documentation pull requests.
• Removed L1 Instruction Cache and L1 Data Cache Outlines: Removed the in-progress outlines for the L1 data cache and L1 instruction cache as the CPU will now directly interface with the cache controllers and no logic for interfacing with the CPU will be in the actual cache modules themselves.
• Merged Development Documentation Pull Request: Merged Uma’s developement documentation pull request.

This week was spent developing the IF/ID latch module. I created the module as well as tests to verify its functionality and was able to create a functional module. I did not get a chance to build the interface for the module yet but will do so once things like the CPU register module are completed so that I can test everything the IF/ID latch module interfaces with.

Week of April 17, 2023

• Merged Documentation Pull Request: Helped Rielle update her branch to be able to merge with the main repo and merged her documentation pull request for additional module documentation.
• Updated IF/ID Module Docs: Updated the IF/ID latch module documentation to match the functionality of the module. Also moved all the module and testing documentation into a single documentation folder with multiple subfolders and added hyperlinks to the module documentation to the readme.
• Made module input and output names consistent: When through all the modules, tests, and documentation to ensure a consistent naming and style for the input and outputs of the modules.
• Updated CPU Diagram: Updated the CPU block diagram with the updated input and output names for the modules.

The majority of this week was spent going through the existing modules, tests, and documentation to create consistent names for the various inputs and outputs. Every module was updated to ensure a consistent style of all lowercase for i/o names and then the tests, documentation, and CPU diagram were updated to reflect the new names. I then reorganized the documentation to put it all in a single folder; that folder then has two sub-folders, one for the development and testing documentation and one for the module documentation.

I also helped Rielle with her documentation pull request as there were initial conflicts that prevented merging the pull request with the main branch of the repo. Ultimately we were able to resolve the issue and successfully merge the request.

This week was also the first of what I hope to make weekly check-ins about team members’ assigned tasks. Currently. Uma is working on the CPU General Purpose Registers, Rielle is working on the Branch Address Calculator, and I’m working on the ID/EX Latch. Uma and Rielle are also both working on documentation for the repo which has been very helpful.

Week of April 24, 2023

• Merged Documentation Pull Request: Merged another of Rielle’s module documentation pull requests.
• Fixed Errors in Module Outlines and CPU Diagram: While working on my presentation I discovered a few mistakes in the overall CPU design so I corrected them.
• Updated ReadMe with hyperlinks Updated the ReadMe with hyperlinks to the rest of the module outline documentation.
• Gave Core Presentation: Gave the core design presentation.

Most of this week was spent working on the core presentation and fixing various mistakes in the CPU design I discovered in the process. The two big issues I found were that I had mixed up where the register and ALU outputs went for accessing memory and that I forgot to account for the different word sizes that can be used to read from or write to memory. They were relatively simple to fix but I spent a decent chunk of time doing it as I needed to update everything from the schematic, to the module outlines. It also didn’t help that I was in the middle of working on the presentation which involved a color-coded schematic where each pipeline was a different color. Fortunately, GIMP’s selection tools were easily repeatable and it saves the colors I used so my color-coded diagrams were easy enough to recreate.

The core presentation went well. It ran longer than I thought it would but I don’t think it was excessive and I covered everything I felt I needed to. I doubt it will be that helpful for onboarding future core team members but it was good for me to get all the design goals and accomplishments in a single place and to have a record of the design as it stands today for reference when questions about the design arise in the future.

As finals approach, I expect work on the core repo will slow down a bit. Fortunately, the progress made up to this point has been quite substantial, especially given our small team size. I’ve currently assigned myself the ID/EX latch module to implement but that will probably be on hold for a bit as I want to outline more modules in hopes of having easier onboarding next semester. For modules like the General Control Module, Hazard Detection, Processor State, Cache Managers, and Branch Predictor, I wonder how practical our current approach to outlining will be. These are far more complex modules so I want to spend time writing a high-level overview of their functionality that can hopefully later be translated into our standard outline. I already have a basic overview of how they will work in my head so I just need to translate that into writing that others can easily understand.

The modules I will probably need the most help with are the caches. I am familiar with how caches and caching work, but most of my intuition for things like the size and distribution of the caches is based on modern multicore 64-bit X86-84 and ARM-64 CPUs. I will need to get information from the memory team on the size and layout of the memory as well as the overall memory map so I know what addresses correspond to ROM vs RAM. Our caches will also all be SRAM based so I’ll need help from the memory team with creating those using openRAM. The physical layout of the core is also important for the caches, as L1 needs to be the closest to the core followed by L2 then L3 then RAM.

Week of May 1, 2023

• Updated and Fixed ALU: Updated and fixed the ALU opcodes
• Updated Documentation: Updated documentation for various modules

The majority of time this week was spent working on outlines for modules, specifically for stuff like the cache managers and general control module. As I expected, things are slowing down as finals approach but we are still making good progress.

Vito’s Design Notebook

This is a teamleiter, it leiters the team

Week of 23 January 2023

Project Work:

• First three labs more or less done:

  • Docs for lab 1
  • Template for lab 2
  • Template for lab 3

• Most of the initial getting started docs are done, but require more work on ironing out practical problems students will run into managing git and especially fast-forwarding commits from upstream onto their origin repos

• Reviewed and merged DNs from team, some examples of feedback provided:

  • Uma PR
  • Sean PR
  • Rishyak PR

• Project page for Phase 1 has some objectives filled in but still needs more concrete guidance on tasking, hoping to deligate this stuff out to project czars once the team is more up to speed on development process

Still trying to get all the material we need to zero-to-sixty incoming students. Generating useful lab material is a larger challenge than anticipated but I need to also keep in mind things that take me minutes will sometimes challenge students for 30+ minutes or an hour because of large deltas in pre-req knowledge.

Also still working on a good general compute environment. Experimented with an Anubis playground, but memory and storage limits quickly made it non-viable. Local development guides are perilous, but might be the only way forward.

Week of 30 January 2023

Project Work:

• Developed new test flow
• Created Lab 4
• Reviewed, provided feedback, and merged student DN PRs per usual.

Chugging away on creating labs, hopefully the last few (which involve less tutorial and more exercises) will go faster.

New test flow is hopefully an improvement, as we move to a single executable/Catch2 managed testing paradigm. Building the codecov report generator as a static lib might be a mistake, as it requires some build-system hacks and finalizing the linking provides no benefit. Need to look into building it as an object lib.

Example Entry for Meeting

Hello World there’s song that we’re singing

Rishyak’s Design Notebook

This is Rishyak, he does processor-designer-ey things.

Week of January 22, 2023

Project Work

• Onboarding Lab 1: Completed lab 1 on toolchains
• Onboarding Lab 2: Completed lab 2 on SystemVerilog

Comments

I met the processor design team during orientation on January 23, 2023.

After much preparation, I started onboarding labs on January 27, 2023. I had to upgrade some dependencies but I was familiar with everything for lab 1.

I also finished the second onboarding lab on system verilog. I had to look up Fibonacci LFSRs and some Verilog syntax but the rest was fairly straightforward. I think it would be convenient if this lab had some more hand-holding. For example, a simpler example at the start for a quick revision on Verilog, or perhaps even a short explanation on LFSRs because CS majors don’t really talk about them ever.

Good labs.

All repositories could use a standardised contribution guideline to familiarise team members with team policies.

Week of January 29, 2023

Project Work

• Onboarding Lab 3: Completed lab 3 on verification
• Repo Cleanup: Cleaned garbage files on repo
• Markdown Cheatsheet: Added a Markdown cheatsheet for reference.
• Minor Fixes: Fixed typos and missing URL’s.

Comments

I finished the last available onboarding lab at the moment. Verilator-based verification wasn’t an issue for me since I have used both, Catch and Verilator before. I faced an issue with exercise 3 which was the tiniest, silliest bug.

Good lab.

I don’t expect people to have their text editors set up to format on save, so documentation should probably touch on that as well.

Fixed some tiny things I saw like extraneous files in repositories or typos or missing URL’s.

Week of February 5, 2023

Project Work

• Onboarding Lab 4: Completed lab 4 on verification toolchains
• Git Documentation: Modernised git documentation.
• CONTRIBUTING.md: Created a contribution guideline
• VM Creation: Created a plug-and-play VM that team-members can use as a native Linux environment
• VM Documentation: Created a guide for installing and using the above VM
• New position: Czar of all things AMBA

Comments

Finished the last currently available lab on verification toolchains. This was easier than expected since I did a lot of the adaptation work last week already. All I had to do was write the toolchains.

I discovered that the instructions were missing a vital piece of information which I spoke to teamleiter about.

Good lab.

I feel iffy about just blindly using nyu-cmake and nyu-util so I’m gonna spend the week looking into that so I don’t feel iffy about using them.

Got sick of the GitHub “community health” notifications and decided to make a CONTRIBUTING.md for the entire team to follow.

I also created a VM for team-members looking for a native Linux experience and a corresponding installation and usage guide.

In my quest to czar the AMBA department, I have finally caught up on all backlog so I can dedicate my week to memorising the AMBA manual and looking into Verilog I know very little about. Shouldn’t be too bad.

Week of February 12, 2023

Project Work

• Documentation: Cleaned up development environment documentation

Comments

Dry week after the last one. I read some of APB manual but I was quickly reminded to focus on homework that I keep procrastinating on.

Did some documentation clean-up and maintenance, but nothing too much otherwise.

Week of February 19, 2023

Project Work

• AMBA:
  • AHB Interface: Updated the AMBA AHB interface
  • APB Interface: Created the APB interface
  • Toolchain: Cleaned up the toolchain on the repo
• Git usage: Helping people collaborate easier on Github

Comments

Spent the week reading the AMBA manuals and implementing their interfaces. We decided to implement burst transfers and protected transfers on the AHB. The APB interface has been pushed too. The first step is to add a UART on the bus. Before adding a UART, I want to spend time working on the AHB.

Other than that, checked some PRs and left comments on how to use git easier. Those comments will be moved into a guide on the website for easier access some time this week.

Week of February 26, 2023

Project Work

• Onboarding Lab 5 (Part 1): Read through the lab
• AMBA: Added a summary of AMBA components for new AMBA team members

Comments

I went through the onboarding lab as soon as it was released. I knew a lot of it through my conversations with Vito or just looking things up. For example, I figured out what SystemVerilog interfaces are to work on the APB and AHB interfaces

I also wrote a summary of the AMBA components so new team members don’t have to parse the whole manual to work on their individual component. The purpose isn’t to avoid reading the specs, it’s to provide context so they don’t have to research things on their own. A dump of my current knowledge, in a way.

I also came up with action items for potential AMBA team members. They will be tracked on the repo’s issues and on the projects page.

Week of March 5, 2023

Project Work

• AMBA:
  • APB Bridge: Added WIP Bridge and comments for APB.
  • Memory Controller Subordinate: Added a WIP memory controller subordinate
  • Toolchain Updates: Updated the CML and vcpkg files
• MEM:
  • Cleanup: Proposed gitignore cleanup
  • Toolchain Setup: Set up the toolchain
  • Memory Interface: Set up the common memory interface to interface with the AHB subordinate

Comments

I spent the week finishing finals week and checking out. However, I started working on the APB bridge, finalised the AMBA team for now, and did some general admin work for that repo.

I consulted with documentation czar Uma for work on my repo. I also helped Siddharth with the onboarding labs.

My team will meet with Sean to discuss the interface for the memory controller so it can interact with the AHB. I have a general idea of what needs to be done, I just want to ensure we’re on the same page. My general idea currently exists in a PR on nyu-mem.

Week of March 19, 2023

Project Work

• AMBA: Over-the-air support

Comments

The first week back after spring break was a dry one. For the most part, I provided support and advice to Kevin who was working on the dummy subordinate.

I attempted to package AMBA but vcpkg documentation got the better of me. After talking about how it works, I have a better idea.

Week of March 26, 2023

Project Work

• AMBA
  • Manager: Designed the manager
  • Interface: Added relevant modports
  • Documentation: Added amba spec in PDF form
  • Other small fixes: Wrong bus widths, missing signals, typos, and the like.

Comments

Spent this week making tiny changes and tweaks to the repository that were discovered as Kevin was working his way through SubDummy. In building files, more bugs came up. They were extinguished appropriately.

I also learnt a lot about how SV packages work, in practice and with CMake. Unsurprisingly, vastly different but now how you’d expect. It’s also this way because of how our toolchain is designed and isn’t a universal solution.

Week of April 02, 2023

Project Work

• AMBA:
  • Toolchain: CMLs for testing and directory reordering
  • Actions and Coverage:
  • Manager: Started working on the manger

Comments

I started the week off strong with a lot of changes to the AMBA repo.I wanted to make the toolchain easier to use for new team members and also enable coverage and testing through actions.

Lastly, I started implementing the manager so we can have the main thing for AMBA out of the way.

Week of April 09, 2023

Project Work

• AMBA:
  • Manager: More work on the manager
• Documentation:
  • VS Code Extensions: A list of VS Code extensions to make your life easier

Comments

This week I continued my work on the manager. Turns out, the manager is a big pain to implement. The spec is quite vague with it’s descriptions and AHB discussion forums just want you to “buy it from a vendor”. We push through nonetheless. I don’t think it’ll be that hard once I talk through some of the questions.

Additionally, in working with Kevin on AMBA, I realised that the team isn’t aware of some VS Code extensions that I usually use. So, Uma and I compiled a list of recommended VS Code extensions that will be helpful for people.

Week of April 09, 2023

Project Work

• AMBA
  • Manager: Made more progress on the manager
• VIP Fair: Spend a couple hours talking to people at the VIP fair
• Final Presentation: Thought about the project presentation

Comments=

Once again, I continued to work on the manager but I couldn’t do much due to a weirdly challenging project for another class.

I intend to finish the manager this semester but I am in a significant time crunch this week and the next.

I also spoke to Kevin about our final presentation.

Swarnashri’s design notebook

Hello, this is my VIP NYU Processor Design notebook/journal.

Week of 23 January, 2023

• Onboarding Lab 1: Completed Lab 1.

This week I spent some time going through the VIP Course Notebook, and completed Lab 1. I created a CMakeLists.txt file and sample C++ code files and could build them without any issues. I haven’t tried Anubis yet. I will try that out next week along with Lab 2.

Week 1:

Onboarding went on pretty smoothly. Got a taste of the environment we’ll be using to design our processor.

Attempted and finished Lab 1. Got exposed to CMake Toolchain, and how CML works. While attempting the quests for Lab 1: make des not work on windows. Would not geenrate a makefile and thus used cmake –build . instead. When attempted to build on VsCode, ran into some minor issues with the header file missing directory even when specified in the CML using target_env_variables.

Also, Started reading up on using verilator.

Week 1 of February 2023 (week 2 lab)

• Onboarding Lab 2 : Completed Lab 2 SV exercises.

Discussed the possiblities/alternatives for a new working environment for windows users since i’m struggling with the commands not indigenous to windows for CMake. After a great meeting on thursday, I plan on shifting to linux / Vs / Chocolatey / GnU for a better integration environment since CMake is the go to for us. Will take some advice from peers regarding the same. Opted to do writeups for the team on some verilog modules for the coming week. Shifting gears and starting the rest of the labs sooner.

Week 2 of February 2023 (week 3 lab)

• Onboarding lab 3 : Completed lab 3 verification exercise.

I actually tried to ask chat GPT to make the verification for the modules discussed in week 3 of our lab. The results were very different and not how we coded our testbench, GPT made use of verilator commands and directly sourced the testbech from the command. Eager to know if we can use the same. Also, I might not be the best at testbenches and may have done some errors in this week’s lab. If i could have more sources for the same, it would be helpful.

Week 3 of February 2023 (week 3-4 lab)

• Onboarding lab 3 : Reverification of testbenches in C++

Got too caught up in academics and job search. The VS Code environment set up as disucssed with vito and reverification of testbenches are going to be pulled early this upcoming week along with lab 4. Excited to start work on the actual design soon. Been practising my verilog concepts through my graduate course so be rest assured i’ll be upto the mark since I have been practising the same for Hack@DAC 2023.

Sean Doyle Design Notebook

Welcome to my Spring 2023 design notebook.

Week of 23 January 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1

I completed the first lab this week which was all about using cmake and make files. The lab went pretty smoothly for the most part however I could not get cmake to make the Ninja build system files. When I tried running the commands in the tutorial cmake came back to me with errors because I did not have the following set:

CMAKE_MAKE_PROGRAM

CMAKE_C_COMPILER

CMAKE_CXX_COMPILER

I believe these are just settings within the cmakelist file that need to be set so if we need to use ninja in the future I’m going to have to look into that. I also did not realize I should put the lab in a git repo to link it here so I ended up doing the lab in its own separate directory and copying to a git repo afterwards and making one big commit. As a result the repo linked here does not really show a natural progression of my work but that’s just a first VIP notebook entry issue. Finally, I would normally set git to ignore the build directory but for the sake of showing I completed the lab I did not do this and included them in my commit. I’m not sure if this is the correct thing to do but it felt like it made sense. Overall the lab went pretty smoothly and I have a much better understanding of Cmake and make.

Week of 30 January 2023

Project Work:

• Onboarding Lab 2: Completed Lab 2

• Onboarding Lab 1: Fixed Ninja build system in Lab 1

I completed the second lab this week which was all about system Verilog and completing exercise related to it. The first exercise was not very hard, however I struggled with the second exercise. I had never used a Fibonacci Linear Feedback Shift Register before so I had to look online to see what it did. I started by following this site but I notices that the pseudo code in that website was putting bits into the output on the opposite end as what the test cases expected. I ended up looking at the test creation code to figure out the specifics of the algorithm (which bits corresponded to which taps and what end of the output to append the new bit) because I couldn’t get the pseudo code from the above website to pass the test cases.

I also struggled a little bit initially with exercise 3 because I thought I had to import the mystery modules on my own. I did not realize that they were automatically included until I looked at the cmake file so I spent a good 10 or 15 minutes trying all possible pathways I could think of to import the mystery modules. :laughing:

After finishing lab 2 I went back and took another look at Lab 1. Based on the discussion at our meeting this week I went to this site and installed ninja for my mac. After doing this I re-did the ninja section of Lab 1 and had no errors!

Week of 6 February 2023

Project Work:

• Onboarding Lab 3: Completed Lab 3

I completed the third lab this week which was all about testing. It went pretty smoothly all things considered but I just ran into a bunch of small problems that made things take longer. None of these were very significant, they were were mostly me misunderstanding how the actual code was intended to work and as a result my tests did not verify the code’s function correctly. Also, for my exercise 4 tests I decided to test all possible inputs which takes about 30 seconds to do. If this were production code I would likely modify these tests to use randomness to pick a subset of inputs but I wanted to get a better feel for the limits of bruteforce testing all possible inputs.

This week, I also created a script that automatically built, made, and ran the tests within the toolchain because I got sick of typing cmake .., make, and then the test command over and over again. Additionally I started to work on some documentation for GitKraken which is the tool that I use to manage local git repos.

Week of 13 February 2023

Project Work:

• Onboarding Lab 4: Completed Lab 4

I completed the fourth lab this week. It went pretty well however at the very end I tried compiling my code by running cmake and for some reason it compiled for ninja not for make. I went back through the original tutorial, double checked all of my work and then tried running cmake again, and it still compiled for the ninja build system. I cleared my build directory and recompiled and only then it created a make file. I’m not sure why this occurred but it was pretty confusing for a bit. Other than this minor hiccup the lab was pretty self-explanatory and went well.

Week of 20 February 2023

Project Work:

• GitKraken Documentation

This week I began looking at the Risc-V documentation [here] (https://riscv.org), [here] (https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/notebooks/RISCV/RISCV_CARD.pdf), and in the spec manual. Most of it I do not understand yet but mostly I was hoping to get acquainted with the resources that way when I do have questions in the future I know where to look for answers. I found that the core instructions link that I referenced above to be the most helpful as that gave me a good idea of all the functionality that we will have to implement.

I also continued working on the GitKraken documentation that I started a few weeks ago. I added sections on committing, pushing, pulling, merging, switching branches, and creating new branches so it is pretty close to ready. I think I will add a few more pictures and then beta test it on someone before putting in a PR. Not sure when this will be because I don’t think this documentation is high priority but if I have some down time in the next few weeks it could be pretty soon.

Week of 27 February 2023

Project Work:

• Onboarding Lab 5

This week I completed the fifth onboarding lab which was all about advanced System Verilog syntax. It made sense overall and I liked learning about interfaces and how they can be used to explicitly link Verilog components together. I didn’t quite understand the difference between nets and variables because this section of the lab felt pretty technical and kind of flew over my head. It might have helped to see some examples so I might look up example code and add it to the lab to help others that struggled with this section too.

Week of 6 March 2023

Project Work:

• NYU-Mem Repository

This week I created the NYU-Mem repository. After talking with Vito I created the issues for the following tasks:

• Mapping out the interface between the memory controller and the HPB
• Implementing the memory control unit
• Creating a decoder for ROM/RAM
• Translating Hex to Verilog for ROM storage.

I then hopped on a call with Rishyak and Kevin and we looked over a PR that Rishyak had created for the mem repository that had an interface between the memory controller and HPB mapped out based on chats we had been having throughout the week. We deciding on adding a response flag but other than that kept what Rishyak had coded up.

Week of 13 March 2023

– Off for Spring Break –

Week of 20 March 2023

• NYU-Mem Repository

This week I worked on the memory controller in the NYU-mem repository. I worked with Vito on interfacing the NYU-mem repo with the Amba repo so that I could have access to the memory interface inside the controller. Also, I began researching more into OpenRAM and read this paper on the tool. I don’t fully understand how it works as I am kind of confused by the diagrams on the third page of the paper which show switching signals mid clock cycle to perform read and write operations, but I plan on digging more into this in the coming weeks as I imagine it will be pretty critical to implementing the memory controller device. I also cloned the OpenRAM repo and built the project, however, I cannot figure out how to run it to create any RAM designs. I’ve been a bit frustrated with the lack of documentation for OpenRAM and have yet to even find a good “Hello-World” OpenRAM tutorial for memory generation. Finally, I got Nicky started on implementing a hex to Verilog decoder that will be used later to implement the ROM on our processor.

Week of 27 March 2023

• NYU-Mem Repository

This week I started off by trying to implement the control signals outlined in this article on pages 15-16. I added the control signals and timing code to the memory controller module and implemented an OpenRAM interface that could interact with OpenRAM generated memory. I could not get the code to compile with the nyu-cmake functions so I reached out to Vito to see what I could modify to enable timing controls. After talking with Vito, he told me that it would be more beneficial to create a script to generate the OpenRAM memory that my code would interact with so I am going to redirect my efforts in the coming weeks to understanding how OpenRAM works and how to generate memory with it. I also improved the documentation in the NYU-mem repo. I tried to model the issues after the nyu-core issues and also added an issue for the OpenRAM memory generation code that I am working on now. I added a few new labels to the issues that I already have to provide more details on their status.

Week of 3 April 2023

• NYU-Mem Repository

This week I generated memory using the OpenRAM library for the first time. I followed this tutorial and created a simple configuration file for OpenRAM to run on. It took longer than expected to follow the tutorial because I installed OpenRAM in a different location than where they specified but after working out these details it generated memory perfectly fine. I then installed an application called Layout Editor in order to open the GDS file generated and got to see a visual representation of the memory generated. I also looked at the Verilog memory file generated and compared it to the sample one that Vito sent me. They looked very similar to one another which was good to see. I plan on learning more about the parameters that I can customize in the OpenRAM config file and documenting my steps to generate memory on this repo website in order to allow people in the future to re-create the memory I made.

Week of 10 April 2023

• NYU-Mem Repository

This week I continued to generate memory using the OpenRAM library trying out different parameters in the config file. I found this website which gave be a lot of useful information on what the parameters of the config file all do, and I changed the word_size and num_of_words to increase the amount of memory generated. The actual memory generation then took a lot longer than expected so it seems like OpenRAM is doing some pretty heavy calculations to create these large memories. I then tried to generate ROM and found limited success there. I started by setting the number of r/w ports to 0 and the number of read only ports to 1 because I thought that would generate memory that was only readable. This caused a bunch of errors to occur none of which I could solve. I ended up reaching out to the creator of OpenRAM halfway through the week and he told me that was the wrong way of generating ROM and he pointed me to the most recent release of OpenRAM which had a specific ROM generation script that I could run on some sample ROM config files. I updated OpenRAM and tried running the ROM generation script but still couldn’t get it to work. The ROM script relied on this technology called sky130 which I could not get installed based on the OpenRAM instructions found here I thought it might be an OS issue as all of the instructions and downloads are written for linux, so I reached out to Nicky halfway through the week to see if he could run the ROM compiler on his Linux VM. We still could not get it working by the end of the week so I asked Nicky to send an email to the OpenRAM creator as well just so that he knows a few people are experiencing the same issue. I also added an issue to the OpenRAM repo to add more ROM generation documentation because the OpenRAM creator asked me to do so in our email exchange.

Week of 17 April 2023

• NYU-Mem Repository

This week I worked primarily on documenting all the steps necessary to download OpenRAM and generate memory. I create an instructions Markdown file and wrote down instructions for OpenRAM installation, RAM generation and ROM generation. I also added more information on the files that should be generated and some extra resources to learn more about OpenRAM. I sent this documentation to Krzysztof and Uma and they both liked it. I also cleaned up the repository and added various files to the .gitignore to keep the repository clean in the future.

Week of 24 April 2023

This week I finalized my parts of the end of semester presentation that Nicky and I gave and then practiced my presentation a few times. I focused mostly on how to generate RAM and walking my audience through that aspect of what I did, but I also included more information on the future scope of the memory team. On Thursday, Nicky and I presented our information and it went really well. To wrap up work this semester I plan on just getting more people to try out the OpenRAM instructions that I made and have them let me know what problems that they run into.

Week of 1 May 2023

This week was pretty lowkey from me with processor design VIP work. I went to the meeting on Thursday and listened to the presentations from Vito, Rishyak, and Kevin. I also sent out a few messages to people asking them to try out my instructions to generate RAM documentation and then followed my own instructions one more time from scratch to make sure they made sense.

Uma Nachiappan’s Design Notebook

A confused Doc Czar and her Processor Designing adventures…

Week of 23 January 2023

Project Work:

• Onboarding Lab 1: Completed Lab 1

This week, I explored the tools on our Anubis IDE and started understanding more about how to use git and GitHub. I completed lab 1 from the onboarding series and learned about toolchains and CMake, and how to implement them to run simple programs.

I struggled a bit with linking my directories and files created in Anubis to my GitHub repository, but with a bit of Googling and with help from the VIP website guides, I was able to push my directory to GitHub and link it above.

I will be unable to complete Lab 2 next week, but I will work on both Lab 2 and 3 during Week 3 (Feb 5-12).

Week of 6 February 2023

Project Work:

• Onboarding Lab 2: Completed Lab 2
• Onboarding Lab 3: Lab 3 In-Progress

I worked on Lab 2 and 3 this week with the intention to finish both by the weekend but alas, going to India for a week without internet means Lab 3 is a work-in-progress.

For Lab 2, I initially struggled with Exercise 2 until I searched up what a Fibonacci linear-feedback shift register was. After finding a diagram of how the component works, it was fairly simple to build the module. I needed a quick refresher on the always_comb statement, since I haven’t used it before. Overall, this lab was a good review/practice of Verilog after taking Digital Logic last semester.

In Lab 3, I completed Exercises 1 and 4, which were the ‘simpler’ multiplexers. I was a bit lost on how to start the code for the tests, but I took a look at the dv directory and module tests from Lab 2 as examples. I feel like my code is okay, and they work as desired, but there is likely a more efficient way to write those programs. If I get the chance/time, I want to take another look at my submissions for 1 + 4.

Next week, I want to finish off Lab 3, and try to complete Lab 4 – hopefully I’ll be able to catch up!

Week of 13 February 2023

Project Work:

• Onboarding Lab 2 Docs: Added LFSR diagram

Due to some personal issues, I am still behind on my partially-self-designated timeline. My progress on Lab 3 was on hold this week, but I’m determined to get Lab 3 and 4 completed next week.

I attempted to set up WSL on my laptop, but I ran into problems when I tried to install the additional packages (CMake, Verilator, etc). I tried to update Ubuntu, then install these packages, but it still wasn’t working for me. So, I decided to switch to setting up a virtual machine using VirtualBox instead. Fortunately, this worked out well, and I now have a functional Linux VM for future project work.

I also made a diagram/schematic for a Fibonacci LFSR for Lab 2 Exercise 2, and created a messy pull request to update the lab docs. This created a mess within my fork of the upstream repo, since I was trying to push from my main branch instead of creating a temporary branch for my changes. A huge shoutout to Rishyak who helped me clean up my fork and also taught me important info about Git and Github (including some very useful git commands).

Week of 20 February 2023

Project Work:

• Working Collaboratively Docs: Created and updated guide for Collaboration

This week, I drafted a guide for working collaboratively that included pull requests, issues, teamwork, and working on team repos. I added a few sections about forks from Rishyak’s suggestions, but there are still a couple of questions/changes I’m probably going to make after I get some more feedback. I have found that I kind of enjoy writing documentation and guides, and I’m getting more used to markdown syntax LOL. I didn’t have much time this week due to the start of midterm season, so I’m still working on the labs and I unfortunately submitted this DN quite late.

Week of 27 February 2023

Project Work:

• Onboarding Lab 3: Completed Lab 3
• Documentation: Mini-Lecture

It’s been 84 years… but I finally finished Lab 3. I was procrastinating on Exercises 2 and 3 since I wasn’t sure where to start, but I took inspiration/clues from the tests of Exercises 2 and 3 from Lab 2, since the questions were similar. Mostly just relieved that this lab is completed and I can get going on Lab 4 next week before spring break. I feel a lot better about working on Lab 4 since it looks like some of the work is based off of Lab 3, which is now done.

I’m also learning the art of asking for what I want, so I am now appointed as Documentation Czar :) I wrote one guide and decided I wanted more, so here we are. I’ve started drafting a docs-ified version of Vito’s mini lecture on the structure of our future chip, but I don’t have a GitHub file yet since I’m trying to avoid a long gross commit history. I’m also going to meet with Vito next week to talk about the other roles & responsibilities of the Doc Czar.

Week of 6 March 2023

Project Work:

• Onboarding Lab 4: Completed Lab 4
• Documentation: Edits for AMBA ReadMe & AHB

I managed to complete Lab 4 before spring break, but I am aware that there are probably a few issues - I still need to do some testing/debugging. It is not my best work for sure, but under my self-appointed time crunch I am glad it is completed and I can start thinking about what component I want to work on.

I also completed my first Doc Czar job - Rishyak asked me to take a look at the AMBA repo docs and check clarity and understanding. I made a PR for a couple of typos & other relatively small edits, but overall the docs were already well written.

Despite bringing my laptop with me during spring break, I did not get a chance to work on Vito’s lecture - but I have a clearer idea of what is needed after talking to Vito, so I want to get a good chunk of the draft this week.

Week of 20 March 2023

• Core: Created PC Module
• Onboarding Lab 5

Coming back from break kicked my butt a little – so sadly did not get as much VIP work done this week as I would have liked. I read through Lab 5 for a better understanding of Verilog, then joined the Core team and implemented the PC module. I didn’t get a chance to write the tests before submitting this DN, but testing the PC should be fairly simple anyway - will hopefully be able to link the tests and a PR to my DN for next week.

I know I signed up to be Doc Czar, and I am still committed to the role - this was unfortunately a very weird week (personally and academically) so my documentation work was at a standstill from before break.

Week of 27 March 2023

• Core: Finished PC Module & Testing
• Documentation (general): Delegation with Rielle
• Documentation (Core): Development & Testing Process

I PRed a first version of the PC module and test, but Michael pointed out that I didn’t edit the CMake files, and I realized myself that my test program was written under sleep deprivation and therefore, was utter nonsense. I redid the test, edited the CMLs, and re-PRed… and success! The Verilator check passed and my module was merged.

Rielle has decided to join for me documentation, so we discussed the current docs to-do list, as well as what would happen in the future after significant module implementation. I also took charge of the docs issues in the core repo, namely a document explaining the development and testing process, and a folder that holds the outlines for un-implemented modules. As I was working on the first, I delegated the outlines to Rielle. I PRed a draft of the dev process doc, and Michael suggested a few edits that I can get done the upcoming week. After that, I want to claim another core module and get some work done on the still unfinished lecture.

Week of 3 April 2023

• Core: Claimed General Purpose Registers
• Documentation (Core): Development & Testing Process addition
• End-of-Semester Presentation: Created Group(s) + Topic

I added a “Best Practices” section to the Core docs I drafted last week, although I will probably add a few more tips as I think of them/they are suggested to me. Currently looking for any other docs issues and working on the lecture looming over my shoulder LOL.

I’m teaming up with Rielle for the end-of-semester presentation - we’re going to be discussing documentation and our similar learning curves regarding git and GitHub. I will also be contributing to Michael’s presentation about Core, since my official development work has been for this repo.

Very last minute before this DN, I claimed the CPU General Purpose Registers so I will be implementing these next week - now that I know how to properly test them.

Weeks of 10 and 17 April 2023

• Core: Implemented General Purpose Registers module
• Documentation: VSCode Extensions Compilation
• Documentation: Memory Docs Check
• End-of-Semester Presentation: Outlined Presentation

Big OOPS on my part, forgot last week’s design notebook.

I created the module for the registers that I claimed 2 weeks ago, and I outlined the verification tests that I have yet to write the full code for. Got caught up in midterms/finals :(

Got a request from Rishyak to compile some useful VSCode extensions that he has been using. I don’t have a proper commit for it yet but it is mostly done, I promise. Will hopefully PR in the next few days. Sean also asked me to check out some documentation for the Memory repo - looked good so far.

Rielle and I created an outline for what we wanted to discuss in our end-of-sem presentation and took charge of whichever topics we were most comfortable with.

I have a lot of loose ends to wrap up this week, but hopefully I can get everything done while not failing Algo.

Week of 24 April 2023

• Core: Created Draft of Gen Regs Test
• Documentation: PR’ed VSCode Extensions
• Documentation: Core Docs to Wiki
• End-of-Semester Presentation: complete! :)

Once again, I’m very late for the DN entries. My only excuse is finals season :(

I created verification tests for the general registers module, but I think I’m losing it because something was not working properly. It’s probably a tiny error that I missed because I wrote the test at… 2 am. Fixing it this week and will hopefully PR to core by the end of the week.

I PR’ed the VSCode extensions doc, but have not merged yet because I want to get the changes/edits done once and for all before the semester ends. If I don’t get to editing by Friday I will merge and make the changes later.

I transferred the Core Documentation to the repo Wiki per Michael’s request. Glad that Rielle and I could close out the Docs issues.

We finished the end of semester presentation! Relieved that a) it was on Zoom and b) it was not solo because I am a bundle of nerves

Still tying up loose ends and trying not to lose track of time… We shall see how the last few weeks go.

Papers

The following are papers and presentation authored by ProcDesign team members:

• Michael Lippe, NYU Processor Design Team SoC CPU Core, May 6, 2024.

• Vito Gamberini, Design and Construction of RTL Toolchains at NYU, A report on the toolchain work performed by the NYU Processor Design Team, May 20, 2024.