Amelia’s Status Report for April 12th

This week I have been working on debugging my client side code as we ran into some bugs while integrating multi client. I’ve also been working on a script to install all necessary dependancies for new users. All code can be found in my github.

For next week, my goals are to have the code fully debugged and to start doing some user testing (currently Anirudh and I have tried out multiclient but it would be good to get at-least one more concurrent user tested). I also plan to start working on the video that we have to include in our final presentation. I am on track however this next week looks busy so I plan to try to get all of the code debugged asap to stay on track for the final two weeks.

Amelia’s Status Report for March 29

This week I worked on finalizing the client communication with the FPGA based on how Anirudh and Andrew configured it (in terms of where data ready flags are set and where output data is sent). Although we have accepted that there will be some resource starvation in our multi-client implementation, I ensured that when the client accesses the flag that signals the FPGA is ready to receive data, that is an atomic action that prevents other clients from simultaneously trying to send their prompts. This also simplifies the process of ensuring the correct data gets to the correct user, since now the only client who will be looking for data from the FPGA will be the one whose request is being processed. I also updated the lua script to read the FPGA data out of a file the python script scps back to the client device. Everything on the client side is now ready to be integrated with the FPGA side. My repo with the code I’ve been working on can be found here.

I am on schedule and completed everything I planned to complete this week. My goals for next week are to have successful interim demos and also integrate my scripts with the hardware.

Amelia’s Status Report for March 22

This week I focused on getting the UI script to automatically ssh into the fpga and then read an “in use” flag that tells the program when the FPGA is available to send a new query. The main challenges with getting this all working was that the client script needed to concurrently check for the “in use” flag and also the input from the user when the lua script is triggered.

Here is a link to my github repo for the code so far: repo

I am on track in terms of getting my scripts ready to integrate with the FPGA and met my goals set last week. Looking forward, we plan to integrate next week, so I can’t say for certain what I plan to work on but my main goal is to get a functional integration of all of our work together so that we have something concrete to show for the interim demo.

Amelia’s Status Report for March 15

This week was a little slow for me as I had a couple midterms and other things I needed to focus on. My goals for this week were to look into pulling power data from the FPGA and get some ideas about how to implement multiuser authentication. I did not have time to look into multiuser, however I figured out how to pull power data from the FPGA and also developed a framework for obtaining power data for our accelerated hardware and not the softcore/everything else on the board.

To read power data I plan to use pynq, since there is a power management module that will allow us to use built in libraries to access power data from the PMIC on board. I also looked into monitoring data overtime to track for heavy use on our system. Most of my time was spent familiarizing myself with these libraries and waiting for our board to arrive so that I could play with the pynq tools once the board was booted. Another issue we ran into is that the PMIC transmits power data for the entire board, which is higher than for just our accelerator. to get around this, we plan to measure power before synthesizing our design and then use the delta of power before and after as our power rating.

I’m off track this week, so to get back on track next week I plan to pivot to getting a package ready for user testing (finalizing survey questions and making sure the repo is public). I also plan to implement a multiuser system with user log ins. Finally, I will be available to help get tokens streaming on the FPGA.

Amelia’s Status Report for March 8

This past week I did not do anything since it was spring break. The week before last I focused on getting the design review done before the Friday deadline. I did not spend as much time getting comfortable with the Vitis EDA tools as I had planned, however, I’m sure over the course of the next few weeks, having hands on exposure will be enough for me to figure things out. I therefore accomplished one out of my two goals from two weeks ago.  I think I am still on schedule.

Given I have quite a busy upcoming week, I plan to focus on figuring out how to pull power data from our new FPGA and also look into multiuser authentication as an extension to our UI. I expect these to be manageable goals for the upcoming week. I would also like to spend some time organizing our website.

Team Status Report for Feb 22

This week we focused on a few different things – the design presentation, which was mainly covered by Andrew,  UI development, which was covered by Anirudh and I (Amelia), and FPGA drama, which we all dealt with.

We finally got the UI setup scripts to work on other user’s computers – something we’d been working on. Once the set up process was finalized, we worked on a more usable interface that fits our use case requirements as laid out in our design presentation. We want to have the UI set up and run scripts completed soon because we plan to do some preliminary user testing while there is still plenty of time to make changes based on anything we learn.

The FPGA drama of the week was we found out that the Ultra96-V2 board we got is part of a broken batch that has non-functional wifi. Without the wifi, we can’t ssh into the board, so we had two options, either pick a new board, or obtain a wired uart extension board. We decided to try the Kria KV260, since that was another board we initially considered due to its greater memory capacity. Our initial hesitation with using this board was because none of us were familiar with Vitis, but after a little reading, we felt that we can learn how to use those EDA tools well enough to develop a synthesis flow. Now we may also be able to work with a larger model, which will give us more accurate text completions.

