Refactor Yosys for f4pga/symbiflow usage

[Pocketkid2]

This contains the changes to Yosys which allows it to work with the F4PGA flow.

What F4PGA does is use its own TCL script for synthesis, then runs its own python script, and then runs another call to Yosys to generate the final .eblif file.

All of the required values are passed in through an array. Because the TCL scripts look for environmental variables, they are in the passed-in array and are put before the command itself so as to avoid using environmental variables in the Makefile.

I'd love to get your thoughts on this. I know it looks messy and I would be happy to document it in whatever way you think proper. Ideally, this would only be used by the F4PGA flow.

On a side note, the array size can be reduced by taking advantage of the template variable for one of the script paths, which may help in preventing unnecessary template generation. I can take care of that if you like this PR as a whole and are willing to move forward with it.

[olofk]

I think we need to take another look at this. In my mind we should only need to have split_io being a boolean to select whether to run that extra step or not. We can't put the command itself as a tool_option, because the location will vary between different computers. However, if f4pga sets up something like, I donẗ know, $F4PGA_ROOT, then we could ensure that variable has been set and set the script path to $F4PGA_ROOT/path/to/split_io. The original f4pga scripts must find it somehow so there has to be some mechanism for getting the location that we can reuse.

(Speaking of finding... I couldn't find the split_io script now. Searched through the whole f4pga github organization without a single hit. Must be missing something. Could you point me to where the script is, so that I can take a look at it?)

As for the other vars, split_io_list[0] [1] and [2] seems like input/output files and we should decide the name of those by ourselves instead of letting the user do that. split_io_list[3] is the name of the script that was handled in the paragraph above. If split_io_list[4] are extra args to the script and we need the user to set those, then perhaps we should put that in a split_io_options tool option. split_io_list[5] is part of a yosys command-line? Can you elaborate on that one split_io_list[6] and [7] are env vars, I presume. If we know which vars to set and their values, then I suggest setting those explicitly here.

[olofk]

Ok, so the script is called split_inouts.py and I noticed just now that @umarcor moved it between two repos 7 hours ago, so I believe we have some syncing up to do. Hey @umarcor. Want to join the discussion? :)

[Pocketkid2]

I think we need to take another look at this. In my mind we should only need to have split_io being a boolean to select whether to run that extra step or not. We can't put the command itself as a tool_option, because the location will vary between different computers. However, if f4pga sets up something like, I donẗ know, $F4PGA_ROOT, then we could ensure that variable has been set and set the script path to $F4PGA_ROOT/path/to/split_io. The original f4pga scripts must find it somehow so there has to be some mechanism for getting the location that we can reuse.

@olofk The reason I have the variables passed in via list instead of just triggered via boolean is that I really don't want to hardcode any values or even variables into Yosys, because F4PGA isn't stable enough in the long term and I'd rather have all that stuff inside the F4PGA flow. (i.g. the variable names might change, or the paths of the scripts might change, etc.)

(Speaking of finding... I couldn't find the split_io script now. Searched through the whole f4pga github organization without a single hit. Must be missing something. Could you point me to where the script is, so that I can take a look at it?)

On my install it's inside the scripts folder (~/opt/f4pga/xc7/share/f4pga/scripts) as split_inouts.py

As for the other vars, split_io_list[0] [1] and [2] seems like input/output files and we should decide the name of those by ourselves instead of letting the user do that. split_io_list[3] is the name of the script that was handled in the paragraph above.

This has just now been updated in commit 2ab019b to remove [0], [1], and [2] since they can already be obtained or inferred.

If split_io_list[4] are extra args to the script and we need the user to set those, then perhaps we should put that in a split_io_options tool option. split_io_list[5] is part of a yosys command-line? Can you elaborate on that one split_io_list[6] and [7] are env vars, I presume. If we know which vars to set and their values, then I suggest setting those explicitly here.

split_io_list[4] and [5] are the args for the first and second calls to yosys, respectively. [6] and [7] are the variables needed for those calls, respectively. I think it is necessary for the variables to be passed in because they are unique to F4PGA and may change in the future. With commit 2ab019b these indexes are now [1], [2], [3], and [4] respectively (with [0] being the path of the python script).

I can leave comments explaining the array values the Yosys tool class if you'd like, although it should become clear when it is implemented in the F4PGA flow.

[Pocketkid2]

Ok, so the script is called split_inouts.py and I noticed just now that @umarcor moved it between two repos 7 hours ago, so I believe we have some syncing up to do. Hey @umarcor. Want to join the discussion? :)

