[ZirconiumX]

full disclosure: I work for YosysHQ, who have an alternative open-source place-and-route program - [nextpnr](https://github.com/YosysHQ/nextpnr/) - and YosysHQ presently has [a grant](https://activities.esa.int/4000141380) from ESA on improving nextpnr.

to be blunt: nextpnr is what happens when you look at VPR as prior art and base every design decision around doing the opposite of VPR.

VPR is flexible, true: you can define an architecture description inside an XML file, but I view the VPR XML format to be poorly considered.

- commonly in an FPGA you will have "legality constraints" - for example, a block of LUTs cannot simultaneously be in carry-chain mode and act as LUT RAM. to produce a legal solution, all these constraints must be satisfied. to nextpnr this is [two basic](https://github.com/YosysHQ/nextpnr/blob/master/docs/archapi....) [API calls](https://github.com/YosysHQ/nextpnr/blob/master/docs/archapi....). to vpr, you must [walk the architecture](https://github.com/verilog-to-routing/vtr-verilog-to-routing...) to discover and cache legal placement positions. - VPR often requires significantly more detail about an FPGA than is easy to provide; for example, [how switchboxes are laid out](https://docs.verilogtorouting.org/en/latest/arch/reference/#...), or [routing metal resistance/capacitance](https://docs.verilogtorouting.org/en/latest/arch/reference/#...). to nextpnr, routing is just nodes and edges on a graph.

Further, VPR's algorithms tend not to be designed with performance in mind; simulated annealing as a placement method does not scale well past the tens of thousands of LUTs, which is why nextpnr moved from full simulated annealing to [heterogenous analytic placement](https://ieeexplore.ieee.org/document/6339278), and recently we have been working on a [multi-electrostatic placer](https://dl.acm.org/doi/abs/10.1145/3489517.3530568); both significantly more scalable methods based on using mathematical optimisation methods to place things nearby.

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

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

[stefanpie]

Awesome, thank you for the details and looking froward to the work with more funding! I have yet to look into the details of nextpnr and this is a great set of of resources for me to get started. I am working on some "deep learning for FPGA implementation" projects and it would be neat to see if I can plug nextpnr into my work. I think (from my point of view), VTR is more of a generic architecture exploration tool / academic tool with a more top down approach hence the arch def files and so on.

[ZirconiumX]

If you have any questions about nextpnr, feel free to email me at [e-mail].