Month: March 2022

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.

At the start of this week, Jeremy and I managed to get the C simulation build to pass in Vitis HLS. While we were quite happy at this initial success, we quickly realized that we still needed a lot more work to get the C synthesis working. One thing that majorly complicated this task was that the C synthesis build script would fail pre-synthesis without actually printing any errors. However, after poking around on the Vitis forums and ticking some specific compilation boxes, we could finally read some of the error logs. As it turns out, most of our problems were just version and build conflicts with different C++ features. For instance, while we were able to get away with the auto function type for our lambda functions in simulation, the synthesis compiler got a bit angry at us. Right now, we are still trying to resolve these issues and hopefully synthesize some version of the kernel soon.

In the process of fixing these compilation errors, we also got started on our optimization work. One major task that we did this week was that we got rid of all instances of par_for, seq_for, and for_n, which – respectively – iterated a function over the particles parallelly, iterated over the particles sequentially, and iterated over the neighbors of each particle. This is a major step, as it allows us to manually control the unroll parameters of the kernel on a per-loop basis, rather than applying a single pragma en masse.

Other than slowly grinding through the myriad waves of compilation errors, there is nothing too much to schedule and to report. Still, once we get a working build of the binary, we’ll throw it onto the FPGA and get some timing values reported. We’ll also need to get a survey of the resource utilization of the base implementation. We envision that this will be done by next week.

Most of my effort this week was spent on getting a lightened version of the fluid simulation kernel to build on Vitis HLS. This comes as a transition in our priorities to better make an MVP target for our project. Specifically, we were interested in implementing a “headless” version of the simulation kernel, where the only thing that we would specifically need to run is the step2 function in the fluid simulation kernel. We decided that all of the rest of the rendering tasks are not as pressing and should thus be handled at a later point.

Much of the work of this week was setting up the Vitis HLS project on the ECE number machines. We were running into some significant build issues running on Alice’s computer, and the documentation online was frustratingly sparse. As such, in order to make some breakthroughs in our project, we decided to transition to the existing, working, setup that 643 uses. Setting up the project took a bit of work, but we were eventually able to resolve a lot of the bulid issues and get the C simulation task to build. A large part of this task was refactoring parts of the code to remove C++17 artefacts and using different versions of the different libraries that the Scotty3D library depends on.

Right now, we are still trying to figure out how to get the C synthesis to fully build. It is a bit difficult at the moment, as the synthesis log is not actually highlighting the error. However, I think it might have something to do with the tool inferring multiple TOP functions.

Obviously, the goal for next week is to get a working version of C synthesis running.