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

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

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

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

[musicale]

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

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