Particle Projectile Simulator
The purpose of this project is to implement a system of particle projectiles simulated using the FPGA on the DE1-SoC. The solution iterates particles using kinematic equations in hardware and displays the resulting projectiles onto a 640x480 VGA display.
The projectiles modeled by the FPGA are based on the kinematic equations below: $$ y=y_0+v_{0_y}t+\frac{1}{2}a_yt^2\\ x=x_0+v_{0_x}t+\frac{1}{2}a_xt^2\\ $$
$$ v_y=v_{0_y}+a_yt\\ v_x=v_{0_x}+a_xt\\ $$These continuous equations map the $(x,y)$ trajectory of a particle with input $t$. However, they can be broken down even further into a series of linear equations:
$$ a_y=g-Dv_{y_n}\\ a_x=-Dv_{x_n}\\ $$$$ v_{y_{n+1}}=v_{y_{n}}+a_y{\Delta}t \\ v_{x_{n+1}}=v_{x_{n}}+a_x{\Delta}t \\ $$$$ y_{n+1}=y_n+v_{y_n}{\Delta}t \\ x_{n+1}=x_n+v_{x_n}{\Delta}t \\ $$These linear equations allow for the incorporation of additional forces, such as drag $D$. By linearizing the equations and normalizing our discrete time step, $\Delta t = 1$ frame, all of the time based multiplications get removed. With only two multiplications to calculate the component accelerations, the particle iterator can be solved combinatorially by the FPGA. This opens up the doors to solving multiple particles in parallel. Positions $x$ & $y$ are measured in pixels. Velocities $v_x$ & $v_y$ are measured in pixels/frame.
While the FPGA can certainly compute many droplets in parallel, it will need to store the previous and current states of all particles being calculated. To solve this, the DE1-SoC's M10K blocks are utilized. This allows the FPGA to solve the trajectory for the next frame and store it in memory to use later.
To display to the VGA, the FPGA writes to the buffered VGA-SDRAM Bus, similar to the example code titled: "VGA display using a bus_master as a GPU for the HPS. Display from SDRAM" found on the course website: DE1-SoC: Avalon bus master to HPS. While easier to implement, this method of writing to the VGA bottlenecks writes to 1 pixel per cycle, so multiple solvers would need an arbiter to write to VGA.
The particle solver was built by first implementing a module utilizing the above combinational blocks. These blocks formed the combinational "droplet" iterator module used to calculate particles' trajectories to write-back to memory and display through VGA before the next frame.
The State Machine describes the sequential logic used to drive the particle solver. The solver interacts with both M10K memory modules and SDRAM VGA Bus, so multiple cycles are necessary to iterate a single particle between loading the particle from memory, erasing the particle's previous position from the VGA, and re-writing it. It takes two Cycles to read from M10k and a cycle to write to both M10K & VGA, so it takes around four cycles to complete a single iteration for a single particle. A particle is done iterating when it falls out of bounds. The packet is done iterating when all particles fall out of bounds. Even though iterating through the list of memory particles in series, the FPGA is still able to iterate the trajectory of more than 256 particles in less than a 60th of a second. Each instantiated solver is responsible for a packet of 256 particles in series, but can be combined to take advantage of the parallel abilities of the FPGA. Unfortunately, the serial constraint appears when utilizing the VGA SDRAM Bus, where parallel solvers would have to queue to write to the VGA. For this reason, I only pushed one solver through the flow.
The current build of the projectile solver launches a packet of projectiles from the bottom left corner of the VGA screen $(0, 0)$ at $v_{x_{n}} = 4.6$ pixels/frame and $v_{y_{n}} = 8.9$ pixels/frame. Gravity is about $-0.2$ pixels/frame$^2$. The Packet contains 256 particles, so a preset vertical and horizontal spread, resulting in the initial diagonal trace, were applied to help differentiate the particles. Colors were also applied by incrementing an 8-bit color register whenever a particle is drawn to the VGA.
The DE1-SoC Switches and Keys(Buttons) were given functions for more sandbox-like features. These switches were toggled to produce the video demo above:
| Switch | Function | Active High |
|---|---|---|
| 0 | Pause/Manual Clocking Mode | Yes |
| 1 | Invert Gravity | Yes |
| 2 | Drag Enabled (0.13) | Yes |
| 3 | Y_Spread Enabled | No |
| 4 | X Spread Enabled | No |
| 5 | Y Rand_Enable /Path Tracing | Yes |
| 6 | X Rand_Enable /Path Tracing | Yes |
| 7 | Sim Speed | Yes |
| 8 | Sim Speed | Yes |
| 9 | Sim Speed | Yes |
| Key(Button) | Function | Active High |
|---|---|---|
| 0 | No Function | N/A |
| 1 | Reset/Packet Launch | Yes |
| 2 | Manual Clock Toggle | Yes |
| 3 | No Function | N/A |
The Rand_Enables are not currently functioning as intended, as they are supposed to set the initial velocities of the particles to have a more random spread, which they do, but the magnitude of the random numbers is too small compared to the initial velocities, along with the pixels not erasing properly afterwards. It does work as an accidental feature, as that results in a traced projectile path of the particles.
One of my favorite settings is to manipulate gravity and drag in the middle of a flight. The drag constant is very high, so the particles will slow down very rapidly in both x & y directions. Flipping the gravity in this mode seems kind of like a mini game where you keep the particles within the screen bounds to prevent the packet from despawning.
Sometimes there are problems with erasing the leftover particles and they seem to "splatter" onto the edges of the screen. Unfortunately, the reset doesn't clear it, so the program needs to be reflashed in order to clear the screen.
The functional switch interface is somewhat intuitive to use, but the user would need to be informed of the various settings available with switches 0 through 9.
The original goal of this project was to implement a firefighting game using projectile water droplets, but it evolved into a particle sandbox. My original expectation was to utilize the HPS to produce a more gamified experience, but my focus shifted more to the particle generation via FPGA to produce a project more computationally intensive. Throughout the semester, I've always had trouble waiting out the Quartus processing times of 8 minutes per build. For future developments, especially when I rebuild to change input parameters, I can set input parameters based on the hardware switches found on the DE1-SoC or by passing them through the HPS. The HPS has a lot of useful features that I could have taken advantage of, such as screen wiping, mouse/keyboard inputs, and even shared VGA writes, all at the cost of speed. If I want to simulate more particles in the future, using the HPS to debug would save me a significant amount of time. All in all, I didn't reach my original goal of creating a fully fledged fire fighting game, but I created a fun particle projectile system. Throughout the semester, my verilog and understanding of hardware have improved drastically, so I'm very grateful to the course for the experience.
To Professor Adams and Professor Land for insight on this project and guidance through various roadblocks.