[mathisfun123]

> Reading your answers, I've noticed that there appear to be some major misconceptions about Yosys and how it works

Indeed I opted to go with vivado instead of yosys (so i'm not an expert) but you're being a little disingenuous; there are absolutely places where yosys is explicitly, manifestly, being used as a scripting harness - you literally have ScriptPass

https://github.com/YosysHQ/yosys/blob/076c5ceb714bc8f20136a8...

and it is indeed used extensively for all of the flows:

https://github.com/search?q=repo%3AYosysHQ%2Fyosys%20ScriptP...

and so in particular, wanting to do synthesis for Xilinx, I was stuck basically commenting various lines in SynthXilinxPass::script

https://github.com/YosysHQ/yosys/blob/076c5ceb714bc8f20136a8...

to experiment with various flows. Now maybe you have/had a better way to do this but I couldn't find it.

[ZirconiumX]

...is your bugbear here that these particular scripts are written in C++ instead of Python?

Yes, those flows use ScriptPass, because for the most part they are scripts. If they were written in Tcl, then Yosys would need to depend on a Tcl interpreter, and equivalently a Python interpreter for Python. By just using C++ for these scripts which usually only developers need to modify, Yosys does not need to depend on either.

But anyway, if I was going to mess about with the flow that much, I'd start by running `help synth_xilinx`, which outputs a list of all the commands that it calls (more or less; it can't model control flow like a proper language can), and then that can be edited into what I need it to do.

[mathisfun123]

> ...is your bugbear here that these particular scripts are written in C++ instead of Python?

this isn't a bugbear - how should i, a user of yosys, that disagrees with the yosys devs about how the xilinx flow should work, proceed?

> By just using C++ for these scripts which usually only developers need to modify, Yosys does not need to depend on either.

you really don't understand how sequence of parameterized steps and compiled binary don't go together at all? see my first question.

> (more or less; it can't model control flow like a proper language can), and then that can be edited into what I need it to do.

again you're being disingenuous - the help message is right there in that file plain as day for everyone to see and the actual steps in the flows are also plain as day and there is an enormous gap in what can be adjusted and exists.

i feel like i'm taking crazy pills here - there's a reason why scripting interfaces are exposed at all right? i.e., tcl. because users need to be able to disagree/decompose/parameterize etc. and these example flows in yosys are frozen in stone (binary) instead of written as scripts that can be adjusted by users.

[rowanG077]

> this isn't a bugbear - how should i, a user of yosys, that disagrees with the yosys devs about how the xilinx flow should work, proceed?

There is a scripting engine in yosys called yosys script. It doesn't support logic but if you just want to run some commands it works fine.

There is also some basic TCL script support in yosys but I have never used it. So I can't really comment how well it works.

In addition a pass doesn't have to be inside the yosys tree for it to work. You can load any module at runtime. Sure this is not as quick to do then having a full scripting interface but you can be up and running within a few minutes.

[mathisfun123]

I feel like no one is understanding me - with how it's currently written (cpp scripting) nothing is reusable without copy-paste and then compile.

[ZirconiumX]

Sorry, I really don't see where the issue is.

Nothing forces you to use C++ scripting here; Yosys has a shell that you can enter commands in, and it takes via `-s` a file of commands; a script.

That the default scripts are written in C++ to not need dependencies does not mean you also need to write your scripts in C++.