@@ -182,7 +182,7 @@ Despite the fact that ``hdlmake`` was originally designed to be used in Linux en
First, install a valid Cygwin environment for your Windows machine. I order to access to the full set of features from ``hdlmake``, you must choose at least the following packages when deploying Cygwin:
- python (choose the most updated 2.7 release)
- python (choose the most up-to-date 2.7 release)
- openssh
- git-svn
- git
...
...
@@ -301,6 +301,8 @@ Each of the modules contains a single testbench file written in the appropriated
While in Verilog the Manifest.py is:
.. code-block:: python
files = [
"counter_tb.v",
]
...
...
@@ -376,7 +378,7 @@ The following common top specific Manifest variables describes the simulation:
- ``action``: indicates that we are going to perform a simulation.
- ``sim_tool``: indicates that modelsim is going to be the simulation we are going to use.
- ``top_module``: indicates the name of the top HDL entity/instance that is going to be simulated.
- ``sim_post_cmd``: indicates a command that can be issued after the simulation process has finnished.
- ``sim_post_cmd``: indicates a command that must be issued after the simulation process has finnished.
Now, if we want to launch the simulation, we must follow the next steps. First, get into the folder containing the top Manifest.py we want to execute and run ``hdlmake`` without arguments. e.g. for VHDL:
...
...
@@ -392,11 +394,11 @@ This generates a simulation Makefile that can be executed by issuing the well kn
user@host:~$ make
user@host:~$ vsim -do ../vsim.do -i counter_tb
But, because we have already defined a post simulation command into the Manifest.py, the generated Makefile allows us to combine the compilation and the test run in a single command:
But, because we have already defined a post simulation command into the Manifest.py, the generated Makefile allows us to combine the compilation and the test run in a single command. In this way, the second command is not required:
.. code-block:: bash
user@host:~$ make sim_post_cmd
user@host:~$ make
If everything goes well, a graphical viewer should appear showing the simulated waveform. Note that every simulation top Manifest.py in the ``sim`` folder includes a tool specific ``sim_post_command``, so all the simulations in this example can be generated by using the same simple command sequence that has been exposed here.
...
...
@@ -471,6 +473,8 @@ Note that we have a different tool associated to each of the different supported
If we focus on the ``spec_v4_ise`` test case, we can see the following contents in the associated folder:
.. code-block:: bash
user@host:~$ tree -d -L 1 counter/syn/spec_v4_ise
counter/syn/spec_v4_ise/
|-- verilog
...
...
@@ -618,13 +622,268 @@ This will tell Hdlmake to fetch modules to the project catalog. Let's see how it
And we finally get the original project we started with.
Pre and Post synthesis / simulation commands
--------------------------------------------
As we have already seen in the simulation example, ``hdlmake`` allows for the injection of optional external shell commands that
are executed just before and/or just after the selected action has been executed. By using this feature, we can automate other custom tasks
in addition to the ``hdlmake`` specific ones.
If a external command has been defined in the top Manifest, this is automatically written by ``hdlmake`` into the generated Makefile.
In this way, the external commands are automatically executed in order when a ``make`` command is issued.
**Synthesis:**
In order to add external commands to a synthesis top makefile, the following parameters must be introduced:
But we can also define the variable value by injecting custom Python code from the command line
when ``hdlmake`` is executed:
.. code-block:: bash
hdlmake --py "simulate_vhdl = False" auto
.. note:: New custom variables are not allowed outside the TOP Manifest.py. In this way, despite the fact that all of the Pyhton code in the used Manifest.py files is executed when ``hdlmake`` is launched, not all of the Python constructions can be implemented.
.. note:: In order to allow the insertion of new custom variables in the child Manifests, you can try the ``--allow-unknown`` experimental feature. By specifiying this optional argument to the ``hdlmake`` command line, a warning message is raised when an unknown option or variable is defined in a child Manifest.py, but the variable itself is inserted and processed.
Remote synthesis with Xilinx ISE
--------------------------------
When using ISE synthesis, ``hdlmake`` allows for the implementation of a centralized synthesis machine.
For this purpose, when running ``hdlmake`` an extra remote synthesis target is created in the Makefile so that
the actual resource intensive synthesis process is executed in a remote machine instead of in the local one.
In order to do that, when a remote synthesis is performed the local machine connects to the synthesis server through
a secure TCP/IP connection by using SSL. For this purpose, the following tools need to be installed:
Note that, for both local and remote Xilinx ISE synthesis, the synthesis process in the Makefile generated by ``hdlmake``
performs the complete process by running a step-by-step approach that goes from synthesis to bitstream generation
instead of executing a single "build_all" command. Going through this step-by-step path, the synthesis process
scans for already performed ISE steps, so that only the pending ones are actually executed
(this information is stored in the associated .gise file).
The different Xilinx ISE steps that are performed by the synthesis makefile are:
- Synthesize - XST
- Translate
- Map
- Place & Route
- Generate Programming File
The main advantage of this approach is that, when synthesizing complex designs, the process can be resumed if
it fails or is halted and the already performed jobs don't need to be re-launched. The drawback is that a little time
overhead is introduced while scanning for the already completed stuff, and this can be noticed if the design is trivial.
If you want to re-synthesize the whole system from the start without scanning for already performed jobs,
just perform a ``make clean`` or ``make cleanremote`` before executing the ``make`` or ``make remote`` command.
Advanced examples
-----------------
**EVO project**: PlanAhead synthesis project for the Zedboard platform, powered by Xilinx Zynq based ARM Dual Cortex-A9 processor plus Artix grade FPGA and performing an asynchronous logic demo:
http://www.ohwr.org/projects/evo/repository
**UMV, Mentor Questa & System Verilog simulation**: Work in progress, ready to be merged into Main branch.
**UMV, Mentor Questa & System Verilog simulation**: A test example involving these tools and languages is included in the ``hdlmake`` source tree.
You can find it inside the ``tests/questa_uvm_sv`` folder.
Check environment for HDLMAKE-related settings. This scan the top Manifest and report if the potentially used tools or/and environment variables are met or not.
Check environment for HDLMake-related settings. This scan the top Manifest and report if the potentially used tools or/and environment variables are met or not.
This is the default action for hdlmake, the one that is run when a command is not given.
.. note:: The ``auto`` command is just inferred if the issued command is a plain ``hdlmake``. If an optional argument is provided, you need to specify the specific command that is going to be executed.
The basic behaviour will be defined by the value of the ``action`` manifest parameter in the hierachy top ``Manifest.py``. This can be set to ``simulation`` or ``synthesis``, and the associated command sequence will be:
Force hdlmake to generate the makefile, even if the specified tool is missing.
``--allow-unknown``
--------------------------
.. warning:: this is an experimental feature!!
Allow the insertion of new options or variables inside the child Manifest. Is this is option is not specified, the only place in which new options or variables can be defined is the top Manifest.
-- Author : Adrian Fiergolski <Adrian.Fiergolski@cern.ch>
-- Company : CERN
-- Created : 2014-09-26
-- Last update: 2014-09-26
-- Platform :
-- Standard : VHDL'2008
-- File : RTLTopModuleVHDL.vhdl Author : Adrian Fiergolski <Adrian.Fiergolski@cern.ch> Company : CERN Created : 2014-09-26 Last update: 2014-09-26 Platform : Standard : VHDL'2008
-- is free firmware: you can redistribute it and/or modify it under the terms of the GNU General Public License
-- as published by the Free Software Foundation, either version 3 of the License, or any later version.
-- is free firmware: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.
--
-- is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
-- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
-- is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License along with . If not, see http://www.gnu.org/licenses/.
-- File : includeModuleAVHDL.vhdl Author : Adrian Fiergolski <Adrian.Fiergolski@cern.ch> Company : CERN Created : 2014-09-26 Last update: 2014-09-26 Platform : Standard : VHDL'2008
-- is free firmware: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.
--
-- is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License along with . If not, see http://www.gnu.org/licenses/.
-- File : includeModuleBVHDL.vhdl Author : Adrian Fiergolski <Adrian.Fiergolski@cern.ch> Company : CERN Created : 2014-09-26 Last update: 2014-09-26 Platform : Standard : VHDL'2008
-- is free firmware: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.
--
-- is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License along with . If not, see http://www.gnu.org/licenses/.
-- File : includeModuleVHDL.vhdl Author : Adrian Fiergolski <Adrian.Fiergolski@cern.ch> Company : CERN Created : 2014-09-26 Last update: 2014-09-26 Platform : Standard : VHDL'2008
-- is free firmware: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.
--
-- is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License along with . If not, see http://www.gnu.org/licenses/.