Add fasm2bels flow to symbiflow

[mtdudek]

Signed-off-by: Maciej Dudek [email protected]

[acomodi]

@olofk Can you please take a look at this PR?

fasm2bels is an enhancements to the symbiflow toolchain that enables to regenerate the original verilog design starting from a bitstream or a FASM file (only for xc7 at the moment)

[olofk]

I think this would make sense to do with the new flow API instead and let the fasm2bels script become a separate tool that can be plugged in after bitstream generation in Vivado and symbiflow flows. We would need to convert symbiflow to the new API first though. What do you think?

[acomodi]

Hi @olofk, yeah, that makes sense to use the new API, and the starting point would be indeed symbiflow in general, for which, as far as I understand we'd need to create a set of tools that will than be included within symbiflow, similarly to how the icestorm flow is set-up.

This lets me wonder on what the best approach could be to re-work symbiflow. As you know, currently, symbiflow makes use of some wrapper scripts, that just wrap around the various tools to be used as well as some other scripts in between to generate the constraints necessary for, e.g., IO placement or other constrained cell placement.

The question would be whether it makes sense to avoid using the wrappers in Edalize, and just call the tools directly. This would mean to add support for VPR and maybe enhance support for yosys (if required) to run similarly as it does in the wrapper.

Probably this would be the way to go, as it better fits the current API where there is a clear and separate concept of tools and flows, whereas the usage of those wrappers kind of merges the two together.

Before proceeding it might good to establish:

• separate place and route for VPR in its different pack, place, route and genfasm stages.
• whether it is possible to call some python script in between place and route steps, to solve the placement constraints generation.
• how to pass the required device files (e.g. RR graph, architecture definition). These files may just end up being incorporated in the tool_options without requiring Edalize having knowledge on what they are. For instance, at the edam generation we can pass sth like --read_rr_graph <path> and that would be it.

[mithro]

@acomodi Replacing the current wrapper scripts with scripts that use EDALize (and thus EDAlize calls the tools directly) seems like a good approach to me?