Support for closed source tools

[Dan10012]

Hi,

I want to discuss if support for closed source vendor tools like Vivado is welcome or not, as it seems the focus here is on FOSS. In my opinion it basically comes down to practicality vs hermeticity (or maybe philosophy), and wanted the opinion of this repo's maintainers and community on this direction before taking a shot at it.

[QuantamHD]

I'm totally okay with them.

Part of the reason we went with such a scorched earth hermetic strategy was because it is/was a bit difficult to install all the open source tools as individual units.

As long as we keep the end user in mind when it comes to error messages and usability, the proprietary tools are a welcome addition.

I have limited experience using them though, and testing is going to be difficult for me, but not impossible. I'll have to check on our CI options at Google as well.

[Dan10012]

Great, so I'll make myself familiar with current implementation before starting anything.

I'm not quit sure I've understood the meaning of your comment about usability and limited experience though. The best conclusion I had regarding this is to review / survey workflows in a number of open projects which use closed source tool, and maybe colab / reuse existing frameworks to use them.

Regarding testing, let's see how things goes. To be real, it would probably take some time to mature as I haven't done something like this before, and have limited free time to work on this. Nevertheless, your thoughts on this are very much appreciated.

Please let me know if I understand you correctly.

[QuantamHD]

You have it about correct.

I was just implying that I have never used the closed source tools, so it will be difficult to offer you any guidance about specifics, we'd have to work together on that.

In terms of usability I just mean that whatever implementation we come up with should require minimal setup and configuration. "It should be an enjoyable experience for the user"

[rickwebiii]

I have some Bazel rules I made for compiling Clash to VHDL and turning that into a bitstream with Xilinx Vivado. The rules are available here: https://github.com/rickwebiii/bazel_fpga_rules.

Do you have have any interest in having them merged here then I'll obsolete my project?

[mithro]

@rickwebiii - I think we would be very supportive of that!

[QuantamHD]

Agreed! I think that would be very cool.

[rickwebiii]

Cool, I'll hopefully have some time in a few weeks to send out a PR.

[stridge-cruxml]

Any update on this? I also have a bazel rules repo for using Vitis/Vivado and xsim tests that I was intending to port. But if there is an existing solution I will integrate with that.

One complication is how to give access to the license. I chose to include a shell script xilinx_env.sh

vivado_bitstream(
    name = "gen_some_module",
    board_designs = [":some_bd.tcl"],
    constraints = ["//path/to:constraints.xdc"],
    module = ":some_module",
    part_number = "xczu28dr-ffvg1517-2-e",
    xilinx_env = "//path/to:xilinx_env.sh",
)

There are a number of features not implemented in my rules currently too. In particular, parsing the logs/reports for timing failure. Currently it silently passes if timing fails. Is it ok to merge this partial solution?

[rickwebiii]

@stridge-cruxml

I'd merge your solution. Mine was a personal project that I don't know even works with the latest version of Bazel.

[QuantamHD]

@stridge-cruxml We can merge your partial solution.

For the license file we might want to move to a configuration flag with the license file location. Then the user could just add the license flag to their .bazelrc

We could also implement a toolchain config that the user would need to fill out.

[stridge-cruxml]

@stridge-cruxml

I'd merge your solution. Mine was a personal project that I don't know even works with the latest version of Bazel.

Sounds good thanks! I had a look at yours and there is some structure/ideas in yours that I like better than mine. I am currently implementing something between both.

[stridge-cruxml]

@stridge-cruxml We can merge your partial solution.

For the license file we might want to move to a configuration flag with the license file location. Then the user could just add the license flag to their .bazelrc

We could also implement a toolchain config that the user would need to fill out.

Toolchain config sounds like it would be the right thing but I need to look into it. Currently I am sourcing a shell script before I run the command. This is an example of what's in there atm:

export HOME=/tmp
source /opt/xilinx/Vivado/2020.1/settings64.sh
export XILINXD_LICENSE_FILE=2100@localhost

In our usage, we have a single license server (probably common?) but multiple versions of vivado. So perhaps a global default in .bazelrc that can be overridden? I think implementing a minimal example with the shell script then iterating towards that is better though.

[stridge-cruxml]

I have added xsim test support here. I will make a new PR after the other is merged.

[mithro]

FYI There is also the https://github.com/Lightelligence/rules_verilog repository. There is an open issue @ https://github.com/Lightelligence/rules_verilog/issues/19 to suggest they merge their work into this repository too.

[mithro]

FYI - @jmlemay99, @ciglass, @justin371 as people sending pull requests to https://github.com/Lightelligence/rules_verilog repository.

[ciglass]

I'm definitely open to reviewing pull requests to rules_verilog. rules_verilog primarily supports proprietary front-end tools (simulation, lint, CDC) and we're open to supporting more tools (FOSS or proprietary). As @mithro mentioned, I'd like to eventually merge our work into bazel_rules_hdl, but I haven't had the free time yet.

[ted-xie]

Drive-by comment:

I foresee a lot of challenges to integrating closed-source commercial EDA tools in a public-facing ruleset, having done this exact thing for a couple tools before. Besides the obvious challenges of dealing with non-hermeticity (i.e. tools' reliance on hard-coded paths for caches, license-via-network, etc.), there are also huge differences in what tools do what tasks, and therefore what action graphs would look like in Bazel. An obvious example of this is FPGA vs ASIC flows: ASIC tool vendors split different "tasks" like logic synthesis, CTS, placement, routing, STA etc into different products, whereas FPGA vendors bake them all into the same binary activated through various Tcl commands.

[ciglass]

Those are good points. The non-hermeticity of ASIC tools is annoying and we've tried to overcome that with a script to wrap 3rd-party tool invocation called runmod. We haven't tried to encapsulate all external workflow dependencies (like license files) into bazel, but runmod helps encapsulate the vast majority of tool-specific environment dependencies. Some bazel tests in rules_verilog optionally use runmod under the hood (which is what we do internally at Lightelligence) but can be overridden. We have some examples of the override syntax in the .bazelrc. That being said, I'd still understand the hesitation to go this direction until everything about this is properly encapsulated in bazel workspaces.

I'm not sure I follow your concerns about the ASIC vs FPGA flows however. Would there be an issue making individual custom rules for different back-end steps (e.g. synthesis, PnR, STA, parasitic extraction, etc.) then have a single macro to call all steps in the correct sequence?