... | @@ -28,6 +28,8 @@ As a proof of concept of a tool that could be used in Linux and Windows environm |
... | @@ -28,6 +28,8 @@ As a proof of concept of a tool that could be used in Linux and Windows environm |
|
|
|
|
|
### Modules export tool
|
|
### Modules export tool
|
|
|
|
|
|
|
|
This comment is taken from #18:
|
|
|
|
|
|
- @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
|
|
- @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.
|
|
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.
|
|
|
|
|
... | @@ -40,6 +42,29 @@ rough and generate false positive (ie add unneeded modules). It could be |
... | @@ -40,6 +42,29 @@ rough and generate false positive (ie add unneeded modules). It could be |
|
possible to reuse existing parser from existing OSS tools, but they are
|
|
possible to reuse existing parser from existing OSS tools, but they are
|
|
often not written in Python.
|
|
often not written in Python.
|
|
|
|
|
|
|
|
## Automated design packaging
|
|
|
|
|
|
|
|
This feature was requested here #68 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,
|
|
|
|
<projectname>*date\>*<tagname>.tar.gz
|
|
|
|
|
|
|
|
For the source: It would be similar but it should not put the binary
|
|
|
|
files into the package.
|
|
|
|
|
|
## Add support for toolchains
|
|
## Add support for toolchains
|
|
|
|
|
|
In random order:
|
|
In random order:
|
... | | ... | |