Hi,
interesting stuff, I have been using those during my studies more than 15 years ago. I don’t know exactly if ModelSim and synthesis tools (was it called Leonardo or so?) can be run on Linux but you’re the expert here 
Write code
One thing I’d recommend for Merge Request workflows - at least have some automated code verification in CI config available. Meaning to day, a new commit triggers a ModelSim simulation and waits for the result. Define that as a stage and job to be run.
Build the design
This can be automated too, given that the compiler will generate a binary firmware quite fast.
Simulate the design
Depending on the architecture and critical path, the simulation may take a while. When automating this step, keep in mind that the CI runner job timeout may need an increased value.
Test the design
This is tricky with your FPGA/ASIC, as it depends on the the operations being done. Say, if you just throw some input and measure the output LEDs, you could theoretically monitor that with a sensor. Meaning to say, a custom environment deployment.
CI Pipeline
All of the above can be moved in the CI pipelines and stages like:
stages:
- verify
- build
- simulate
- test
verify_job:
stage: verify
script:
- echo "Compiling the VHDL code!" && ./build/compile_source.sh
Start with the above and make it work. Once you have the first step done, you can go further. I’d also recommend for the build chain:
- Either have the tools for compiling, simulating, etc. in the same repository
- Or create a custom (Docker) image where these tools come pre-installed. Once in a while you rebuild the image and push it to the GitLab container registry.
Benefit with using a custom Docker image - you can test that on your local machine too, before deploying to GitLab itself.
Error handling
For the other jobs, you’ll get the idea of the pipeline. Whenever one stage fails, all following jobs are halted and you’ll see the result.
Failure - what’s that? Your scripts need to decide upon the output of e.g. the simulation, if it is ok, or failed. That may be the critical path seconds, or an analysis of available logic blocks to complete the operation in one cycle, or similar (been years that I looked into that).
exit 0 - ok, exit 1 - error. One tip for custom scripts would also be adding some echo statements, or a log file as an artifact to the jobs. That way you can extract every valuable information from the CI runners.
Future Questions
In terms of getting support/help - possibly here, and likely there are others in the field who are in the embedded world. The more we are openly discussing it, the better
Assuming that hardware is sensible and operations may take a while, you need to keep in mind to have more CI runners available, or increased timeouts. Other than that, I don’t see a reason why this shouldn’t be possible as much as ARM devices or any other hardware architecture.
Cheers,
Michael