f4pga CLI: Bugs and Improvements
kboronski-ant opened this issue · comments
This issue accumulates various ideas for improvements related to f4pga (CLI tool) that was recently merged (#530).
Please refer to https://f4pga.readthedocs.io/en/latest/f4pga/Usage.html and related pages for documentation of this new tool.
Bugs
Relative paths
@umarcor has reported to me that he had an issue with some dependency failing to resolve despite being present inside of project's directory when using f4pga [with pwd] outside of that directory. Looks like some paths do are not converted to absolute path when processing inputs for stages.
UX improvements
Add missing metadata for module targets
Modules have optional fields for metadata that provides a helpful description of targets. Some targets are missing their descriptions.
Make target metadata independent from modules
Currently modules provide metadata for their outputs, but this means that there's no way to provide metadata for targets that can serve only as inputs. Target descriptions should be independent of modules.
Handle all output streams from running tools
Currently f4pga modules can print only stdout of tools being used. We may want to extend that to all streams to provide better feedback.
Better flow definitions
Currently the flow definitions aren't the prettiest. First of all there's a lot of overlap between similar platforms. It would be nice to make some code re-usable. For example allow importing stage definitions from an external file.
Another thing is the fact that declarations of stages are in a different place than stage options. This makes adding/modifying stages confusing, because there's no indication about the module being configured next to stage options, which are module-specific. An example for improvement that I propose would be to get rid of stages field, rename stage_options to stages and add an extra module field that points to the module to use for that stage.
Rework CLI dependency/value expressions
The current format has two issues: First - it doesn't allow passing nested structures. So far there's no need to do that anyway, but if a user attempts to pass a nested structure to CLI, they will get a very unclear error message. The second problem is that the current format makes it painful to pass lists generated in make or bash. Perhaps there's a room for improvement.
Native support for target renaming within flow definition
io_rename module is an ugly hack. That's it.
New features
Add analysis targets
The old wrappers support analysis flows, whereas f4pga does not.
This might require creating an additional module and adding an analysis targets to flow definitions.
Pretend an unresolved dependency is resolved
While resolving dependencies it would be very useful to temporarily trick the algorithm into thinking that an unresolved dependency is actually resolved. This would allow collecting information on which of the dependencies have to be provided by the user and which can be generated when building the target.
Distinguish user-provided targets from generated ones in explicit declarations
Targets (aka dependencies) can have their paths specified by using a dependencies entry in flow configuration file or -D flag in CLI interface. This however does not distinguish between dependencies that have to be provided by the user and ones that can be generated. Specifying a path to non-existent dependency will not cause a failure if this dependency can be generated and saved in the provided path. This however could easily become a misleading behavior and a user should have an option to require using a dependency provided by them or fail otherwise.
Use f4pga to download architecture definitions as dependencies
Instead of downloading architecture definitions manually, we could use an f4pga module to do that and declare an architecture definition as a dependency in a flow.
Modules for other PnR tools
Currently we have a module for VPR. Some flows use nextpnr tho, if we want to support these flows we will need a module for nextpnr too.
Activate/deactivate stages
An option to mark a stage as active/inactive in flow could be useful if we wanted to choose between different tools that could generate same targets (eg. VPR/nextpnr). Currently only VPR is supported, so this is not very important now.
I've been trying to get this tool running on a simple Verilog project I got working through an Edalize/F4PGA makefile. I keep getting this error Constrained pad W5 is not in available pad map: followed by a huge list that doesn't include W5. Any ideas about what's going on or how to start debugging this?
Edit: Moved to #557
@Pocketkid2 can you please open a new issue and paste the error report there? Let's keep this issue as an index/reference.
I'm closing this issue as there's no activity and we will prioritize changes that remove complexity from the existing solution over changes that add new features, yet this issue contains mostly various ideas for improvement. I expect many of them to be eventually taken into consideration, once there's more time to deal with them.
The bugy path handling got its own issue.