[mathisfun123]

> full disclosure: I work for YosysHQ

let me take this opportunity to ask a question about something that makes absolutely zero sense to me: why did yosys insist on sticking with tcl over some more modern/well-known/familiar scripting language? yes everyone has their favorite tcl scripts for vivado or intel or whatever but none of them are transferrable to yosys irrespective of that fact that yosys supports tcl.

further more, why is yosys itself basically scripting of ABC and nextpnr and etc using cpp instead of again using just some reasonable scripting language to connect the pieces?

> multi-electrostatic placer

um why? dreamplace exists? https://github.com/limbo018/DREAMPlace

[aseipp]

1. Because you will piss off would-be users. That simple. I have also complained about this endlessly. I also despise Tcl and had to use it to help automate lots of EDA tools in ASIC and FPGA designs, so I'm with you on this. But it isn't a hard question to answer in reality. Users will just be annoyed and think you are annoying and contrarian. (Nextpnr at least allows scripting with Python, and I'd ideally like to see other takes on synthesis in the next few years, thanks to more robust language frontends coming along.)

1.1. It is not "just scripting ABC", but ignoring that. I assume it's because Claire just liked C++. She was historically an embedded/hardware engineer. A lot of them like C++. But I can't read anyone's mind. The project is like, probably 15 years old now (the initial Git checkins from 2013 aren't even full replications of the real history, to my knowledge, which go further back into an ancient SVN server.) What would you have suggested using in 2010? Python with zero static typing and pip?

2. Because actually owning the code you write and ship to your users is a nice and good thing. Dreamplace is a DL-reinforced placer. It's an academic project. Having rode that bull (shipping academic code to production users and then having to rework it again and again), realistically, I'd probably reimplement Dreamplace directly into the codebase if I wanted to ship features to users. No offense but this isn't a SaaS service where the sausage machine is hidden; and most RTL engineers, nor I, want to install some giant annoying shitware ML stack into a python virtualenv to run Nextpnr. Just to be clear, if yosys uses some magical ML reinforcement learning, or doesn't, I don't care. It would be great if it did and it got a bajillion % higher QoR. But I don't want actually using the thing to be a giant pain in the ass.

Most open source software engineering isn't about being Super Epic. It's about meeting users where they are at and handling basic engineering constraints around the project. EDA is no different.

[mathisfun123]

> It is not "just scripting ABC",

I'm not downplaying the fact that yosys is a logic synthesizer - it's valuable and it's the only one of its kind. But that doesn't change the fact that many of the steps are just piping ABC or nextpnr or whatever and doing it using cpp. See https://github.com/search?q=repo%3AYosysHQ%2Fyosys%20ScriptP.... And like I know this not tangentially but because I tried use yosys but not all of yosys and it was impossible to decompose it.

> No offense but this isn't a SaaS service where the sausage machine is hidden; and most RTL engineers, nor I, want to install some giant annoying shitware ML stack into a python virtualenv to run Nextpnr. Just to be clear, if yosys uses some magical ML reinforcement learning, or doesn't, I don't care. It would be great if it did and it got a bajillion % higher QoR. But I don't want actually using the thing to be a giant pain in the ass.

I'm with you on every instance of this trueism except here, where runtime of the tool is not just important it's absolutely critical for DSE.

> Most open source software engineering isn't about being Super Epic

Again I agree with you in every other instance except here - just like LLVM and gcc can't be just oss, they need to be nuclear weapons grade software in order to have won mindshare (and investment) away from commercial compilers so does yosys.

So you can take me to task for being naive and arrogant but the reality is that the decisions made by yosys prevent further serious investment by anyone that's not playing with toys.

[ZirconiumX]

> > full disclosure: I work for YosysHQ

> let me take this opportunity to ask a question about something that makes absolutely zero sense to me: why did yosys insist on sticking with tcl over some more modern/well-known/familiar scripting language? yes everyone has their favorite tcl scripts for vivado or intel or whatever but none of them are transferrable to yosys irrespective of that fact that yosys supports tcl.

