Hi, I wanted to continue with the discussion here about using Gradle for Verilog/SystemVerilog. Has anyone done this successfully? What has been the experience?
I think this experiment can be considered as difficult and long, but not impossible. It requires a deep knowledge of the compilers involved, and a lot of patience to not cut corners. I am using the new software model, which is hard to learn because it is very new. I use Ivy dependencies because Ivy can fetch non-jar dependencies much more easily than Maven. At this time I cannot share any code because it is proprietary.
Thanks for the response! Where did you find the most difficulties? One of your requirements was to fetch multiple versions of the same source, I don’t think I’ll have to do that. Hopefully this simplifies things. I will also check out the new software model, I’m not familiar with that yet.
Also, I think that HW development tends to sync the whole source database via your SCM (SVN, ClearCase, Perforce, etc.) and then just compile from there, rather than fetching dependencies as part of the build process. In fact if I suggested that, people would think I’m crazy. Were you able to reconcile these two flows? Do you sync all the source and then just pull it in via Gradle, or is your build process fetching dependencies? I’m just learning about these tools, but it seems like you can set Ivy up to just point to a “local” repository of source code. And then as long as each module has an Ivy XML file checked in with it, Gradle will be able to find it.
Finally, re. the code, it’s a shame that in general us HW development guys don’t collaborate more on tooling and flows. There are literally 0 online examples of how to use these tools with HDLs. I will try to get permission from my employer to share some basic build scripts with the community, if anything good comes out of my experiments. Would be great to build in Verilog/SystemVerilog/VHDL support via plugin.
Most difficulties are in using the new software model. I am trying to bridge external dependencies (the gradle dependency declaration code block) into the new model (e.g. get UVM and others into the compiler arguments directly from their gradle dependency declaration - just like Java has its classpath automatically computed). I am also trying to express inter-dependencies between project libraries (I still have not tried gradle sub-projects). I am trying to use the dollar-dot syntax. All of it is difficult and takes lots of time to experiment. I am looking forward to reading the completed version of Idiomatic Gradle volume 2 by @Schalk_Cronje , I hope it will answer many questions I have.
1 Like
I’m also interested in what @evancox10 mentioned, regarding synchronizing the SCM database. The issue is that HDL gets used in multiple flows, so it would be necessary to set up a build for each. For simulation I could probably set something up, but colleagues responsible for the other flows will still want their setups to work as before, by selecting the proper file versions and running some scripts manually.
We use ClearCase. Instead of checking out repositories (like in Git/SVN) I was thinking of using a dependency management tool to generate a config spec. Afterwards, the decision of automating the build using a build tool or running some handcrafted scripts can be taken on a case by case basis. Both of these tools could be Gradle.
I was wondering what the state of your experiments is.