Open Pocketkid2 opened 2 years ago
For context:
@umarcor - It would nice if most of the scripts listed under arch-defs-install went away;
@mithro, agree. Is it within the scope of this issue? The description mentions "shell wrappers", not "Python wrappers".
@mithro, agree. Is it within the scope of this issue? The description mentions "shell wrappers", not "Python wrappers".
@schafernc and I have been directed to make the Edalize backend call the tools directly without the need for additional python wrappers (because Edalize is already a python module). We are, however, using the existing wrappers as a guide to help us design the new F4PGA Edalize backend so that it works in roughly the same way.
@umarcor - Well, I was thinking that the work making edalize call the python scripts might be better spent making the python scripts disappear...
@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 along the way.
We will start by getting rid of the wrappers, but still call those Python scripts (just to get functionality deployed faster), but then we should tackle those Python scripts as well. We will need to look at them on a case-by-case basis to see if they should be migrated into the Edalize sub-tool, or whether it's better to make modifications to the tools themselves (eg modify VPR). I'm not familiar with these scripts enough to know.
@Pocketkid2 Can you add a new task item above with these scripts (with sub-bullet items for each script)?
@jgoeders - Basically, I'm pretty sure all the functionality should end directly in the VPR tool or Yosys plugin.
@jgoeders - Basically, I'm pretty sure all the functionality should end directly in the VPR tool or Yosys plugin.
OK, thanks. Good to know.
@kgugala / @acomodi - Antmicro where involved in creating a lot of these "extra" Python scripts, can you help advise?
@Pocketkid2, there are five sets of "scripts":
symbiflow_*
script, a Python function exists. The Python function is used to generate an entrypoint through setup.py
, and it calls the corresponding shell/bash script. See https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/__init__.py and https://github.com/chipsalliance/f4pga/blob/main/f4pga/setup.py#L53-L77.Therefore, Python is both on top and below the TCL/Bash scripts. Replacing the Bash scripts with Python code is technically straightforward because those are isolated. I.e., you can fork f4pga and replace the wrapper functions with any Python code to test backwards compatibility of the Python implementation. However, the lowest abstraction python scripts were not isolated yet. Those should be identified and moved somewhere else (VPR, Yosys, plugins, f4pga...), to decouple them from the arch-defs packages/tarballs.
We have come full circle. I was just looking at @Pocketkid2's propsed changes to yosys regarding split_io and was wondering if my tcl/python cleanup patch (https://github.com/SymbiFlow/f4pga-arch-defs/pull/2371) was merged, when I saw it was mentioned here :)
Generally, Edalize doesn't benefit from utility tools being written in Python since it needs to make an external call to each tool anyway. This is to keep the abstraction and being able to push out each tool invocation to different hardware if so needed (think SLURM or CI pipelines).
My approach to the split_io script, which is one of those custom scripts used, was to call it from a tcl file which we tell yosys to execute. The end result is that we only call yosys once, and it will do the magic internally.
I'm not familiar enough with the other scripts, but hopefully we can dig into those as well and move bits and pieces to other places
My approach to the split_io script, which is one of those custom scripts used, was to call it from a tcl file which we tell yosys to execute. The end result is that we only call yosys once, and it will do the magic internally.
I fully support this answer, I'll add it to the list
This is an ongoing project that @schafernc and I are working on as undergrad students under the supervision of @jgoeders. This is essentially our attempt at implementing #302 to rework the F4PGA/Sybmiflow Edalize backend.
F4PGA right now is a simple flow that calls Yosys for synthesis and VPR or NextPNR for place and route. It also adds some extra commands at the end for FASM and bitstream generation.
Tasklist (New, updated 12 Oct 2022):
Tasklist (Old):