Jeff Goeders

@mithro I agree. @Pocketkid2 There are "wrappers" that are calling the individual tools, and then there are the set of Python scripts that @mithro highlighted that are doing extra processing...

> @jgoeders - Basically, I'm pretty sure all the functionality should end directly in the VPR tool or Yosys plugin. OK, thanks. Good to know.

Since multiple small PRs is easier, I'll start with this PR which provides a basic backend, and will add more functionality through subsequent PRs.

>Is run_vtr_flow.py the entrypoint we should use? We do have the option to let Edalize take over the responsibility of this wrapper script and call the tools directly if we...

Some more followups: @olofk > Looking at the run_vtr_flow.py script I'm a bit confused about the arguments. It says usage = "%(prog)s circuit_file architecture_file [options]" but all the examples look...

@olofk Thanks for sharing https://github.com/olofk/edalize/wiki/Edalize-(Slight-return). I looked through this and it seems exactly what we would want to fully transition VTR to Edalize (whereas the current PR is just a...

OK, great, thanks for the update! I'm pretty tied up with other projects at the moment, so likely won't be able to get to it for a while. I have...

@olofk My students @Pocketkid2 and @schafernc are going to take a crack at this. As shown in your image above, the plan is to change the Makefile generated by Edalize...

@olofk See above. Can you point us to an example of using ESR? Thanks!

OK, those look like like nextpnr and Symbiflow backends. I thought in the VTR meeting we had discussed creating an Edalize backend specifically for VTR. Am I misunderstanding?