Yosys version not moving forward automatically? Need to make sure we are on HEAD

[mithro]

From #277 (comment)

First of all it looks like you are using an outdated Yosys version (Yosys 0.9+4270 git sha1 539d4ee9) which seems to cause problem in BRAM inference in some cases. I've tried the upstream one that is Yosys 0.15+44 git sha1 3bf107024. With the upstream version there were no issues with inferring BRAM for inst_memory whatsoever.

---

Unfortunately the memory inference does not work with the version currently supposed to be used in symbiflow / f4pga which is Yosys 0.13+3 git sha1 61324cf55 as well. I'll create a PR which bumps its version.

---

Which I replied to with the following #277 (comment);

@mkurc-ant - Why is our version of Yosys so old? Isn't it suppose to be auto-updating?

It is super important that we try to stay as close to Yosys HEAD as possible. We really want everything to be updated within 24 hours if possible.

FYI -- @acomodi / @kgugala

[tcal-x]

We encountered this in #245 as well. The user's bitstream didn't work with the f4pga-examples pinned installation of SymbiFlow, but it DID work with the unpinned (and therefore most recent) SymbiFlow installation from CFU Playground.

I recall the discussion then being that we wanted to stay on a "known good" version of the tools for f4pga-examples. But we didn't address whether to set up a bot to automatically test and bump to the most recent possible "known good".

Edit: more info: The cause of the user's original problem was the old version of Yosys, v0.9. Updating to v0.13 resolved the issue.

[pgielda]

The point of f4pga-examples is that they "compile" (CI is green) and they work on hardware (this has to be tested manually). Does not mean we cannot have a separate bleeding edge version that produces candidates for testing and once its tested it gets updated in the "stable" version. So in fact we would have two sets. Not sure how this plays with conda packages etc but I guess it should be doable. @kgugala what so you think?

[hzeller]

Is there a roundtrip possible in which hardware testing can be automated ? Like a circuit that determines if, say, a LED blinks ?
A CI with no humans in the loop is the best.

[pgielda]

Agreed. But there is lots of demos so probably hard to automate all. We could agree on a set of demos (that e.g. cover some of the Arty demos) that if pass in CI we assume its a good enough indicator... we have some Arty runners internally. But nothing externally exposed to Github Actions currently. But obviously cam be done long term

[mithro]

If our CI on this repository is green I think we should merge the updated Yosys.

If this causes issues for our end users then it will prompt us to improve the CI.