The module was integrated with an already existing RISC‑V CPU project, created as part of other master's theses, by other students.

I devoted a significant part of my work not only to creating the predictor, but also to analyzing and repairing the RISC‑V processor project, because it turned out to be full of errors and inconsistencies with the provided documentation.

In addition to the predictor itself, an extensive test environment was created, allowing for fully automated programs compilation, running simulations, and creating reports. The environment consists of scripts (written in JavaScript) and a Makefile file, allowing for the selection of configuration, with which variant of the predictor the project should be compiled, and which test programs to run.

Additionally, an visualizer of processor internal signals was created, presenting an insight into its operation using an HTML file, divided into cycles and pipeline stages.

A more detailed description of the project structure, and how could you run the project yourself, is over in GitHub's readme.

The Master Mind game consists of guessing a certain sequence of colors (set randomly by the device or by another player). With each guess, the device determines and displays hints as to how many colors are correct and how many of them are in the correct position.

The game was created entirely in the hardware description language SystemVerilog. This approach requires a different way of thinking than in the case of programming in a regular programming language (such as C++). Since the entire logic was designed in hardware, it was not possible to simply define a sequence of instructions to be executed - there is no processor to execute them. Data is processed much more concurrently than if a CPU were used, which required some creativity, especially when implementing the logic calculating the hints.

The designed system displays the game image on a monitor with a VGA and/or HDMI interface. Control is performed via buttons on a separate breadboard connected to the device. The project is also equipped with a speaker that can play simple melodies. The user is able to configure many game parameters, such as the number of available colors, the size of the board and the number of allowed attempts to guess the hidden sequence. It is also possible to set the size of the font displayed on the screen and the color palette used to draw many elements.

The station consists of:

• ASTORINO robot
• ESP8266 (for interfacing between the robot and other components)
• HTTP control interface (on a RaspberryPi)
• Storage structure from aluminum profiles
• Collection of multicolored 3d-printed elements (bases and tops)
• Small rotary table, controlled by a PLC
• Collection of sensors (camera, distance, force and induction)

The station operates as follows: The user creates a request via the HTTP interface, to produce an element with parts of 2 specified colors. Then, the robot grabs the parts from the corresponding rails and inspects them with a distance sensor. The parts are put on the rotary table, and their color is checked by the camera. The robot screws the two parts together, and then outputs the complete element on the output rail (or throws the parts into the trash, if sensor inspection was negative).

Throughout the entire process, the user can preview the state of sensors and internal signals in the HTTP interface.

The robot communicates with ESP via the General Purpose Input and Output ports. Because ESP has too few of those, to fully implement state preview and reliable communication, it was required to use additional port extenders, on a I2C bus. The communication is done via a custom made handshaking protocol. The robot has a precoded set of possible actions, which are send serially from the ESP.

The communication with other components (RaspberryPi and camera) is done via MQTT protocol over WiFi. The RaspberryPi acts as a MQTT Broker. The PLC controlling the rotary table had to be controlled via ModbusTCP.

The ASTORINO robot used in the project was still in the alpha development stage. It made it so that, a lot of things were breaking all the time. For example, the most "fun" thing we encountered, was the robot reading an input pin as the inverse of it's actual state, once every 10000 or so polls, which led to out of nowhere ramming into the table :).

The original application in MS Access was ridden with custom macros, that made it impossible to simply import it to a newer version of Access, and had to be run on a Windows XP virtual machine, and was unwieldy to use altogether.
I decided to build a new app from the ground up. It made it much simpler to add new custom features, than if I were to use another Access-like program. I opted for the SQLite database for the backend.

The app was created with the Tauri framework. Tauri allows to use the operating system's built-in WebViewAPI, which enables my app to use all the features as a Web Browser (most importantly HTML, CSS, and JS for layouts), while not bundling an entire NodeJS runtime, like with Electron.

Tauri's backend is written in Rust. All the interfacing with the SQLite and managing the files is handled by Rust. The user interface is created with the use of the Vue framework. The user can add and edit clients, registered cars, car parts, and orders. They can also filter the views based on many parameters. For each order, an invoice's PDF can be generated and printed automatically.

As a safety net, my app is able to import and export its current state to or from the original MS Access app, using CSV files as intermediate. I also created a couple of scripts in NodeJS, which help to convert the original MS Access db structure into a SQLite one. The app also performs regular configurable backups of the database.