Implement a simulation command in the shell (only for verilog)

[IAmMarcelJung]

This makes it possible to start the simulation with the verilog testbench directly from the shell. It uses all commands from the scripts in Test, but directly in FABulous.py, so no script has to be called. The paths in sequential_16bit_en_tb.v are correctly adjusted when a new project is created. It also adds the possibility to create a .vcd file so the waveforms can be viewed with gtkwave. Additionally a check if the hexfile can be read successfully was implemented. The creation of .fst or .vcd files can be enabled by an optional flag to the command.

The usage of the command is: run_simulation [<fst|vcd>] <bitstream_file> so an example call would be: run_simulation vcd user_design/sequential_16bit_en.bin or run_simulation user_design/sequential_16bit_en.bin if neither an .fst nor a .vcd file should be produced.

Currently this does not support emulation, but since it is just another flag to be set, it might be easy to also add it in the future. The changes in the testbench were only made to the copied file sequential_16bit_en_tb.v so the current simulation and emulation flow stays untouched for now.

As always I'm really open for feedback and other suggestions!

[KelvinChung2000]

Regarding the new function that was created for facilitating testing, we should move them to a new file. Maybe into a directory like fabric_test/testHelper.py.

The number of things need to be checked starts to grow. Are you planning to spend more time on extending FABulous CLI further and adding a lot of new commands? If so, we might want to start considering using argparse for command parsing and handling, i.e. each command has its own little parser. This should make each command code look cleaner.

[IAmMarcelJung]

Regarding the new function that was created for facilitating testing, we should move them to a new file. Maybe into a directory like fabric_test/testHelper.py.

If we move it into a new file we cannot use it the shell or do you mean we should create a new module and import it? Or is the philosophy to keep the simulation really separated from the rest of the flow?

The number of things need to be checked starts to grow. Are you planning to spend more time on extending FABulous CLI further and adding a lot of new commands? If so, we might want to start considering using argparse for command parsing and handling, i.e. each command has its own little parser. This should make each command code look cleaner.

I've currently not planned any further changes other than the currently existing, since I should start focusing more on my student research project. All changes were created from a situation where I stumbled upon something when trying out and using FABulous. I guess the number of changes will decline now since there are no more things I see to be improved for now, except maybe a better tab completion.

If there is however the motivation to change more things in the FABulous CLI, like the use of argparse that you mentioned, I could of course try to help.

[KelvinChung2000]

Yes, I mean making it into a module and doing import. This is just trying to keep the CLI file only having things for the CLI, and the CLI is driving the testing infrastructure.

If that is the case, do not worry about the command parsing. Focus on your student project first. This is just purely for improving the aesthetic of the code. Feel free to ask for help with what you are working on.

[IAmMarcelJung]

Hi @KelvinChung2000 thanks for merging this. I hope it makes simulation easier for everyone! Sorry I did not respond to you last comment. I agree that making a module would also be good. Unfortunately I did not have time to change it to a module and I also did not heavily use FABulous for the last couple of months. Maybe this could be turned into a good first issue since it would be mostly refactoring and there might be many new students working on FABulous in the future and it would then be a good starting point for contribution?