Author Name: Todd Strader (@toddstrader)
Original Redmine Issue: 1547 from https://www.veripool.org

Original Assignee: Todd Strader (@toddstrader)

Currently, for verilator CI we are caching object files when building Verilator but for verilator_ext_tests we are doing that and caching the binaries themselves. We're also doing this in a separate build stage. This allows us to skip the entire build if we've already built the Git revision that we're on. It also allows all subsequent Travis stages to share the Verilator build.

I've now brought all of that into the verilator CI environment:
https://github.com/toddstrader/verilator-dev/tree/travis-stages

Two things which could be landed as separate commits (or not, just let me know):
t_a4_examples was using the root Makefile which will cause Verilator to re-build if we're pulling from cache and the intermediate objects don't exist. I've changed it so that this won't happen which is how the rest of the regression suite behaves.

driver.pl was modified to report what tests are running if it doesn't report anything or five minutes. This is how I discovered what was going on with t_a4_examples. I could push some of this to Parallel::Forker, but then we'd need to bump the version of that module, etc., etc. But if that's desirable I can go that route instead.

All of this allows for more streamlined builds (especially when there is contention on Travis). But even more so it allows users of Verilator (e.g. verilator_ext_tests, SweRV, cocotb) to be able to use ci/build_verilator.sh for themselves thus simplifying users' CI setups. I've done this in verilator_ext_tests here:
https://github.com/toddstrader/verilator_ext_tests/tree/vlt-build

The verilator_ext_tests branch has a commit that I will not push to trunk but was necessary to test this against Travis while in this intermediate state.