... | ... | @@ -35,23 +35,24 @@ current Master [Masterforisypusers](Masterforisypusers). |
|
|
### "doc" folder in sources
|
|
|
|
|
|
It includes two pdf files that are not valid for current master as they
|
|
|
are ISYP related.
|
|
|
are ISYP/v1.0 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.
|
|
|
- **hdlmake\_manual.pdf**: this is old, points to ISYP/v1.0
|
|
|
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/v1.0.
|
|
|
|
|
|
It also includes a document 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.
|
|
|
ISYP/v1.0 again and only points to VHDL support.
|
|
|
|
|
|
### Wiki content
|
|
|
|
|
|
The ISYP and current Masted related info is mixed across the wiki.
|
|
|
The older ISYP/v1.0 and current Master related info is mixed across the
|
|
|
wiki.
|
|
|
|
|
|
- [Manifest-variables-description](Manifest-variables-description):
|
|
|
this content is from ISYP. Some of the critical variables for
|
... | ... | @@ -63,10 +64,11 @@ The ISYP and current Masted related info is mixed across the wiki. |
|
|
### Proposal
|
|
|
|
|
|
- Compile all the stuff related with ISYP/v1.0 and set a clear wiki
|
|
|
section for this stuff.
|
|
|
section for this older stuff.
|
|
|
- Write a new user documentation for Master in texinfo format:
|
|
|
- Complete feature list and related parameters/arguments/options.
|
|
|
- Full set of example tutorials covering the most important
|
|
|
- Add a complete feature list and a full related
|
|
|
parameters/arguments/options user reference.
|
|
|
- Introduce a set of example tutorials covering the most important
|
|
|
features.
|
|
|
- Generate developer doc by using a standard code documentation tool
|
|
|
(Epydoc or Sphinx)
|
... | ... | @@ -77,42 +79,51 @@ There is only a single test in the Master source code (Xilinx ISIM |
|
|
simulation). Creating a separated repository with new tests is listed as
|
|
|
one of the desired new features that needs to be done.
|
|
|
|
|
|
*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.
|
|
|
*Learn by example**: use the same demo projects for both
|
|
|
documentation/tutorial and regression testing. The core features we want
|
|
|
to test are those the users would like to use.
|
|
|
|
|
|
### Test setup
|
|
|
|
|
|
I've deployed a test setup environment in order to evaluate/test the
|
|
|
current Master status and coverage.
|
|
|
A state-of-the-art test setup environment has been deployed 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 test
|
|
|
folder in **2014** branch.
|
|
|
Some of the tests that have already been used for this analysis are in
|
|
|
the hdlmake test folder under the **2014** repository branch.
|
|
|
|
|
|
Ubuntu 14.04 LTS
|
|
|
The following table indicates the most important testground features:
|
|
|
|
|
|
Python 2.7 (Python 3.3/3.4 doesn't work)
|
|
|
|
|
|
Tested on the next architectures.
|
|
|
<table>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td><strong>Operating System</strong></td>
|
|
|
<td>Ubuntu 14.04 LTS "Trusty Tahr"</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td><strong>Python Version</strong></td>
|
|
|
<td>Python 2.7.6 (Python3 not supported)</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td><strong>Architecture</strong></td>
|
|
|
<td>i386, amd64, armhf [1]</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
- i386:
|
|
|
- amd64:
|
|
|
- armhf: Remote synthesis runs OK with minor fixes if a valid xise
|
|
|
project is provided.
|
|
|
- \[1\] All of those hdlmake actions not relying on a local
|
|
|
ISE/Quartus install can be executed from an ARM based processor
|
|
|
running an embedded Linux. e.g. Remote synthesis runs OK with minor
|
|
|
fixes if a valid xise project is provided.
|
|
|
|
|
|
### Proposal
|
|
|
|
|
|
- Develop a list of features that are going to be validate/documented
|
|
|
- Develop a list of features that are going to be validated/documented
|
|
|
- Include a simple test/demo example for every feature we want to
|
|
|
validate/document.
|
|
|
|
|
|
## Synthesis
|
|
|
|
|
|
In adition to general purpose code managing capabilities, there are
|
|
|
different tool specific actions:
|
|
|
|
|
|
### Brand biased
|
|
|
### Brand biased feature set
|
|
|
|
|
|
<table>
|
|
|
<tbody>
|
... | ... | @@ -134,8 +145,6 @@ different tool specific actions: |
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -143,25 +152,31 @@ synthesis not supported. |
|
|
and then launch the synthesis by executing a Quartus shell custom
|
|
|
script:
|
|
|
|
|
|
- https://github.com/stefanrauch/bel_projects.
|
|
|
- GSI Repository: https://github.com/stefanrauch/bel_projects.
|
|
|
|
|
|
### Remote Synthesis
|
|
|
|
|
|
Need a local ISE install in order to build a local xise
|
|
|
|
|
|
Asks for user password multiple times halting the automated flow.
|
|
|
In order to run remote synthesis makefile, an ISE project file must be
|
|
|
provided. The problem is that we need a local Xilinx toolchain install
|
|
|
in order to generate this project from a Makefile.
|
|
|
|
|
|
(I've not tested screen support, just default mode)
|
|
|
This situation may led to ISE project version mismatch between Locally
|
|
|
generated xise file and the remote synthesis deploy.
|
|
|
|
|
|
### Handling Higher Level Hardware Descriptions
|
|
|
|
|
|
Higher level abstraction are not well managed by ISE.
|
|
|
Higher level abstraction such as Xilinx IP Cores and embedded hardware
|
|
|
processors are not well managed by ISE tool. The "de-facto" standard
|
|
|
workflow for handling this Xilinx design stuff is based on **PlanAhead**
|
|
|
tool.
|
|
|
|
|
|
PlanAhead:
|
|
|
PlanAhead supports:
|
|
|
|
|
|
- Embedded cores (xps) -\> Zynq, Dual core.
|
|
|
- IP (xco) -\> Issue already requested \#938.
|
|
|
- Optimized for tcl: concurrent runs, work batches...
|
|
|
- **IP (xco):** Support for Xilinx coregen components has already been
|
|
|
requested in the next issue \#938.
|
|
|
- **Embedded cores (xps):** Zynq dual core ARM Cortex-A9 Processing
|
|
|
System is supported. This device is currently being used for testing
|
|
|
**Libre-FDATool** and **AsyncArt** OHR projects.
|
|
|
|
|
|
### Proposal
|
|
|
|
... | ... | @@ -174,9 +189,10 @@ PlanAhead: |
|
|
## Simulation
|
|
|
|
|
|
Each simulation makefile builds a run project/workspace and then
|
|
|
specific.
|
|
|
specific actions needs to be executed depending on the simulation tool
|
|
|
being handled.
|
|
|
|
|
|
### Coverage
|
|
|
### Tool coverage
|
|
|
|
|
|
<table>
|
|
|
<tbody>
|
... | ... | @@ -202,7 +218,7 @@ specific. |
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>GHDL</td>
|
|
|
<td>PARTIAL [1]</td>
|
|
|
<td>PARTIAL [2]</td>
|
|
|
<td>NO</td>
|
|
|
</tr>
|
|
|
</tbody>
|
... | ... | @@ -216,26 +232,24 @@ 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
|
|
|
file).
|
|
|
- Support for custom simulation scripts.
|
|
|
- Merge and fix GHDL support. This is the only "Free/Libre" real
|
|
|
- Fix and merge 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.
|
|
|
In order to generate an ISE or a Quartus project, the device family
|
|
|
parameter is required. In the current Master, the family support is very
|
|
|
limited.
|
|
|
|
|
|
The way in which hdlmake calculates the family requires a constant
|
|
|
database update as new device families are introduced in the market
|
|
|
(e.g. Zynq family).
|
|
|
The way in which hdlmake calculates the family from the device ID
|
|
|
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.
|
|
|
In adition, some naming schemes are not supported in the current
|
|
|
automatic calculation (e.g. Spartan3E, Spartan3AN...), as already
|
|
|
discussed on hdlmake mailing list.
|
|
|
|
|
|
### Xilinx supported families
|
|
|
|
... | ... | |