Speed
The speed of the execution was a big topic during our design of how to implement the calculations so that it could be stored in BRAM without timing delays as fast as possible. After doing some timing test on software versus hardware implementations of the automation calculations, it was very evident that the hardware implementation would be much faster and have less timing delays. This was because of two major points.
- Software implementation required more time to be allowed between writing ad reading
- Hardware implementation could be done where cells were computed using logic in a 2D array setting allowing for a small level of concurrency.
Because of this, we only used a hardware implementation in our final design. This also allowed for on board switches to be used for how we could input different rules of automation. The speed for how quickly the automation would appear on the screen was blazing fast because of this as well. A single button push would almost immediately show both the full and rotated versions of the display seemingly instantaneously. While the audio part did not work as expected, testing with predetermined data for audio input also was very fast.
Accuracy
All of the cellular automata and their respective rotations are exactly as expected except for a few scenarios where the starting state for the automata (the top row) changes unexpectedly. In every case where this happens, the top row becomes all white instead of the normal top row that we hard-coded into the design.
Usability
With the hardware implementation, it became very easy for users to discover different automata themselves. The switches are easily seen as binary values representing the 256 possible rules for automation and the buttons, although they are not expressly labeled, work quickly enough that users can switch between views easily. There is no flicker or delay at all either.