Command syntax and run arguments name/behavior have changed from
ISYP/v1.0 to current Master, but the documentation it's not very clear
about this issue.
The most of the documentation is intended for the older versions, and
only this link covers how to migrate an older design/script to the
current Master Masterforisypusers.
"doc" folder in sources
It includes two pdf files that are not valid for current master as they
are ISYP related.
hdlmake_manual.pdf: this is old, points to ISYP information. It
only mentions VHDL supported, while some of the current hdlmake
actions support Verilog, VHDL and even some other HDL languages such
as System Verilog.
hdlmake_quick_start.pdf: this is old, related with ISYP.
The source file in La(tex) format.
hdlmake.tex: this is supposed to be the actual user document
specific for current Master code, but it seems to be targeted to
ISYP again and only points to VHDL support.
The ISYP and current Masted related info is mixed across the wiki.
Run-arguments-summary: the argument syntax
is from ISYP, but the argument set doesn't match with the actual
Separation between older releases stuff and current master.
Compile all the stuff related with ISYP/v1.0 and set a clear wiki
section for this stuff.
Write a new user document in both wiki and texinfo.
Complete feature list and related parameters/arguments/options.
Full set of example tutorials covering the most important
Developer doc*: Include python comments and a Python generation
(tested with "epydoc").
There is only a single test in the Master source code (Xilinx ISIM
Learn by example*: use the same design samples for both
documentation/tutorial and regression testing (this is one of the
features to be done). The core features we want to test are those the
users would like to use.
I've deployed a test setup environment in order to evaluate/test the
current Master status and coverage.
Some of the test I'm working in are already uploaded to the hdlmake
Ubuntu 14.04 LTS
Python 2.7 (Python 3.3/3.4 doesn't work)
Tested on the next architectures.
armhf: Remote synthesis runs OK, but needs a local install for
generating an ISE project
Develop a list of features that are going to be validate/documented
Include a simple test/demo example for every feature we want to
In adition to general purpose code managing capabilities, there are
different tool specific actions:
In order to use synthesis, it's mandatory to use proprietary tools.
Xilinx ISE is the only supported tool for synthesis -- Altera Quartus
synthesis not supported.
NOTE:* GSI uses hdlmake current Master for building Altera projects,
and then launch the synthesis by executing a Quartus shell custom script
(see github repo).
Need a local ISE install in order to build a local xise
Asks for user password multiple times halting the automated flow.
(I've not tested screen support, just default mode)
Handling Higher Level Hardware Descriptions
Higher level abstraction are not well managed by ISE.
Embedded cores (xps) -> Zynq, Dual core.
IP (xco) -> Issue already requested #938.
Optimized for tcl: concurrent runs, work batches...
Add support for Makefile generation handling local/remote Quartus
Add remote project generation for both Quartus and ISE.
Add PlanAhead support for handling Xilinx coregen/DSP/embedded-CPU
Each simulation makefile builds a run project / workspace and then
*: some GHDL support work was made in a separate branch. This is not
included in master and follows an older software design (2 years old).
Add a set of common unified simulation flow commands and output for
the different (e.g. run for X time and dumps the signals to a vcd
Support for custom simulation scripts.
Merge and fix GHDL support. This is the only "Free/Libre" real
alternative for VHDL simulation.
Allow for remote simulation. Simulation is an ideal remote feature
because of the same reasons Synthesis is.
Device Family Support
In order to generate an ISE or a Quartus project, the device family is
required. In the current master, the family support is very limited.
The way in wich xise calculates the family requires a constant database
update as new device families are introduced in the market (e.g. Zynq
Some naming schemes are not supported in the current automatic
calculation (e.g. Spartan3E, Spartan3AN...). A more complex mechanism is
required in order to manage some devices. Even worse, if new naming
schemes are introduced in the future, the algorithm will need to be
Arria II GX
Add family as an optional Manifest parameter, in this way we are not
limiting the use of new devices.
If not family option value is provided in the Manifest, hdlmake will
try to get the family name from the device parameter.
Upgrade the automatic family calculation algorithm and database.
Add to the documentation an entry with how to get the valid device,
speed-grade, package and family parameters from datasheet or device
Better HDLMAKE_COREDIR handling
Screen support for remote synthesis.
Fetch modules to a single directory, whatever the structure of the project is.
Fix all OHWR issues
Add finer control for synthesis stages
Arrange a separate repository with test projects
Add support for Windows OS
No binary in repo
Some of the issues marked as solved are not applied in master -- may
they be on a branch?.
The following are a couple of examples I've already fixed in 2014
e.g. Binary configuration file generation #637
e.g. Hierachy Separator property. This was reported to the mailing list
but a issue was not filled. Current status is not solved.