Oh, this is interesting. Looks like I need to update my F4PGA

[Pocketkid2]

Ok, so the script is called split_inouts.py and I noticed just now that @umarcor moved it between two repos 7 hours ago

Commit 3c323d8 reflects the new way of accessing the split_inouts.py script, with the added benefit of reducing the number of passed in values by one

[umarcor]

@olofk @Pocketkid2 we are working on moving the python scripts which are currently distributed in the arch-defs tarballs to be shipped along with f4pga. At the same time, as @Pocketkid2 noted, we are making them usable by importing them in python or externally (either through the module or through command f4pga utils ...). See https://github.com/chipsalliance/f4pga/pull/613 and https://github.com/SymbiFlow/f4pga-arch-defs/pull/2826. By using the utils command, further modifications (moving the scripts within the f4pga package) should be transparent. However, if the location of the script or the module are used explicitly (as done in this PR at the moment) they might need to be adapted. I recommend to use pinned versions of arch-defs and f4pga until these changes are stabilized. See https://f4pga.readthedocs.io/en/latest/development/changes.html.

Nonetheless, split_inouts.py was added to repo f4pga 3h ago (https://github.com/chipsalliance/f4pga/pull/625) and it was not removed from the arch-defs tarballs yet (https://github.com/SymbiFlow/f4pga-arch-defs/pull/2883). Therefore, even if you are using the latest arch-defs and 'main' f4pga, you should not be affected by these changes yet.

[olofk]

Yes! f4pga utils is exactly the kind of command I was hoping to see! I haven't familiarized myself with the f4pga codebase yet, so can you please show an example of how to use it? I couldn't figure out how to install the python modules.

[olofk]

@umarcor I saw a script running python3 -m f4pga.utils.split_inouts -i ${OUT_JSON} -o ${SYNTH_JSON}. Is that the proper way to invoke the tool? f4pga --help (installed with pip install --user -e . from the f4pga subdir) doesn't list utils as a subcommand

[olofk]

@Pocketkid2 I think things are starting to clear up now and that we can simplify a lot of things. One thing remaining is the env vars that we send to yosys in the last step after running split_inouts. IIRC that last yosys invocation only converts from json to (e)blif. Do we really need any env vars for that? What's the name of the tcl script yosys runs? I guess it's supposed to go into split_io_list[1] but I'm not sure where that is defined.

EDIT: I remember now. It's in conv.tcl now called conv.f4pga.tcl (right @umarcor ?)

EDIT2: They all just run opt_clean and different variations of write_blif and only need $::env(OUT_EBLIF) to set the output file name. Except for xc7 which also uses an USE_LUT_CONSTANTS env var that I don't know the purpose of. (Do we need to care about that one at all? One solution would be to reconstruct this command-line and just send to yosys to avoid the need of the tcl file in the first place, but if f4pga changes those, then we need to keep them up to date ourselves. Other option is to just pass OUT_EBLIF (which we know the value of ourselves) and maybe USE_LUT_CONSTANTS if that's something users are supposed to touch

[umarcor]

@olofk f4pga utils was not merged into main yet. That's why you see python -m ... used in the code, and there is no matching argparser to produce a help. Let me provide the context. We want to:

• Move into the f4pga python package all the python/shell/tcl scripts that are currently distributed as apparently standalone scripts, but which do depend on each other (i.e. remove the scripts subdirs from arch-defs tarballs).
• Convert all the (deprecated) shell scripts to python, in order to:
  • Make f4pga usable on any platform (i.e. do not depend on bash).
  • Have CLI help and documentation automatically generated (i.e. bring https://f4pga.readthedocs.io/en/latest/f4pga/Deprecated.html up to date).
• Provide APIs, i.e. make it explicit which functions/utils/commands are expected to be used/called as independent entrypoints (regardless of them being also used "internally" by either the "deprecated" wrappers or the "new" flow), instead of having hardcoded paths everywhere.

So, we are in the middle of this process:

• chipsalliance/f4pga#612 moved most of the code from the deprecated shell scripts into python, and it converted some of it to python functions.
• chipsalliance/f4pga#625 was a proof of concept, to replace the usage of envvars UTILS_PATH with either calling a function (https://github.com/chipsalliance/f4pga/pull/625/files#diff-21fc80edb6ae994e56f4ea83e3c680f50a7b4cf5570867a968129450a9d73a4cR87) or using python -m ... (https://github.com/chipsalliance/f4pga/pull/625/files#diff-cee356eda16cdc418e92c316d0e4e2cbf1020eb55433cab80c1f305072d0bb69R142). See also https://github.com/SymbiFlow/f4pga-arch-defs/pull/2883.
• chipsalliance/f4pga#626 replaced sourcing vpr_common.sh with parsing args and setting envvars in Python.
• chipsalliance/f4pga#630 got rid of redundant envvars and changed several external (python -m) to function calls.
• chipsalliance/f4pga#631 moved the remaining python scripts from xilinx arch-defs tarballs into f4pga. Note that the imports were changed to f4pga.utils..., so that they don't depend on manually adding paths to PYTHONPATH. See also https://github.com/SymbiFlow/f4pga-arch-defs/pull/2888.
• chipsalliance/f4pga#613 will move the remaining python scripts from quicklogic arch-defs tarballs into f4pga, and it will add the 'f4pga utis` command. See https://github.com/chipsalliance/f4pga/pull/613/files#diff-541244fbbd227aaadf6e1c0c63d0515eae673e2b4a43c08f1aa2744cb927eb81R177. See also https://github.com/SymbiFlow/f4pga-arch-defs/pull/2826.
• After merging chipsalliance/f4pga#613, we will hopefully get rid of the remaining hardcoded calls to "external" python scripts in https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/init.py.
  • There are still three shell scripts, though (see https://github.com/chipsalliance/f4pga/tree/main/f4pga/wrappers/sh/quicklogic and https://github.com/chipsalliance/f4pga/tree/main/f4pga/wrappers/sh/xc7). And some of the arg parsing needs to be converted to python: https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/init.py#L609-L629. That will be the remaining work before automatically generating all the docs (for the deprecated commands/entrypoints, for the utils, and for the new flow).

Therefore, if you want to implement this PR as if f4pga utils existed, you need to:

• Remove subdir scripts from the arch-defs tarballs (use the latest). See https://github.com/antmicro/f4pga/blob/umarcor/ql/python/scripts/prepare_environment.sh#L73.
• Use pip install https://github.com/chipsalliance/f4pga/archive/pcza/ql/python.zip#subdirectory=f4pga or pip install https://github.com/chipsalliance/f4pga/archive/umarcor/ql/python.zip#subdirectory=f4pga from the antmicro fork of f4pga.

Alternatively, you can use python -m ... for all xilinx targets with the main f4pga branch; and later update them, when the utils command is merged.

In any case, during this process, it would be really helpful if you let us know which utils/scripts/resources are being used by edalize "directly". Until now, nothing was explicitly public or private, so everyone was hardcoding the paths and manually plugging the scripts. As part of the cleanup process, we want to make it explicit which resources are public (expected to be called by others) and which are private (called by other scripts/functions within the f4pga package, but not externally). That will help us do refactorisations/cleanups in the future without breaking other projects. In the current implementation of f4pga utils, everything will be exposed, but we might change it to "known set of utils" rather than catching them all. Moreover, as we discussed in other issues/threads, some of those utils should eventually be moved into yosys/vpr and not be part of f4pga.

EDIT: I remember now. It's in conv.tcl now called conv.f4pga.tcl (right @umarcor ?)

Yes. However, similarly to the shell scripts, we are also providing minimal functionality to avoid hardcoding the location of the TCL scripts. See https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/xc7/synth.f4pga.sh#L21 and https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/xc7/synth.f4pga.sh#L140. Or, if you are using it from Python: https://github.com/chipsalliance/f4pga/blob/9946ed7f3d13f3fc7d2a764a812894c5eeca668a/f4pga/flows/common_modules/synth.py#L25 and https://github.com/chipsalliance/f4pga/blob/9946ed7f3d13f3fc7d2a764a812894c5eeca668a/f4pga/flows/common_modules/synth.py#L97-L99. It will use envvar FPGA_FAM by default, but you can pass the arch/family as the second argument: https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/quicklogic/synth.f4pga.sh#L124-L125.

Overall, your questions about the envvars are very pertinent and I'd also like to understand it better. Until now, that huge vpr_common.sh was sourced in almost all of the scripts (which sometimes call each other, thus sourcing it again). During the conversion from shell to python, I found that some functions/scripts were relying on local variables which were not explicitly exported. After we finish converting the synth.f4pga.sh scripts to python, it will be easier to clean that up.

[Pocketkid2]

@Pocketkid2 I think things are starting to clear up now and that we can simplify a lot of things. One thing remaining is the env vars that we send to yosys in the last step after running split_inouts. IIRC that last yosys invocation only converts from json to (e)blif. Do we really need any env vars for that? What's the name of the tcl script yosys runs? I guess it's supposed to go into split_io_list[1] but I'm not sure where that is defined.

EDIT: I remember now. It's in conv.tcl now called conv.f4pga.tcl (right @umarcor ?)

EDIT2: They all just run opt_clean and different variations of write_blif and only need $::env(OUT_EBLIF) to set the output file name. Except for xc7 which also uses an USE_LUT_CONSTANTS env var that I don't know the purpose of. (Do we need to care about that one at all? One solution would be to reconstruct this command-line and just send to yosys to avoid the need of the tcl file in the first place, but if f4pga changes those, then we need to keep them up to date ourselves. Other option is to just pass OUT_EBLIF (which we know the value of ourselves) and maybe USE_LUT_CONSTANTS if that's something users are supposed to touch

@olofk USE_LUT_CONSTANTS and OUT_EBLIF are the only variables in the conv.tcl script, and although we can easily take care of OUT_EBLIF like you mentioned, that leaves the other flag. I'm leaning towards leaving it in for compatibility's sake, but if you think we should keep optimizing further we might want to hear more from @umarcor about it.

Edit: Should clarify that USE_LUT_CONSTRAINTS isn't being set anywhere in the main f4pga codebase, only checked for in the TCL script

[olofk]

@umarcor I'm extremely happy to hear about this cleanup. The current Symbiflow integration is very suboptimal because it uses those bash shell scripts instead of having Edalize call the tools directly, which means that we're missing out on most of the features Edalize can provide and the Edalize symbiflow code is a mess. I have tried myself a couple of times to dig through that wall of tcl/bash/python but never got further enough than to submit some tiny clean-up patch.

I have been hoping for years to improve the symbiflow (now as f4pga) backend so I was very excited to see @Pocketkid2 taking on this task. Since we have been calling the shell scripts previously, we don't rely on any env vars or specific setups and I would prefer not to do that unless completely necessary.

So I guess it's both good and bad that we're working on this in the middle of a big f4pga refactoring. The bad side is that things might not be completely ready yet, but the good thing is that we will be early adopters and can hopefully affect things to make the edalize integration even smoother.

[olofk]

@Pocketkid2 I noticed that too about USE_LUT_CONSTANTS. I have a vague memory now that it was used in some cases when doing P&R for just a small part of the device. But I wonder if that's a feature more for the developers of the P&R tool than for the users. And in that case, I suspect the devs will not run through Edalize anyway. Searching through all of github I only find what looks like two test cases setting it, so I suggest dropping it actually.

I think this means that the only items from split_io_list we need to resolve are [0] and [2], i.e. args and env vars for the first yosys invocation. You mentioned that f4pga uses a different synthesis script than the other edalize backends. What script does it use and can we unify those scripts?

EDIT: I see now that it uses the scripts in f4pga/wrappers/tcl/*/synth.f4pga.tcl. Those are reasonably complex so we should reuse them for now. Long-term I would like to split them up a bit so that the ordinary Edalize main tcl yosys file can just source them to get the extra stuff needed, but that's for another day. The thing we should look at here is what env vars these scripts expect and if we know the values of them without involving the user

[olofk]

I mapped out all the env vars used in the various synth tcl scripts and it looks like this f4pga/wrappers/tcl/eos-s3/synth.f4pga.tcl: DEVICE_CELLS_SIM OUT_SYNTH_V OUT_JSON PCF_FILE PINMAP_FILE PYTHON3 TECHMAP_PATH UTILS_PATH

f4pga/wrappers/tcl/ice40/synth.f4pga.tcl: OUT_JSON OUT_SYNTH_V

f4pga/wrappers/tcl/qlf_k4n8/synth.f4pga.tcl: TECHMAP_PATH SYNTH_OPTS OUT_JSON OUT_SYNTH_V

f4pga/wrappers/tcl/xc7/synth.f4pga.tcl: INPUT_XDC_FILES OUT_FASM_EXTRA OUT_JSON OUT_SDC OUT_SYNTH_V PART_JSON PYTHON3 TECHMAP_PATH TOP USE_ROI

I'm pretty sure most of them are just filenames that we can set as we wish. Some of them also seem to be alternative ways of loading extra files, which we don't need to support.

[Pocketkid2]

@olofk I think we still need the conv.tcl script because it converts the json netlist to eblif form (I'm not 100% sure why but I think VPR needs a blif/eblif and not json)

I will go through all those variables and write the ones in Yosys that we reasonably can (a few of them do rely on f4pga install paths so those are still going to need some kind of path variable passed in)

[umarcor]

The current Symbiflow integration is very suboptimal because it uses those bash shell scripts instead of having Edalize call the tools directly, which means that we're missing out on most of the features Edalize can provide and the Edalize symbiflow code is a mess. I have tried myself a couple of times to dig through that wall of tcl/bash/python but never got further enough than to submit some tiny clean-up patch.

Since we have been calling the shell scripts previously, we don't rely on any env vars or specific setups and I would prefer not to do that unless completely necessary.

As shown in https://github.com/olofk/edalize/issues/323#issuecomment-1170137415 symbiflow/f4pga has a lot of scripts, at different layers of abstraction. Most "consumers" call them as black boxes from the higher abstraction entrypoints, so there was no need to understand the internal details. However, that's a maintenance nightmare because the lack of explicit and organised documentation hits developers frequently. Using three different languages makes it more complex, because it's not comfortable to inspect/use variables/functions across them.

As a result, it is not trivial for Edalize (or any other project) to call the tools "directly" and "once only", assuming that "the tools" are yosys and vpr. Both Xilinx and QuickLogic flows do have "patches" between stages/passes, and some of those patches depend on the envvars set in higher abstraction scripts, but it's not explicit. Therefore, rather than reimplementing the synth shell scripts in edalize, I would recommend edlize to consume the corresponding function in python. Currently, https://github.com/chipsalliance/f4pga/blob/main/f4pga/wrappers/sh/init.py#L544 is expecting CLI args only. We should rework it as done in https://github.com/chipsalliance/f4pga/blob/main/f4pga/utils/xc7/create_place_constraints.py#L1113-L1181, so that we have a function with args, and a wrapper that handles CLI args. If edalize consumed p_synth, we might have additional options/arguments in there to fit edalize's needs, but without breaking the backwards compatibility with consumers calling symbiflow_synth. Then, the functionality of edalize's symbiflow/f4pga stage would be "get data from EDAM and call the coarser or fine-grained functions in f4pga". In the near future, when the synth scripts in f4pga are completely converted to python and with f4pga utils available, it will be easier (if necessary) for edalize to go one step lower in the abstraction and reimplement synth/p_synth instead of consuming it. IMHO, the power of edalize is providing multiple pre-synthesis stages, calling the adequate synth command, calling the PnR (which might involve multiple calls) and getting results/stats from them. I don't see the benefit of reimplementing the synth function, because that's just one of the many functions in f4pga that are used either explicitly or implicitly. We would first need to move all the lower abstraction utils into yosys and/or vpr, so that then edalize can provide f4pga flows without f4pga.

With regard to TCL scripts, I believe they exist because of the complexity to manage lists of lists, structs, etc. in bash. Originally, it was all done with makefiles and shell scripts only, so TCL was the obvious approach to put "complex" logic into the yosys pipeline. However, we are now dealing with it through Python. Hence, eventually, we can generate the specific sequence of commands with all hardcoded content, so that no TCL logic is needed. I.e., we might replace the current TCL scripts with templates. That will get rid of all the envvars in favour of explicit args with proper type checking.

[olofk]

@olofk I think we still need the conv.tcl script because it converts the json netlist to eblif form (I'm not 100% sure why but I think VPR needs a blif/eblif and not json)

Yes, that's correct. The json format was invented by the yosys devs when they developed nextpnr but AFAIK no other tools use this format. Yosys can write blif directly, but since we need to do some extra hacks we first write out json, then do some extra operations on the json file (i.e. split_inouts) and then call yosys again to convert the hacked json to blif using conv.tcl. (This is also why I suggested running split_inouts directly from within yosys, so that we only need to call yosys once, and split_inouts would just be an extra line in synth.tcl. But let's not go there)

I will go through all those variables and write the ones in Yosys that we reasonably can (a few of them do rely on f4pga install paths so those are still going to need some kind of path variable passed in)

I believe the f4pga utils command that @umarcor mentions is the way to go. We should be able to query that to get the installation path. But if that's too far in the future to be used, then I'm fine with using some env var pointing to the install dir in the meantime.

[olofk]

@umarcor I'm trusting your judgement on what would be the best layer of abstraction to call the EDA tools. Since Edalize is an abstraction layer we can always dig deeper later on if needed, but I really don't want to duplicate too much of what's inside f4pga. A sweet spot for me would be, as you mention, to e.g. call yosys directly from Edalize but using the f4pga synth scripts for all the device-specific quirks.

Let's speak more about this at FPGA World in two weeks also :)

[kboronski-ant]

Okay, so there's a couple of things here:

First, I don't think you should depend on directly using Tcl scripts that are part of f4pga. Those scripts can (and will) change, including the environment variables. In fact, there's a PR that replaces direct references to environment variables with calls to a procedure that's internally provided by f4pga.

To interact with f4pga, you should not be calling individual scripts. The fact that you can call python3 -m f4pga.utils.split_inout as a standalone thing is only a temporary solution. The intended use of the python tool is to provide it with inputs, ask for a given output and let it do the rest. You can provide it with verilog and ask for eblif for example:

(When running the tool from terminal):

f4pga build -p XC7A35TCSG324-1 -t eblif -Dsources=[top.v] -Deblif=output.eblif -Vtop=top

(When using f4pga directly in python):

# These might get moved in the future
from f4pga.flows.commands import make_flow_config
from f4pga.flows.flow import Flow
from f4pga.flows.flow_config import ProjectFlowConfig
from f4pga.flows.common import set_verbosity_level

# Set amount of information on stdout (optional)
set_verbosity_level(2)

part_name = "XC7A35TCSG324-1"
# F4Cache object can be None. It's used for incremental builds.
f4cache = None

# Configure inputs and outpus
project_flow_cfg = ProjectFlowConfig("")
project_flow_cfg.flow_cfg  = {
    part_name: {
        "dependencies": {
            "sources": ["top.v"], # list of verilog sources
            "eblif": "path/to/eblif/output.eblif" # optional, use it to override default output path of eblif
        },
        "values": {
            "top": "top" # top module's name
        }
    }
}
# Build complete config using user's inputs and flow definitions provided by f4pga
flow_cfg = make_flow_config(project_flow_cfg, part_name)
# Build complete flow for target "eblif".
flow = Flow(target="eblif", cfg=flow_cfg, f4cache=f4cache)
# Execute the flow. Will produce the results or raise an exception.
flow.execute()

In other words, either use yosys directly and you own copy of python and Tcl scripts, leaving f4pga uninvolved, or call f4pga to produce a desired results - in this case you could wrap synth stage of f4pga flow as an Edatool. Stages available for a given platform are described in https://github.com/chipsalliance/f4pga/blob/main/f4pga/flows/platforms.yml

In regards to f4pga utils - this concept to have a separate command is new to me. I will have talk with @umarcor further about it, so we have a mutual agreement on how would such thing work. If there are utilities which are particularly useful it might make some sense to have an extra simpler interface for them. I'm not sure if split_inouts is such an utility tho.

[Pocketkid2]

@olofk Take a look at f37b08c and see what you think. I've gotten it down to just two single variables, neither of which can be resolved from information inside Yosys (input xdc constraints files used in the TCL scripts and the JSON part architecture file which can be resolved with device, part, and prjxray information). It should be noted that the F4PGA_SHARE_DIR environmental variable will be required, but this should be easy to point out or create automatically in F4PGA.

[Pocketkid2]

@olofk What's the status on this?

[olofk]

@kboronski-ant Is there any reason why you created a new project configuration format instead of reusing the EDAM format? I think it would be excellent to have that as an interchange format between Edalize, F4PGA and SiliconCompiler and in the long term I'm hoping to push support for it directly into the various EDA tools.

And regarding using the f4pga python wrappers or calling the tools directly, I think there are benefits for Edalize to go directly. That means we can use the Edalize features that comes with all the other backends, like launcher files, tcl scripting and tool-specific escaping of defines/parameters/plusargs, etc. But at the same time it would be nice to not duplicate the synth tcl scripts, so having them available through a utils command would be great.

A question. Have you considered instead to build the f4pga tooling on top of the Edalize EdaTool class? That was what I thought was the initial idea when I first heard about an f4pga refactoring.

[olofk]

@Pocketkid2 It looks much better now! Happy to see things keep getting simplified. There are still too many env vars and I'm sceptical towards exposing the f4pga_synth tool option like that, but it shouldn't hurt anyone so I think we can leave it as is for now and move on to other things.

The one thing I'm most worried about right now is having xc7_vpr hardcoded in TECHMAP_PATH. Doesn't that limit the use of this backend to only work for the AMD 7-series devices? Maybe that's ok to start with, but I want to know if that's the case.

[Pocketkid2]

The one thing I'm most worried about right now is having xc7_vpr hardcoded in TECHMAP_PATH. Doesn't that limit the use of this backend to only work for the AMD 7-series devices? Maybe that's ok to start with, but I want to know if that's the case.

This had slipped my mind because most of what F4PGA supports right now is the xc7 stuff. Probably should fix that although I'll have to check with the latest versions of the architecture to see their paths (and if their paths have even been harmonized with the xc7 paths yet which was a big issue for me a month or two ago looking into supporting those other architectures with Edalize)

[Pocketkid2]

@olofk 4f54526 should fix it for the time being, although on my install it's showing the eos-s3 techmap files being installed inside the xc7 environment, not sure if that's an issue on my end or one that f4pga is still working on.

edit: I now realize that change won't actually really fix the problem until the f4pga install paths are harmonized (which is a known issue), so I reverted the commit and hope that you will allow it in like it is now for the present until we can properly fix it

[olofk]

Yeah, I think we'll let it be for the time being. There were a lot of inconsistencies in symbiflow and f4pga is a moving target so we'll try to finish this up and revisit later when the dust has settled. Pulling this is now unless you have any other last-minute changes. Just let me know

[Pocketkid2]

@olofk no I'm good, pull it in. If I have further tweaks to make they will be included in the PR that has the main F4PGA flow

[olofk]

Woohoo! After some git fiddling it's merged now. Thank you for your contribution