Integrate with python vga-simulator for lab6

[benjamin051000]

Use something like https://gist.github.com/pvieito/8cdb54a9a03fd36e51c8df6e331a3006 to automatically generate the VGAs! That would be a pretty sick addition to the lab6 testing.

[benjamin051000]

One issue is figuring out exactly how we can tell whether or not the generated images are correct. Perhaps the best way would be to simply open them in a window and the TA can choose whether or not they look good.

[benjamin051000]

I think at least including the Gist script in this repo (modified for our purposes) would be pretty helpful.

[benjamin051000]

I don't know if my gist is up-to-date, but one cool thing we could do is just include the gist as a submodule (I think this is possible)

[benjamin051000]

It's now a repo at https://github.com/ARC-Lab-UF/vga-simulator.

[benjamin051000]

This doesn't need to happen yet, but I'm wondering if an easy "modular approach" would be to have like an extras/ directory, where you can drop a folder that contains a program to run any supplemental programs. For example:

extras/lab5/ would be the root of a "subproject" that can run additional stuff during simulation (either before, after, maybe even during...). Maybe an entrypoint could either be main.py or __init__.py or the actual name of what it does, whatever makes the most sense.

The process would be something like this

• Parse the lab from CLI
• Check extras/ for any lab-specific programs
• If nothing, skip and run like normal.
• If a dir is there for this lab, parse it's manifest/configuration to see what it wants us to do (e.g., run before modelsim TB, after? During in parallel? etc., other config options)
• Do it

A few benefits to this design:

• Subprograms can be anything: any language, any tool. So long as they conform to the testbench-runner extras interface (TBD)
• decoupled from normal testbench runner

Some examples of things we can use this for:

• VGA simulator (a python project)
• MOSS upload (perl script)
• Formal verification
• Quartus script to synthesize the project, check for warnings/errors or something
• Quartus synthesize, program board, to automatically test on the board :o
• Canvas API hook perhaps? Although this would more likely be built-in to the normal program. Doesn't feel like an "extras" thing to me.

[benjamin051000]

An alternative design idea is to have extras/subproject where the subproject's manifest/config file tells us which labs it applies to.

+ Less duplication when multiple labs require the same subproject (e.g., MOSS)
- cons? Unsure

[benjamin051000]

Okay, we are definitely doing this. I honestly like the idea of the extras/ dir, making a separate issue for that.