search

olofk / edalize

An abstraction library for interfacing EDA tools
BSD 2-Clause "Simplified" License
603 stars 183 forks source link

Interfacing edalize and bazel #140

Open mithro opened 4 years ago

mithro commented 4 years ago

bazel is Google's build system. Currently it primarily targets things like C++ and Java server building, but it would be nice if it had strong support for interfacing to HDL toolchains.

I'm unsure what the best way for edalize to be interfaced to bazel, should; 1) edalize generate bazel build files (in a similar manner to generating Makefiles)? 2) bazel build files (which can support Python) call into edalize? 3) edalize be used inside bazel in some way?

Ideally bazel would not have to duplicate all the code in edalize for doing things like parsing and understanding the output of various EDA tools.

mithro commented 4 years ago

FYI - @hzeller

imphil commented 4 years ago

@mithro what would be the goal of such an integration? Specify all source files in bazel description files, and use edalize to

mithro commented 4 years ago

@mithro what would be the goal of such an integration? Specify all source files in bazel description files, and use edalize to

  • call the EDA tools?
  • create a "run configuration"/bazel snippet describing how to run the tool?
  • something else?

This is what I opened this issue to try and figure out! Should bazel be using edalize to call the EDA tools? Should edalize be generating configuration for bazel? Or is there something else better here?

fangism commented 4 years ago

FYI - @snsokolov

olofk commented 4 years ago

Hi @mithro . Thanks for raising the topic. I had similar discussions with the Meson devs last year. I know about Bazel, but have never used it so I can't really comment on the technical side. But I have been having some general high-level ideas about this on my mind for a long time. As the way things are now I believe the best way to start with is for Bazel to treat Edalize as a monolithic build step where you input and EDAM file togeteher with verilog, vhdl, constraints and all the other stuff that the EDA tools need and as a result you get a simulation model, FPGA image, netlist, or whatever you have set up your Edalize flow to produce.

Parallel to this I'm planning to exchange the current makefiles with ninja to improve the connection between the internal stages of edalize

In the longer run I'm considering ways to make Edalize even more modular and treat it as a series of more fine-grained processing steps. The current backends would then become pre-defined flows that just pull in the processing steps needed. But it would also allow to more easily create custom flows. And once we have come to that stage, it might make sense for Bazel-based builds to define these flows in the Bazel way instead, so that Bazel has full visibility of the artifacts produced between stages.

Not sure if any of this makes sense outside my head, so please let us keep talking until everyone is on the same page :)

solsjo commented 1 year ago

@mithro I haven't looked into Bazel hdl. Has there already been some work started on this?

Otherwise,

I guess that if we start simple, we could just wrap edalize as a binary rule. Allow all flags to just be fall through; and provide all .v / .vhd / other + py to be listed as dependencies?

I guess the path to the underlying tools might be provided as env vars if possible.

This rough wrapping might not give all benefits of Bazel but at least a first step?

solsjo commented 1 year ago

Haha, I missed all but the first comment.

But as you guys concluded, a first step would be to treat it as a single build action.

Has anyone started with that? I can give it shot otherwise.

solsjo commented 1 year ago

@mithro @olofk

I made an example rule here:

https://github.com/solsjo/rules_edalize

See the github actions for example invocation.

I did a small change in a copy of el_docker. I added support for providing additional docker flags. (Executing in docker in the Bazel sandbox results in the repo original source files not being available, if they're not added as extra volumes)

In either case, I don't really feel like it makes sense to add rules directly to the edalize repo. (Doesn't feel like core functionality) It might be better to keep it like this and refer to it in Bazel hdl rules?