![\"\"](\"http:\/\/course.ece.cmu.edu\/~ece500\/projects\/s22-teame1\/wp-content\/uploads\/sites\/203\/2022\/02\/Picture1-300x270.png\")
<\/p>\nThis first week of the project was anaylzing the feasibility of accelerating the fluid simulation workload. My first step was to analyze the fluid simulation algorithm to assess where we could stand to benefit from the increased parallelization.<\/p>\n
<\/p>\n
From an initial viewing, we can obviously observe that the \u201cfor all particles i do\u201d \u00a0loops introduce an obvious avenue of parallelization. For each request of the fluid simulator, we expect to process 512 particles at a time; we could attempt to fully unroll into 512 separate threads, but this could take up a large amount of hardware. Instead, we\u2019d probably want to do a batched pipeline, where we dispatch some N-sized batch of particles into the pipeline at a time. In terms of the exact parameters of the pipeline (parameters such as batch width, pipeline depth), these will be handled on the low-level by the HLS tool itself and on the high-level by the relative importance of different sections of the code. For instance, we might expect that the loop from lines 20-23 will occupy much of the runtime than lines 1-4. As such, Amdahl\u2019s law tells us that we should first focus on deriving speedup for lines 20-23. On the first order, we may say that performance is directly correlated with the amount of hardware resources we assign to a task (as we are just instantiating more threads); so concretely, we may desire a 16-wide pipeline for lines 1-4 and perhaps a 64-wide pipeline for lines 20-23. Of course, we will arrive at some more exact figures once we fully crack open the code and perform some mappings to the hardware resources and determine how much we have to work with.<\/p>\n
In terms of progress, I would say that we are certainly a bit behind, due to the pivot from the UNISURF project to this. However, I will say that a lot of the investigations we performed for UNISURF in regards to the hardware resources of the Ultra96 and the organization of data between the CPU and the FPGA fabric map nicely to this new project.<\/p>\n
In terms of deliverables we would like to have completed by next week, I would personally like to have the entire Vivado\/Vitis project set up. This would mean that we first have to ensure that the base program works nicely on the Ultra96\u2019s ARM core, and then we\u2019d have to designate the different parts of the Vivado project such as the specific compute kernel. Since the Fluid Simulation library is only a portion of the Scotty3D program, I\u2019ll have to investigate to see if there is anything special I\u2019ll need to set up in order to ensure that the different compute tasks are correctly running on the FPGA. In terms of whether Vitis can port in the code, since everything is written locally on the Scotty3D library (no reliance on external libraries), I don\u2019t think that we\u2019ll run into any troubles on that front. Nevertheless, in terms of getting this up an running, I doubt it\u2019ll be as simple as tossing the code into Vitis and hitting build. I will be reviewing 643 documentation to see if I can set up a more streamlined compilation and testing platform.<\/p>\n","protected":false},"excerpt":{"rendered":"
This first week of the project was anaylzing the feasibility of accelerating the fluid simulation workload. My first step was to analyze the fluid simulation algorithm to assess where we could stand to benefit from the increased parallelization. From an initial viewing, we can obviously observe that the \u201cfor all particles i do\u201d \u00a0loops introduce … <\/p>\n