suggested methods to stay aligned to releases

[jeffnye-gh]

We depend on a number of upstream components in our flow that are interrelated and rely on compatible versions, branches or sha's. We use stf_tools, stf_lib, map/sparta, mavis, helios, dromajo, olympia, etc. I expect the rate of change to increase, at least in the short term.

Should map/sparta be a sub-project of olympia w/ a specific sha? Similarly should stf_lib be a sub-project of dromajo? Olympia already does this for mavis and stf_lib.

Or are we outliers using this many dependent projects ?

I could use some recommendations on how to manage the various versions which may/may not be compatible.

[klingaard]

There's a similar discussion in #44.

Yeah, keeping these libraries in sync, etc is a problem and, no, you're not an outlier. Some ideas and some statements...

• I think you and I chatted about making Condor's Dromajo fork either an external project or a submodule of Olympa -- can't remember which. Either way, if Dromajo were a subproject or submodule it could rely on Olympia to set the version of stf_lib used. This could be part of Olympia's regression -- making sure it can create a trace that Olympia (of the same SHA) can consume. Dromajo does have some kind of co-sim mode that can run simple/small ELF binaries w/o the need for a rootfs
• Sparta is a different beast. At previous companies, we added a hook in the CMakeLists.txt file of our simulator that checked the version of Sparta installed. We did not install Sparta in conda, however, but a separate directory named after the revision. This kept our sanity. 😄
  • We could make it a subrepo or external project of Olympia, but I was hoping to avoid that just for keeping build/disk space utilization at a minimum

[jeffnye-gh]

I did not notice the previous discussion, re: #44.

but I was hoping to avoid that just for keeping build/disk space utilization at a minimum

I'm fine with that. I will give thought to your solution for Sparta, I/we have some work to do on our process, separate sparta dir would knock off a few rough edges.

You/I decided on dromajo as an external project. If it helps we can change it. This was to get away from the patch file.

Yes dromajo will run baremetal so a regression is possible. We do this with some micro-benchmarks I grabbed from some repo, I believe it was riscv-tests. https://github.com/riscv-software-src/riscv-tests/tree/master/benchmarks

Thanks for the recommendations, that helps.