First: PYosys exists as Python bindings for Yosys, so you can in fact use a more modern scripting language for this.

Second: even if the Tcl scripts are not transferrable, a lot of our users do still have Tcl experience, and that transfers if nothing else.

But personally? For a lot of tasks you don't need a scripting language. If you want to turn a set of Verilog files into a JSON to pass to nextpnr-ecp5, that's `yosys -p "synth_ecp5 -abc9 -top top -json design.json" *.v` and there is neither Tcl nor Python involved here.

> further more, why is yosys itself basically scripting of ABC and nextpnr and etc using cpp instead of again using just some reasonable scripting language to connect the pieces?

Yosys is not simply some scripting around ABC: you need to parse input files, store this in an intermediate representation (RTLIL), elaborate and monomorphise the input structure, perform optimisation and logic minimisation on it; you need to map large structures like memories, hard multipliers and carry chains (ABC can't do that), legalise flop types and only then can you pass the logic to ABC. Once you get that logic from ABC, you need to turn it into cells that tooling recognises.

That the "script passes" we have that most front-end users use are so simple is because the complex logic is packed into neat passes to call.

> > multi-electrostatic placer

> um why? dreamplace exists? https://github.com/limbo018/DREAMPlace

We're aware of DREAMPlace, however: DREAMPlace itself is for ASIC applications, so you'd want to use DREAMPlaceFPGA instead, which is...limited to a simplified Xilinx architecture or whatever partial FPGA Interchange Format support they have. We consider speed a feature, and having to deserialise the target device and netlist into FPGA Interchange Format in the hopes that DREAMPlaceFPGA can understand it is...not fast.

So instead we're working on our own multi-electrostatic placer which can more tightly integrate with nextpnr than something using DREAMPlace[FPGA] could.

[mathisfun123]

these are legit answers so thank you for them and i'm sorry for coming off as angsty.

[ZirconiumX]

Reading your answers, I've noticed that there appear to be some major misconceptions about Yosys and how it works: certainly, ABC is a core part of a standard synthesis flow, but Yosys is based around a series of passes that modify a common intermediate representation. That should mean if anything it is very easy to use only part of Yosys.

Obviously it'd be off-topic to try to discuss your particular needs and use-cases of Yosys here, so feel free to email me at [e-mail].

[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.

[stefanpie]

I think there is a big difference between published academic tools that work on a specific benchmark format versus an academic tool that has been integrated into a robust EDA toolflow. Also, note that dreamplace is simply accelerated electrostatic placement tool using deep learning frameworks to take advantage of GPUs. Electrostatic placement is not a new concept and is not specific to dreamplace.

[mathisfun123]

> Also, note that dreamplace is simply accelerated electrostatic placement tool using deep learning frameworks to take advantage of GPUs. Electrostatic placement is not a new concept and is not specific to dreamplace.

I don't know why you're explaining this to me (I've made contributions to dreamplace). my point is why reinvent a very well-functioning wheel?

[AshamedCaptain]

> yes everyone has their favorite tcl scripts for vivado or intel or whatever but none of them are transferrable to yosys irrespective of that fact that yosys supports tcl.

But still it is much easier to have one Tcl script with conditionals targeting all the tools than a myriad scripts in various language-of-the-week. Tcl is just good enough, and extremely "well known".

[mathisfun123]

> various language-of-the-week

Python is a "language of the week"? While absolutely no one uses tcl except EDA.

[AshamedCaptain]

Yes it is. Some time ago this discussion would have been about Perl, some more time ago it would have been about C shell. If you jumped on all thee languages you'd be in a much terrible situation than you are now. And we are literally talking about EDA here, where you can find way more engineers who know C shell than engineers who know Sh or Bash (or Python).

[musicale]

There are some things I like about tcl (and Tk) but I can't imagine choosing a scripting language other than python today.

[ZirconiumX]

Well, at least part of this comes down to the fact that we did not choose a scripting language today, but at least a decade ago where Tcl was dominant in EDA and Python would not have been taken seriously.