2014 Release

THIS DOCUMENT IS AN IN PROGRESS DRAFT!!

Intro

Bring the current master to a similar stage to the ISYP branch.

Docs

Command syntax and run arguments name/behavior have changed from ISYP to current master, but the documentation it's not well

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.

Wiki

The ISYP and current Masted related info is mixed across the wiki.

• Manifest-variables-description: this is from ISYP. Some of the critical variables for current Master are not listed: e.g. syn_tool
• Run-arguments-summary:Run-arguments-summary: the argument syntax is from ISYP, but the argument set doesn't match with the actual code/binary.

Proposal

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

A full current feature set list with examples and parameter/options.

Developer doc: Include python comments and a Python generation (tested with "epydoc").

Demos

"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 run a set of preliminary demos that are on the test folder 2014.

Do we want to arrange a separated repository for the demos?

Supported tools

In adition to general purpose code managing capabilities, there are different tool specific actions:

GHDL*: some work was made in a separate branch. This is not included in master and follows an older software design (2 years old).

Xilinx biased, no synthesis makefiles for Altera.

Proposal

Add a supported action table and a demo project / example.

Add support for Makefile generation handling Quartus synthesis.

Simulation

Each simulation makefile builds a run project / workspace and then specific.

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 family)

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 upgraded again.

Xilinx

Altera

Proposal

Add family as an optional 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.

Remote Synthesis

Simulation

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)

New workflow support

Higher level abstraction.

PlanAhead:

• Embedded cores (xps) -> Zynq, Dual core.
• IP (xco) -> Issue already requested #938.
• Optimized for tcl: concurrent runs, work batches...

New Features

Current status?

Issues

Some of the issues marked as solved are not applied in master -- may they be on a branch?.

Some examples I've already fixed in 2014 branch)

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.

Should we re-check issues?