Hdlmake can reason the correct flow from the manifest options. There is no longer need to run it with parameters such as --make-synth, --make-sim, --make-vsim. The desired tool is specified in the manifest as it is related to the code and cannot be changed freely by the code user. The tool is specified with sim_tool or syn_tool in the manifest. Automatic flow is run with python hdlmake or python hdlmake auto
Hdlmake is able to check and report values of Hdlmake-related environmental variables (i.e. HDLMAKE_*). It can check also presence and version of supported tools. To use this feature, run python hdlmake check-env
Print debugging log
Hdlmake can print detailed execution-related information, as well as debugging-oriented trace. Probably this is not a first-class feature, but can greatly improve debugging or :-) Can be run with python hdlmake --log=, where level is one of: debug, info, warning, error, critical. By default info level is set.
Specify tool version
There is a new manifest variable - force_tool - which is used to include in the output Makefile the requirements concerning the version of simulation or synthesis tools. As for now, it can only support ISE. Some logic (e.g.: >, ) is embedded, so this value can be kind-of/slightly interpreted. To set ISE as synthesis tool put syn_tool = "ise", to enforce a certain ISE version (using this option), put force_tool = "ise > 13.1" or "ise 12.0" etc. NOTE: there is some clash with syn_ise_version. I have to clarify that (Pawel)
Pre- and post- -synthesis and -simulation commands
Hdlmake can add execution of specified commands before and after synthesis or simulation. This is done by using syn_pre_cmd, syn_post_cmd, sim_pre_cmd or sim_post_cmd in the main manifest. This option can be useful when someone uses scripts for sources preprocessing.
Action manifest variable
Action is a variable that implies the flow that is executed by Hdlmake. It takes two values by now: 'synthesis' or 'simulation'
top_module manifest variable
top_module is a new manifest variable that specifies name of the top level entity (VHDL) or module (verilog). It is needed in simulation, synthesis, remote synthesis and ISE project generation flows.
If this variable is set, all hdlmake submodules will be set to this location, instead of being fetched to each module's default fetchto location.
Subcommands and options
Hdlmake CLI is very similar to the one offered by git. When running hdlmake one has to give a subcommand and possibly some options. Subcommands are never prefixed with -- (e.g. fetch, clean), whereas options are always prefixed with --. Help for each subcommand can be obtained with python hdlmake --help.
Full dependency parser
Hdlmake crawls through the set of all the source files listed in manifests. It parses the dependencies and builds a dependency tree. Thanks to this it can see (a) what are the dependencies and (b) which files are not necessary at all. It can then purge unneeded files from the result makefile. To avoid this, use --noprune. Pruning is currently used only with ISE project files, although there are no technical reasons not to introduce it into other flows.
Merge cores enhancement
merge-cores is a subcommand that can produce a single HDL file from the whole project. The result file contains content of the involved files, as well as (as comments) name of of each file, revision and date of the last modification.
Global variable scope
All variables from the top manifest are always available in the children manifests, excluding those that are redefined in children modules or are module-specific (e.g. files, modules, include_dirs etc.). Path to the current module is passed as __manifest. For instance, in a child manifest it can be checked what is the value of syn_tool or top_module in the top manifest.
list-mods and list-files
These are the subcommands that list modules (including git submodules) and files accordingly. The former can print files as well when run with --with-files
local and remote synthesis included in the same makefile
Makefiles for synthesis include now targets for remote and local synthesis (targets "local" and "remote"). No separate makefiles are produced
git submodules support
Hdlmake implements now support for git submodules. They are treated in the same way as manifest modules. Hdlmake can recognize submodules added in .gitmodules or by running git submodule add. This means that building up the module tree that a project consists of is possible either by using manifest modules ("modules" variable in the manifest) or by using git submodules. If a git sumbodule is not fetched, running python hdlmake fetch will fetch missing hdlmake-modules and git-submodules recursively. Both kind of modules are listed when running python hdlmake list-mods.
By default Hdlmake will refuse to generate a makefile if it fails to detect local installation of the chosen tool. This might be bypassed by running python hdlmake auto --force. It will then generate a makefile, but it's correctness remains uncertain. For instance, hdlmake won't be able to detect the libraries installed in Modelsim, if its path is not specified.
By default, when running "hdlmake fetch", only the missing modules are cloned or pulled (in git terminology). Using "--update" flag will change the default behavior and fetch subcommand will try to pull the latest revisions. Beware, this can lead to merging remote changes with local changes. On the other hand, if there are no local changes, it allows to keep local copies up to date.