diff --git a/tools/hdltool_readme.txt b/tools/hdltool_readme.txt
index 838fd14908856c8aecb2079e67e1f8b5a3cb44bf..d4564a386863b750860fca7760ec1d8e0754c037 100644
--- a/tools/hdltool_readme.txt
+++ b/tools/hdltool_readme.txt
@@ -378,7 +378,7 @@ In addition several other files need to be modified to be able to simulate the I
- the compile_ip.tcl files need to be updated according to the generated/sim/mentor/msim_setup.tcl
because the IP library name and file names may have changed
. the copy_hex_files.tcl files need to be updated
- . the IP lirbary name in the hdllib.cfg of the IP needs to be changed
+ . the IP library name in the hdllib.cfg of the IP needs to be changed
This concerned these files:
@@ -441,20 +441,6 @@ and the try to simulate a design, eg.:
- unb2_minimal
-The disadvantage of this scheme is that only one version of Quartus can be supported. For a minor version
-change it may not be necessary to upgrade, but for a major version change or for a device family change it
-probably is. To preserve the old version IP it is best to treat the new version as a new technology. For
-example for Arria10 we now use Quartus 15.0 and device family of UniBoard2 v0 and the IP for that is kept
-in:
-
- $RADIOHDL/libraries/technology/ip_arria10/
-
-A future version of the IP can be kept in a version sub directory (TBD):
-
- $RADIOHDL/libraries/technology/ip_arria10/v16.x/
-
-
-
3) HDL environment configuration files
@@ -579,6 +565,10 @@ d) hdllib.cfg key descriptions
IP is instantiated as component. Hence the exclusion works because for a component instance that is not used only the
component declaration (in the component package) needs to be known by the tools. Hence the exclusion makes use of the same
VHDL component mechanism as the technology independence.
+ The exclusion is only done for synthesis, so not for simulation. The reason is that for simulation it is oke to keep the
+ library included and also necessary to avoid compile error when the library is mentioned in a LIBRARY clause. For
+ IP libraries this occurs in the tech_*.vhd to declare IP libraries to ensure default binding in simulation, e.g. like in
+ tech_ddr_stratixiv.vhd. This IP library clause is ignored by synthesis, so then the exclusion causes no errors.
The difference between this 'hdl_lib_excludes' key and the 'hdl_lib_technology' key is that the HDL libraries with
'hdl_lib_technology' key value that does not match the specified technologies are not build. Whereas HDL libraries that
are excluded with 'hdl_lib_excludes' are still created in the build directory, but they are not used for that HDL library
@@ -683,9 +673,10 @@ find the new avs2_eth_coe in $RADIOHDL.
5) Build directory location
-The Modelsim and Quartus build location central outside the $RADIOHDL sources directory tree:
+The Modelsim and Quartus build location central outside the $RADIOHDL sources directory tree, whereby the
+subdirectory names are defined by the corresponding keysin the hdltool_<toolset>.cfg:
- <build_dir>/<toolset>/<tool_name>/<hdl_lib_name>
+ <build_dir>/<toolset_name>/<hdl_lib_name>
eg.
@@ -932,6 +923,87 @@ p) Python peripherals
may be to use a synbolic link from a central directory to each local Python peripheral.
+q) Improve support IP for multiple FPGA device types and Quartus tool versions
+
+The IP is FPGA type specific (because it needs to be defined in the Qsys source file) and tool version specific
+(because some parameters and even port IO may change). Currently there is only one IP directory per FPGA
+technology (eg. ip_arria10) so there is no further separation into device family type and tool version. The
+disadvantage of this scheme is that only one version of Quartus can be supported. For a minor version
+change it may not be necessary to upgrade, but for a major version change or for a device family type (eg. from
+engineering sample to production sample) change it probably is. To preserve the old version IP it is best to
+treat the both the FPGA device version id and the Quartus tool version as a new technology. For example for
+Arria10 we now use Quartus 15.0 and device family of UniBoard2 v0 and the IP for that is kept in:
+
+ $RADIOHDL/libraries/technology/ip_arria10/
+
+This can be renamed in:
+
+ $RADIOHDL/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_15.0/
+
+For a directory name it is allowed to use a '.' instead of a '_'. The directory name is not mandatory, but the name convention is
+to define the FPGA technology as a triplet:
+
+ ip_<fpga family>_device_<fpga identifier>_quartus_<version>
+
+A future version of the IP can be kept in:
+
+ $RADIOHDL/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/
+
+The technology_pkg.vhd then gets;
+
+ c_tech_arria10_device_10AX115U4F45I3SGES_quartus_14_1 = ...;
+ c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0 = ...;
+ c_tech_arria10 = c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0; -- optional default
+
+The hdllib.cfg of the specific technology IP library then has key (only one value):
+
+ hdl_lib_technology = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
+
+The hdltool_<toolset>.cfg can support multiple technologies eg. to be able to simulate a system with more than one FPGA that are
+of different technology (eg. an application with Uniboard1 and Uniboard2):
+
+ technology_names = ip_stratixiv
+ ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
+
+All libraries that have hdl_lib_technology value that is not in the list of technology_names are removed from the dictionary list
+by hdl_config.py, so these IP libraries will not be build.
+
+The build directory currently contains:
+
+ <build_dir>/<toolset_name>/<hdl_lib_name>
+
+This scheme is probably still sufficent to also support the FPGA technology as a triplet. However it may be necessary to rename the
+library key values in the IP hdllib.cfg to contain the full triplet information, so eg.
+
+ hdl_lib_name = ip_arria10_fifo
+ hdl_library_clause_name = ip_arria10_fifo_lib
+
+then becomes:
+
+ hdl_lib_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo
+ hdl_library_clause_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo_lib
+
+this is a bit awkward. If only one Quartus version and only one device type are supported per toolset, then all these versions can keep
+the same basic hdl_lib_name and hdl_library_clause_name because the IP libraries that are not used can be removed from the build.
+Alternatively the hdllib_config.py could support multiple technology version IP libraries that use the same logical library name and use
+clause.
+
+The purpose is to be able to handle in parallel different FPGA vendors, different FPGA types and different tool version. We do not have
+to support all combinations, but only the combinations that we actually use. Eg. for the FPGA type this implies that we only support the FPGA types
+that are actually used on our board. If we make a new board with another FPGA, then we add the technology triplet for that FPGA.
+
+
+r) Improve toolset scheme
+
+The toolset defines the combination of Modelsim version and Quartus version. Currently there are two toolsets 'unb1' and 'unb2'. This
+toolset scheme needs to be improved because:
+
+- for python they are defined by the hdltool_<toolset>.cfg, but for the run_* bash scripts they are defined in set_modelsim and set_quartus,
+ can they be defined in a common source (eg. base on hdltool_<toolset>.cfg set an environment variable and use that for bash). The bash
+ script must then be ran from the same terminal as where the python config script was used to set the environment variable, because otherwise
+ the environment variable is not set or may not be correct.
+- the toolsets are tight to a board name 'unb1' (is that oke?) or should we use more general toolset names, or do we need a symbolic toolset names at all?
+- there is also a 'site' level in the bash scripts (is that still needed?)