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