hdl: remove yosys-report.txt

[proppy]

• set default shell to bash
• add pipefail option

Fixes #412

[umarcor]

What about using set -o pipefail so we can preserve having the report written to a file?

[proppy]

@umarcor are we cool with tying the build process to bash?

[mithro]

@umarcor are we cool with tying the build process to bash?

I think I am.

[umarcor]

Honestly, I'd be good with tying it to Python only and leaving bash and Makefiles behind. It's 2021 already! So, I think requiring bash is ok, until we can actually provide a py solution.

[proppy]

I'd be good with tying it to Python only

are you thinking of something like https://nox.thea.codes/en/stable/ to automate testing in various python environment, or just orchestrating the build in python?

[umarcor]

are you thinking of something like https://nox.thea.codes/en/stable/ to automate testing in various python environment, or just orchestrating the build in python?

Actually, my statement has several layers of complexity. I mean a modular project composed of various Python abstraction layers (classes) stacked on top of each other, which would allow existing HDL/EDA management tools to stop reinventing the wheel.

0. Packaging and distribution of tools.
1. Abstraction of a CLI program (independent of EDA tools, can also be Git).
2. EDA tools and interaction with these incl. output filtering.
3. Middle layer to translate projects into execution steps.
4. Projects.
5. Workflows.
6. INI/YAML files.

See the thread in gitter.im/hdl/community?at=60f6b7d0c9f8852a97fa240b and umarcor.github.io/osvb/apis/tool.

The Makefiles in the hdl subdir of this workshop, as well as the ones in stnolting/neorv32: setups/osflow are the non-Python common ground I'm using as a reference. Whatever Python solution we build needs to support all the toolchain installation and execution patterms used in the CI of this workshop (linux static-toolchain, windows static-toolchain, macos static-toolchain, container all-in-one linux/windows/macos, container fine-grained linux/windows/macos, windows MSYS2) and others (conda, oss-cad-suite, brew, etc.).

The final solution is likely to have parts of pyIPCMI, Litex, PyFPGA, edalize, etc. Meanwhile, my naive approach is to replace Makefiles and bash with pydoit. That allows just a syntax change, with very low cognitive load for any reader used to makefiles. See, for instance, stnolting/neorv32#110.

I find nox very interesting, but similarly to tox the scope is not exactly the same. I/we are not explicitly insterested in creating multiple venvs with specific packages in them. We are focused in a single Python environment (which might be the system, a container, one specific venv or some venv created by Conda) and multiple EDA tools not written in Python. Nevertheless, I will note down the reference to nox, because it might be useful in some of the abstraction layers. Some of the tools that use nox, such as Hydra or Google's projects, do have some overlap with our scope.

[mithro]

One thing to think about is that we want to be as familiar as possible to existing software developers. While we do want a "unified solution" there are plenty of stubborn developers which will always want to start with "simple makefiles".

[mithro]

See also f4pga/f4pga-arch-defs#2225 and https://github.com/PyFPGA/symbiflow_cli

[umarcor]

One thing to think about is that we want to be as familiar as possible to existing software developers. While we do want a "unified solution" there are plenty of stubborn developers which will always want to start with "simple makefiles".

Agree. People need to be convinved about the need for a "fully-featured Python ecosystem" before using it. Those working on a limited number of boards, with an specific set of languages, or an specific sub-ecosystem will not need such solution. There will always be a place for makefiles. However, at some point of complexity, they are more painful than useful.

See also f4pga/f4pga-arch-defs#2225 and https://github.com/PyFPGA/symbiflow_cli

I need to do a writeup of the discussion in hdl/community and a meeting I had with Patrick and Kaleb. Then I will reply there.

[umarcor]

@proppy, do you mind using pipefail and adding Fixes #412 to your first message above?

All other CI failures should be fixed now (both doc and macos).

[proppy]

@proppy, do you mind using pipefail and adding Fixes #412 to your first message above?

PTAL

[umarcor]

Thanks!