Last week my goal was to work on some optimizations for the build. However, I had to shift my attention to what Jeremy was working on with the nearest neighbors. Since hardware needs to have known memory sizes for everything, it makes it challenging to discretize the 3D world space and partition the fluid particles accordingly, so we are currently trying to bound the possible fluid simulation positions. However, right now we still have a bit of work to do with re-working how we read particles in (in case they get dropped) and making sure the output is reasonable. My goal for next week is to finish up getting the algorithm to work correctly in hardware and then work on optimizations.

I definitely feel slightly behind since our team was not able to meet in person at all this week and communication has been slow. However, it seems like Jeremy will be able to meet in person again soon and we’ll be able to get back on track.

So this week unfortunately I have been sick with COVID, and wasn’t able to make as much progress as I wanted to originally. For the majority of the week I have been trying to get rest and recover quickly, so I’ll be productive next week. Later in the week I was able to put in some work where I worked on the correctness of our algorithm, as we were facing some issues where particles did not behave as we expected them to. The issues turned out to be with how we calculate the bounds of the scene and the voxels that particles are in, but they are mostly solved now.

I feel slightly behind since I did not expect to get sick this week, but I think that we are still in a good spot, and will be able to produce good results from our project. Next week I am ti help with collecting data and continuing to optimize our implementation.

Last week we were rushing to finish the build for the interim demo, and I was unable to complete the evaluation script. This week I was able to do so. I also read up a lot on unrolling, pipelining, and other optimizations outlined here: https://docs.xilinx.com/r/en-US/ug1399-vitis-hls/HLS-Pragmas

This upcoming week I’ll be working on adding said pragmas for optimizations. I’ll also be helping to verify that the Vitis HLS project provides reasonable fluid simulation output once Ziyi finishes the interface work to get an output text file from the FPGA.

We had a really great push at the beginning of this week. I’m optimistic that we can achieve our goals.

This week we got a ton done on the hardware side of things. First of all, after finally squeezing out the final few compilation errors, we managed to get a trimmed down version of the kernel (everything sans nearest neighbor loops) built using Vitis HLS synthesis. After looking at the synthesis analysis, we were able to see that the correct loops were also getting synthesized, which meant that our code was being inferred correctly.

After passing synthesis, we were able to export the rtl implementation (the .xo file) and import it into regular Vitis itself without any additional troubles. Then, after implementing some basic interfacing code between the host program and the kernel, were were able to build a binary to run on the FPGA. In order to get this binary onto the board, we simply scp’d the files onto the board.

Running the program resulted in a segmentation fault, so we still have a bit to go. My goal for next week is to debug the interface and work on some optimizations with Alice and Jeremy.

This week we got a lot of work done in terms of synthesizing the kernel. At the start of the week, we managed to get a synth running using floats as the main datatype. The problem with this one is that since floats were so computationally intensive, it was pretty much impossible to get the critical path to converge to the target critical path, and so we couldn’t meet timing. Nevertheless, this was a significant step in the right direction.

So my next task was to begin the migration from floats into our custom fixed point datatype. Basically any calculation we would perform on the particle positions or speeds, we would replace with a fixed point datatype. For now, we decided to use a fixed point representation where we have 6 bits representing the integral part of the number and 6 bits representing the fractional part of the number.

Unfortunately, this would prove to be quite an involved task, as we would also need to make significant changes to all of the math libraries in order to change them to use the new datatype. So, a majority of this week was spent incrementally compiling and changing the math libraries to use the arbitrary precision datatype instead of the floats. This was complicated by the fact that there were still some weird C++ issues that led to some weird aliasing of the datatype to the int datatype. Another specific issue we had to investigate was how we would take care of some specific math functions (such as square root); thankfully, this issue was easily addressed using the equivalents in the HLS math library. Other than that, we seem to have mostly figured out those issues, and now we have a compile running!

Our next step is to finalize the changes to get a complete synth of the kernel and then upload the project to normal Vitis so we can generate a binary file and upload it onto the board in time for the in-class demo. All in all, I am much more optimistic as to the effectiveness of our project after this week.

This week we did a lot of work on both some optimizations and synthesizability of our project. There were still many C++ errors from the interactions with the Vitis libraries and the modern C++ codebase that we are using. After initial synthesis attempts, it turned out the amount of floats, there was no way we could meet any sort of reasonable clock period for synthesis, so we began converting the code to use fixed point numbers as outlined in our design. But, the libraries provided by Vitis did not interact well with the already written math libraries, and I spent a while trying to get these libraries to cooperate with each other.

I think that we are on time, and are making steady progress towards the goals we set out to accomplish. We need to ensure that we work consistently in the upcoming weeks, but we have been working well recently. Next week I hope to work more on optimizations with unrolling and pipelining.

This week, we made progress on two fronts. On the hardware front, Jeremy and Ziyi worked on getting the Vitis HLS build to work on the stripped down version of Scotty3D; on the software front, Alice worked on having Scotty3D read particle postions from a preloaded file for stepping through a simulation.

In terms of hardware, we managed to get the C simulation build option to work and run a small testbench. While this was a good start for getting the binary built, we realized that we still had a long way to go before we could get C synthesis to work. The biggest hurdle is that the C synthesis seems to run on an older version of C++, with a bunch more restrictions and caveats on what can actually get compiled into hardware. Many features that the C simulator readily worked with, the C synthesis just outright refused to cooperate with. Still, despite these setbacks, we believe that we are quite close to a breakthrough for the C synthesis. Once we finally get a working build, we will get the area estimates and also get some timing reports from putting the binary on the Ultra96 development board and running it. It is also worth noting that in our endeavors to get a working build, we  alsorefactored the par_for, seq_for, and for_n (for neighbors) lambda functions into separate, discrete for loops. Though this reduces code reuse, it is important in that it allows us to specifically reconfigure the different instances of these loops so that we can more deliberately assign hardware resources as opposed to accelerating all of the different loops with the same parameters (which would otherwise be hard coded in the lambda functions themselves).

In terms of the Scotty3D interface, we were successful in getting Scotty3D to run a precomputed set of points. Of course, this resulted in a lightning fast visual simulation within the Scotty3D engine, which provides a compelling example of the benefit of hardware accelerated precomputation. Nevertheless, though this is not as interesting as a real-time demo, it is a significant step in the right direction. The next major goal on the interface side is to enable UART communications between the FPGA and a host computer to transfer live simulation data. This will be an essential step to having  the real-time simulation. Of course, we will also have to investigate the UART bandwidth to see if we can keep up with frames per second latency demands of the simulator.

This week I was primarily working with Ziyi on getting the code in the C++ build environment to work well with the Vitis HLS build. We spent a while improving the portability of the code as Vitis has a set of specific requirements, and does not work well with very modern C++ code that is generic for many purposes. Vitis HLS has very cryptic error messages, so progress is steady but slow on getting this to work. There is a lot of trial and error involved in figuring out what is causing errors, and it is tricky to figure out how to redesign the code to fix it. We also began to work on optimizations for the fluid simulation, initially by starting to unroll loops, which creates larger parallelism and hardware utilization.

I think that we are on track to complete our project on time, but slightly behind where I would like to be at this point. It is good that we left ample slack in our schedule. Next week I want to continue to work on optimizing the implementation, and also work with Alice on communication between the FPGA and CPU to display the output of our renders.