|
|
# Introduction
|
|
|
h3. Rationale
|
|
|
Maintaining VHDL projects either for Altera or for Xilins is a source of many problems. When using Modelsim for simulating VHDL designs there is no tool for dependencies generation. The developer has to think up the dependencies between files and modules, as well as compilation order, on his own. This is laborious and consumes developer's time.
|
|
|
|
|
|
## Rationale
|
|
|
|
|
|
Maintaining VHDL projects either for Altera or for Xilins is a source of
|
|
|
many problems. When using Modelsim for simulating VHDL designs there is
|
|
|
no tool for dependencies generation. The developer has to think up the
|
|
|
dependencies between files and modules, as well as compilation order, on
|
|
|
his own. This is laborious and consumes developer's time.
|
|
|
|
|
|
Synthesis of large projects is a time and resource-consuming process. It
|
|
|
makes the edit-compile-test cycle unreasonably long and makes it harder
|
... | ... | @@ -13,20 +19,29 @@ computer remains still useful. |
|
|
|
|
|
The aim of the project is to offer multiple functionalities whose aim is
|
|
|
to make VHDL coder's life easier. Nevertheless, its principal goal is to
|
|
|
provide means for performing simulation and synthesis for VHDL
|
|
|
projects.
|
|
|
provide means for performing simulation and synthesis for VHDL projects.
|
|
|
|
|
|
## Python
|
|
|
|
|
|
The script is written in Python and is checked under Python 2.7. There
|
|
|
have been some issues with compatibility in Python 3.1 but they have
|
|
|
been resolved. Nevertheless, there can occur some unexptected problems
|
|
|
following that the Python maintainer don't hesitate to remove functions
|
|
|
or change calling syntax. I did my best to ensure compatibility but
|
|
|
there is no guarantee for proper working in the newest versions of
|
|
|
Python.
|
|
|
|
|
|
### Python
|
|
|
The script is written in Python and is checked under Python 2.7. There have been some issues with compatibility in Python 3.1 but they have been resolved. Nevertheless, there can occur some unexptected problems following that the Python maintainer don't hesitate to remove functions or change calling syntax. I did my best to ensure compatibility but there is no guarantee for proper working in the newest versions of Python.
|
|
|
## Required environment
|
|
|
|
|
|
### Required environment
|
|
|
Hdlmake is basically written for use in Linux environment. It was tested and developed under Ubuntu 10.04. For the time being there are no perspectives for moving to Windows (there is also no need, by the way).
|
|
|
Hdlmake is basically written for use in Linux environment. It was tested
|
|
|
and developed under Ubuntu 10.04. For the time being there are no
|
|
|
perspectives for moving to Windows (there is also no need, by the way).
|
|
|
|
|
|
For the most options Python is the only thing that you need to make it
|
|
|
work.
|
|
|
In order to perform remote synthesis you should equip your system with a
|
|
|
ssh client and rsync.
|
|
|
h3. Way of use
|
|
|
h2. Way of use
|
|
|
The basis for Hdlmake are configuration files called \`\`manifests''.
|
|
|
Those files have form of Python scripts and therefore must obey its
|
|
|
syntax. They should also have Python exstension (.py). As Hdlmake
|
... | ... | @@ -54,8 +69,10 @@ also used for specifing additional parameteter that are not enclosed in |
|
|
manifests. All supported actions are listed in an appropriate section
|
|
|
below
|
|
|
h1. Features
|
|
|
|
|
|
Hdlmake consists of two major ingredients which are described below.
|
|
|
h5. File-based project description
|
|
|
h3. File-based project description
|
|
|
|
|
|
Hdlmake defines a way to describe projects that consist of smaller
|
|
|
modules. Usually developers kept these modules together, altough each of
|
|
|
them \`\`deserved'' an own repository. When some of these modules are
|
... | ... | @@ -66,16 +83,33 @@ 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.
|
|
|
that he feels comfortable with.
|
|
|
|
|
|
### Helper script for project-related operations
|
|
|
|
|
|
##### 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.
|
|
|
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.
|
|
|
h1. 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 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 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
|
|
|
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
|
|
|
manifest. It is assumed that all needed modules were previously fetched.
|
... | ... | @@ -91,11 +125,25 @@ to figure out dependencies between them by analizing each file's |
|
|
content. They are next written down as a makefile in the testbench's
|
|
|
directory.
|
|
|
|
|
|
### Fetching submodules for a top module (option -f)
|
|
|
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).
|
|
|
## Fetching submodules for a top module (option -f)
|
|
|
|
|
|
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).
|
|
|
|
|
|
## Synthesizing projects remotely (option -r)
|
|
|
|
|
|
### 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 comparison with local synthesis, remote synthesis has several advantages:
|
|
|
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
|
|
|
comparison with local synthesis, remote synthesis has several
|
|
|
advantages:
|
|
|
|
|
|
- Developer can run synthesis on a fast machine, instead oh his slow
|
|
|
machine
|
... | ... | @@ -119,10 +167,16 @@ Synthesis server and username for logging in on the synthesis server can |
|
|
be specified with run parameters:`--synth-server` and `--synth-user`
|
|
|
accordingly.
|
|
|
|
|
|
### Synthesizing projects locally (option -l)
|
|
|
It is also possible to perform synthesis on the local machine. For this purpose server and username are not necessary.
|
|
|
## Synthesizing projects locally (option -l)
|
|
|
|
|
|
It is also possible to perform synthesis on the local machine. For this
|
|
|
purpose server and username are not necessary.
|
|
|
h1. Additional features
|
|
|
h3. Injecting files list into an ISE project file
|
|
|
|
|
|
## Injecting files list into an ISE project file
|
|
|
|
|
|
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 more control over what is happening you
|
|
|
can run Hdlmake in verbose mode. In this mode most of the intermediate
|
|
|
data structures are printed
|
|
|
|