Group Goals for the next week:

  1. We have to complete the design review report for Friday
  2. Our new FPGA is arriving soon, so we need to start working on our new synthesis flows.

Amelia’s Status Report for Feb 22

This week I focused on getting the UI ready to be tested by users. I learnt the basics of LUA and edited Anirudh’s original scripts to support a text preview and then the user can either accept the auto complete or regenerate the response. The UI now utilizes two hotkeys – cmd G to prompt the model and cmd L to remove the output if it isn’t what the user wants. I wanted to get the UI finished early so that we can start preliminary user testing (likely after spring break).

The other main thing I was focused on this week was watching/reading some Vitis tutorials to learn how to synthesize softcores on our new Kria FPGA.

Preview of generated text

Goals for next week:

  1. make significant progress on the design review report as that is due Friday
  2. Spend more time getting comfortable with Vitis EDA tools

Amelia’s Status Report for Feb 15

I started off this week setting up the DeepSeek model I downloaded last week. While very interesting, after using the model and trying to find a way to prompt it to do text completion, I found that it is very much a chatbot with visible chain of thought. Therefore, we decided to stick with our original model.

I then pivoted to getting our UI set up on my computer, which required some debugging. I wanted to make sure the set up scripts were working because I plan to conduct some preliminary user testing next week. I quantified our metrics for usability, deciding on a setup time of at most 15 minutes and a benchmark of 100% success for users to reject or accept text completion suggestions, which is one of our system requirements. Finally, I worked on the design review presentation, making final block diagrams and quantifying technical design requirements.

The specified need our product will meet with consider of social factors is that it levels the playing field in terms of who has access to AI tools that support more efficient workflows for individuals. While many people can use text completion copilots to speed up their work, those working in data sensitive field cannot. This leads to a disparity across groups of who has more time to spend on more skilled aspects of their job, or more free time to spend doing other things. By enabling greater access to copilot tools, our product effectively enables greater access to better uses of time for a greater number of people.

Amelia’s Status Report for Feb 8th

At the beginning of this week I was focused on finished our proposal presentation slides and practicing for that presentation. In addition to practicing, I spent some time refining/narrowing our use case in order to guide benchmark creation for some of the more subjective elements of our project (like user experience). After finishing the proposal presentation I looked into new models for our text completion assistant. Specifically, we found that someone had quantized DeepSeek, and I wanted to see if it would be possible for us to fit that on our FPGA. I started by downloading the quantized model and getting it set up to run on my computer – to test output quality and ensure the quantized version was still of decent quality. The first roadblock I ran into was that this quantized model requires around 3Gb of memory, and our Ultra96v2 FPGA only has 2Gb of RAM. Unfortunately the group that quantized deepseek did not provide their quantization code, so I reached out to them to see if they would be able to provide it to me. If that happens, I plan to look into quantizing the model further, to see if we could fit in on the RAM in our FPGA

For this coming week, my goals are:

  1. Figure out how to load the model onto the FPGA (using the softcore to scp files)
  2. Get the FPGA to computer UART framework in place
  3. Develop a metric for usability of our UI and conduct some preliminary user testing

 

Team Status Report for Feb 8th

We started this week focused on completing the proposal presentation, which included narrowing down our use case to a focus on users who want to use text completion models but are unable to use commercial products due to privacy concerns with sending sensitive information to the cloud. After the proposal presentation, we received some feedback that caused us to change our approach to benchmarking. Instead of synthesizing CPU/GPU cores onto our FPGA to generate timing and power benchmarks, we are now exploring a way to measure those benchmarks on a Mac, which allows us to start developing and synthesizing our architecture sooner than anticipated. In terms of updating our schedule, we now have more room for slack which will be key as we have to do integration more towards the beginning of our project and will likely run into hurdles getting the host computer and FPGA communicating.

We got our FPGA this week – the ultra96v2, and are now in the process of booting Linux on it (and finding a power supply).  We also got a UI working for all text boxes on a Mac as well as a python script that automates the installation process of all libraries required to use the autocomplete feature. The next steps for the UI include finalizing a model that is small enough to fit in the DDR memory on our FPGA but has decent outputs. One risk we have identified is that we haven’t tested the installation process on any computers other than our own, and we may conduct some user testing to ensure it’s a simple installation process for people with and without technical skills.

Our group goals for next week are:

  1. Finalize a model that is small but has a potentially higher output quality than what we are currently working with
  2. Boot linux onto the FPGA
  3. Figure out how to get timing and power data from MacOS
  4. conduct preliminary user testing (and develop a quantifiable metric to benchmark it’s quality)