... | ... | @@ -85,46 +85,46 @@ necessary modules. There is no need to store them permanently on the |
|
|
local hard disk.
|
|
|
It is of course up to a developer how a project is divided into smaller
|
|
|
parts. All files can be stored in one folder and kept in one repository,
|
|
|
but this seems to be a bit inconvenient. Everyone should use a structure
|
|
|
that he feels comfortable with.
|
|
|
but this has been found to be a bit inconvenient. You should use a
|
|
|
structure that you feels comfortable with.
|
|
|
|
|
|
### Helper script for project-related operations
|
|
|
|
|
|
When your project is properly described with manifest files, then you
|
|
|
can take advantage of written scripts. You can write makefiles for
|
|
|
simulation, do synthesis on other machines over a network. You can fetch
|
|
|
needed modules recursively and automatically and get rid of them
|
|
|
whenever you want.
|
|
|
simulation and do synthesis on other machines over a network. You can
|
|
|
also automatically fetch the needed modules recursively and and get rid
|
|
|
of them whenever you want.
|
|
|
|
|
|
# Basic run scenarios
|
|
|
|
|
|
In order to Hdlmake developer has to put all python files together in
|
|
|
one directory. \\verbhdlmake.py must have execution rights. Next it is
|
|
|
necessary to change current directory to this one that contains a
|
|
|
In order to use Hdlmake developer has to put all python files together
|
|
|
in one directory. \\verbhdlmake.py must have execution rights. Next it
|
|
|
is necessary to change the current directory to this one that contains a
|
|
|
manifest. From there \\verbhdlmake.py must be run with one or more
|
|
|
arguments.
|
|
|
|
|
|
## Makefile preparation (option -k)
|
|
|
|
|
|
Makefile preparation is one of the most basic features that Hdlmake can
|
|
|
be used for. It relieves a developer of creating makefiles by hand. When
|
|
|
compiling VHDL files for simulation, one must ensure their correct
|
|
|
order. In every project there are more or less complicated dependencies
|
|
|
between all project files, that can be expressed in a form of dependency
|
|
|
tree - one file makes use of data from an other file by e.g. including
|
|
|
it. Each file may not be compiled until all files it is dependent on are
|
|
|
compiled, otherwise the compilation process will fail.
|
|
|
|
|
|
In order to use it, Hdlmake must be run from the directory containing a
|
|
|
be used for. It relieves a developer of creating makefiles by hand.
|
|
|
When compiling VHDL files for simulation, one must ensure their correct
|
|
|
order. In every project there dependecies between all project files,
|
|
|
that can be expressed in a form of dependency tree - one file makes use
|
|
|
of data from an other file (by e.g. including it). A file may not be
|
|
|
compiled until all files it is dependent on are compiled, otherwise the
|
|
|
compilation process will fail.
|
|
|
|
|
|
In order to use Hdlmake, it must be run from the directory containing a
|
|
|
manifest. It is assumed that all needed modules were previously fetched.
|
|
|
When run, Hdlmake starts with reading the top module and recursively
|
|
|
collecting modules that are parts of the current design. You can specify
|
|
|
modules that are stored locally, in a git or in a SVN repository.
|
|
|
modules that are stored locally, in a git or an SVN repository.
|
|
|
|
|
|
When the list of used modules is ready, Hdlmake checks if any of those
|
|
|
modules has in its manifest a list of files, that should be used in the
|
|
|
modules has in its manifest a list of files that should be used in the
|
|
|
testbench. If not, all of the module's files are added to the list of
|
|
|
files. In the next step, Hdlmake scans all of the listed files and tries
|
|
|
files. In the next step, hdlmake scans all of the listed files and tries
|
|
|
to figure out dependencies between them by analyzing each file's
|
|
|
content. They are next written down as a makefile in the testbench's
|
|
|
directory.
|
... | ... | @@ -133,42 +133,42 @@ directory. |
|
|
|
|
|
Hdlmake offers a short way of describing project structures. It is
|
|
|
assumed that a projects can consist of modules, that are stored in
|
|
|
different places (locally or a repo). The same thing is about each of
|
|
|
those modules - they can be based on other modules. Hdlmake can fetch
|
|
|
all of them and store them in specified places. For each module one can
|
|
|
specify a target catalog with manifest variable \\verbfetcho. Its value
|
|
|
must be a name (existent or not) of a folder. The folder may be located
|
|
|
anywhere in the file system. It must be then a relative path (Hdlmake
|
|
|
support solely relative paths).
|
|
|
different places (locally or in a repository). Each of these modules can
|
|
|
be based on other modules.
|
|
|
Hdlmake can fetch all of them and store them in specified places.
|
|
|
For each module one can specify a target catalog with manifest variable
|
|
|
`fetchto`. Its value must be a name (existing or not) of a folder. The
|
|
|
folder may be located anywhere in the filesystem. It must be though a
|
|
|
relative path (Hdlmake supports only relative paths).
|
|
|
|
|
|
## Synthesizing projects remotely (option -r)
|
|
|
|
|
|
Another valuable feature of Hdlmake is the ability to perform VHDL
|
|
|
synthesis on a remote machine instead of running it on your desktop.
|
|
|
Both Altera's qsh and Xilinx' ISE-command-line-tools are supported. In
|
|
|
Both Altera's qsh and Xilinx' ISE-command-line-tools are suppored. In
|
|
|
comparison with local synthesis, remote synthesis has several
|
|
|
advantages:
|
|
|
adventages:
|
|
|
|
|
|
- Developer can run synthesis on a fast machine, instead oh his slow
|
|
|
- Developer can run synthesis on a fast machine, instead on his slow
|
|
|
machine
|
|
|
- Developer is not forced to install new software in case when his
|
|
|
computer is not equipped with particular version of software
|
|
|
- Synthesis is a resource-consuming process. When someone runes it on
|
|
|
a remote machine, his own computer remains usable
|
|
|
- Common synthesis server allows to unify synthesis projects. Usually,
|
|
|
when developing a project in a team, all team members have different
|
|
|
version of software tools. These tools are complex and their
|
|
|
versions are not always fully compatible with each other. When
|
|
|
- Developer is not forced to install new software in case his computer
|
|
|
is not equipped with a particular version of the software
|
|
|
- Synthesis is a resource-consuming process. When someone runs it on a
|
|
|
remote machine, the development machine remains usable
|
|
|
- A common synthesis server allows to unify synthesis projects.
|
|
|
Usually, when developing a project in a team, all team members have
|
|
|
different version of software tools. These tools are complex and
|
|
|
their versions are not always fully compatible with each other. When
|
|
|
collaborating developers share the same machine for synthesis they
|
|
|
can always be sure that the synthesis will run correctly.
|
|
|
|
|
|
In order to make command-line synthesis possible, for both Altera and
|
|
|
Xilinx a project for vendor's IDE must be created - this is Quartus and
|
|
|
ISE respectively. For Xilinx a .tcl file must exist in addition. This
|
|
|
file can be generated when selecting \`\`Project'' and then \`\`Generate
|
|
|
.tcl s
|
|
|
Xilinx a project for the vendor's IDE must be created - this is Quartus
|
|
|
and ISE respectively. For Xilinx a .tcl file must exist in addition.
|
|
|
This file can be generated when selecting \`\`Project'' and then
|
|
|
\`\`Generate .tcl script''.
|
|
|
Synthesis server and username for logging in on the synthesis server can
|
|
|
be specified with run parameters:`--synth-server` and `--synth-user`
|
|
|
be specified with run the parameters:`--synth-server` and `--synth-user`
|
|
|
accordingly.
|
|
|
|
|
|
## Synthesizing projects locally (option -l)
|
... | ... | @@ -180,9 +180,9 @@ purpose server and username are not necessary. |
|
|
|
|
|
## Verbose mode (option -v)
|
|
|
|
|
|
For debugging purpose and having more control over what is happening you
|
|
|
can run Hdlmake in verbose mode. In this mode most of the intermediate
|
|
|
data structures are printed
|
|
|
For debugging purpose and having a more detailed view over what the
|
|
|
program is doing you can run Hdlmake in verbose mode. In this mode most
|
|
|
of the intermediate data structures are printed
|
|
|
|
|
|
# Manifest variables description
|
|
|
|
... | ... | |