... | ... | @@ -4,41 +4,41 @@ |
|
|
|
|
|
Maintaining VHDL projects either for Altera or for Xilinx 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.
|
|
|
no tool for dependency generation. The developer has to manually
|
|
|
generate the dependencies between files and modules, as well as
|
|
|
compilation order. 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
|
|
|
to introduce petty modifications to the hardware. Apart from that much
|
|
|
of system resources like memory or CPU time are consumed and synthesis
|
|
|
makes running other application harder. The solution for this problem is
|
|
|
to set up a dedicated server for synthesis purpose only. This allows to
|
|
|
delegate this demanding task to a fast machine, while the developer's
|
|
|
computer remains still useful.
|
|
|
to introduce trivial modifications to the hardware. Apart from this,
|
|
|
much of the system resources like memory or CPU time are consumed and
|
|
|
synthesis makes running other application harder. The solution for this
|
|
|
problem is to set up a dedicated server solely for the purpose of
|
|
|
synthesis. This allows to delegate this demanding task to a fast
|
|
|
machine, while the developer's 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.
|
|
|
to make the VHDL coder's life easier. Nevertheless, its principal goal
|
|
|
is to 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 unexpected 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.
|
|
|
were some issues with compatibility in Python 3.1 but they have been
|
|
|
resolved. The best efforts have been made to ensure compatibility
|
|
|
between versions but there is no guarantee of correct behavior in the
|
|
|
newest versions of Python.
|
|
|
|
|
|
## 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 the 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 at the
|
|
|
moment).
|
|
|
|
|
|
For the most options Python is the only thing that you need to make it
|
|
|
work.
|
|
|
For most of the options, Python is the only thing that is required to
|
|
|
make it work.
|
|
|
In order to perform remote synthesis you should equip your system with a
|
|
|
ssh client and rsync.
|
|
|
|
... | ... | @@ -52,8 +52,8 @@ and top modules. The major goal of the manifests is to describe the |
|
|
structure of the project:
|
|
|
|
|
|
- what is the module's ancestor (if needed),
|
|
|
- for parent modules, what modules it is made of, where to take them
|
|
|
from, where to store them locally,
|
|
|
- for parent modules; what modules it is made of? where to take them
|
|
|
from? where to store them locally?
|
|
|
- what are the local files, that should be used in synthesis or
|
|
|
simulation,
|
|
|
- what is the target library for a module (in a VHDL sense),
|
... | ... | @@ -61,29 +61,28 @@ structure of the project: |
|
|
- which ISE version should be used,
|
|
|
- which qsh (Quartus Shell) version should be used, etc.
|
|
|
|
|
|
Whenever you want to run Hdlmake for any reason, you should have
|
|
|
prepared manifest.py file containing all needed variables. Description
|
|
|
of available variables you can find in a section below. For a quick help
|
|
|
you can also use built-in user help.
|
|
|
Whenever you want to run Hdlmake for any reason, you should prepare a
|
|
|
manifest.py file containing all the needed variables. Description of
|
|
|
available variables can be found in section \\ref{subsec:vars}. For a
|
|
|
quick overview you can also use the built-in user help.
|
|
|
Hdlmake makes use also of run arguments. In general, their purpose is to
|
|
|
indicate the action that should be taken by the script. Some of them are
|
|
|
also used for specifying additional parameter that are not enclosed in
|
|
|
manifests. All supported actions are listed in an appropriate section
|
|
|
below
|
|
|
also used for specifying additional parameters that are not enclosed in
|
|
|
manifests. All supported actions are listed in an appropriate section.
|
|
|
|
|
|
# Features
|
|
|
|
|
|
Hdlmake consists of two major ingredients which are described below.
|
|
|
Hdlmake consists of two major components which are described below.
|
|
|
|
|
|
### File-based project description
|
|
|
|
|
|
Hdlmake defines a way to describe projects that consist of smaller
|
|
|
modules. Usually developers kept these modules together, although each
|
|
|
of them \`\`deserved'' an own repository. When some of these modules are
|
|
|
reused accross several projects, then there can appear a mess. Hdlmake
|
|
|
offers easy and convenient way to specify where to find necessary
|
|
|
modules. There is no need to store them permanently on the local hard
|
|
|
disk.
|
|
|
modules. Many times developers keep these modules together in a single
|
|
|
repository, even though it is cleaner to store them separately. When
|
|
|
some of these modules are reused across several projects, it can cause a
|
|
|
mess. Hdlmake offers easy and convenient way to specify where to find
|
|
|
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
|
... | ... | |