The following project was part of a university assignment, taken a step further and improving some crucial aspects of our project, mostly regarding visualization and preprocessing.
The team consisted of 2 members :
The assignment could be broken down into 3 parts:
- Preprocessing
- Hardware Simulation
- Visualization
Functionality of each one is explained in below.
The whole procedure could be explained in short from the shape below. Basically the circular shapes describe the Hardware FSM ( implemented in SystemVerilog) and the rectangular shapes are the Python Notebooks Used for Data Preprocessing & Analysis from left to right, respectively.
Specifically, the first Python Notebook in Part A will create 2 memory files mem.sv & weights.sv , which will be in a ready-to-use memory format for our hardware implementation. After the hardware is simulation is complete, we export our grid values in relation to the simulation time, and use it as our input, for our Data Analysis notebook, which will convert the values to a sequence of frames and finally export it in a .gif format, basically visualizing our evacuation algorithm.
Input : map.png
Output : weights.sv & mem.sv
In this part we will convert a png top view of our map, in 2 SystemVerilog memory files.
Map Format :
- Red Color : Person
- Green Color : Exit
- Blue Color : Wall
- Black Color : Free Space
The files we create based on the above picture, specified by the above mentioned rules, are:
- mem.sv : responsible for providing a represantation of the map in a 3 FF / 3bit state for each pixel, based on their absolute RGB values. So for example, for a red block we will have (R,G,B) = (255,0,0) and convert it into a 3'b1000 for a pixel in a hardware memory format.
- weights.sv : the file will hold the value of the Manhattan Distance of the closest exit to each pixel, unless the pixel is that of a wall object, in which case it will replace it with an absurdly large value.
It is worth noting that the files output are scalable and does not depend on the size of our grid dimensions, as well as the sum of our project was made to be as parameterized as possible for more flexibilty.
As described above, having our files ready we proceed to simulate in hardware the algorithm as shown in the FSM. In short, for a grid with dimensions x,y:
- load the FFs values from memory, of our grid and weights files in x*y clock cycles
- scan each pixel's value. If it is a person we look at each of its neighbors and move it combinationally if possible, according to the FSM, based on the John von Neumann CA
- repeat until completion or manual stop
In Modelsim we ould see the grid's FFs changing states and people getting closer to exits, as well as people stepping on an exit and thus being removed from our grid.
Problems:
- people congestion : solved by setting neighboring blocks with people to absurdly large value - not taken in consideration
- wall in front of exits : not solved yet, needs an alternative route for a person, not only based on the heuristic of our Manhattan Distance weights
After we have completed our simulation we export our field variable representing our grid in relation to time of our simulation. The file format has a line for each timestamp, which holds all values of our FFs for each pixel, so it will hold x*y 3bit values for each time step, or each frame, when constructed in a reverse way from Part A.
TIPS:
- There is an option to save the frames in a specific frames folder for larger maps, or hold in memory for the execution of the program.
- There is an option to upscale images to 512*512 pixels for the gif creation for better visualization
After executing that for 4 different scenarios we got the following results (see media folder for more details):