Ideas for evolution
Installation on Windows
Windows users find installation tedious: they need a windows distribution of Python, they need a command line console...
- Provide a single binary (single .exe file)
- Or provide an installer
NOTE: hdlmake is now available in PyPI.
Better integration (Windows)
- HDLmake can call the tools directly instead of generating a Makefile. Usually you need to call HDLmake, then make and then you can work directly on the result (synthesis or simulation). You need to call HDLmake again only when you modify the Manifest.py files. If HDLmake were executing the tools directly, that would simplify the life of Windows users.
Simple GUI
Several hdlmake users, mostly working in Windows environments, have asked for a simple GUI interface.
Web based GUI proof of concept
As a proof of concept of a tool that could be used in Linux and Windows environments, the hdlmaker makes use of web technologies such as Node.js to provide a user friendly graphical wrapper for hdlmake that can be handled from any web browser. This is a demo video showing the hdlmaker handling the building of a non-trivial ISE design and graphically exploring its hierarchy.
Modules export tool
This comment is taken from #18 (closed):
-
@greg.d : To make our IP cores easier accessible to non-Linux, non-git users we could imagine having a generation tool with simple GUI. This tool could provide a list of modules (generated by hdlmake from our repositories like wr-cores, general-cores) where a user could click&check the modules he/she wants to use in the design. The tool then would copy all necessary files from our repositories to a separate folder that the user could include in his design. In case some extra modules are needed, the same tool could be used to re-export the content of the included directory with these new ip-cores. The tool should take into account dependencies based on Manifests and e.g. include appropriate modules from general-cores that are needed for selected modules from wr-cores repository.
-
@lipinskimm : the tool could also allow import of user's changes to the original repo
Improve HDL parsers
The parsers written in HDLmake to compute the dependencies are very rough and generate false positive (ie add unneeded modules). It could be possible to reuse existing parser from existing OSS tools, but they are often not written in Python.
Improve SDB integration and workflow
Look for a way to handle SDB without having to use two commits/steps in the HDLMake + SDB (Self Describing Bus)
Automated design packaging
This feature was requested here #68 (closed) by @benoit long time ago and could be considered for further discussion.
It would be nice to have an option to create a package in order to ease human error in the release process:
hdlmake --pack-src
hdlmake --pack-bin
- Print information about the software used to generate the binaries (hdlmake, python, ISE)
- Print information about which commit has been used to generate the binaries
- Possibility to add the generated doc (pdf) into the package. This could be done by letting the user include its own code into the auto generated Makefile (Makefile_hdlmake.inc)
- Name the package according to a standard nomenclature. i.e, date>.tar.gz
For the source: It would be similar but it should not put the binary files into the package.
Add support for toolchains
These are the currently supported toolchains. Note that Intel/Altera Quartus, Xilinx ISE and Xilinx Vivado are the best supported and tested ones, but Lattice and Microsemi ones should be working OK too.
Missing tools that had been requested:
- Synopsys' Synplify: the support for this tool was requested by users from NASA's Jet Propulsion Lab and reported in #30 (closed).
Enforced compilation
Feature suggested by @adrianf0 at feature request #43 (closed).
Possibility to enforce compilation of certain additional files at the
end, respecting order.
Case: A single netlist file generated by Cadence contains some empty
modules. Their functional description is in separate, RTL files.
Because/thanks to solver, I don't see possibility to enforce compilation
of those additional files at the end, so empty modules in a work
library, a overwritten by the specific one.