Fpga ci/cd

Hey folks,
Just joined GitLabs and looking forward to having a play with it!

However, I’m a special case! One of those hardware developers (ASIC/FPGA). Flow is quite similar to SW, but I’ll probably need to do some funky stuff (for example, I doubt any tools I use are supported, so may need a custom docker/image).
Does Anyone have any experience with this?
Where can I get help with this?
Any help with pointing in right direction would help.

FYI: FPGA flow typically:

  • Write code (text based, VHDL/Verilog). This part is ok, I can use all normal tools for pull requests.
  • build the design. Special software needed for this (for example Xilinx/Microsemi/Altera). Normally installed locally on PC (yuk) or preferably on a Linux box. Flow can be automated with shell scripts.
  • simulate the design. As above, need special tools (eg Modelsim simulator) and can be automated with scripts also. The output/results would typically be written to a text file.

Those are the two main task that I need to match up with the existing flow. I’ll post follow on questions when I figure out how to use the tools and get stuck!

In the meantime, thanks in advance for any help,
Cheers,
Mick

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 :slight_smile:

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 :slight_smile:

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