Added to do plan for: hdltool.cfg per toolset, generate IP, only central build...

Added to do plan for: hdltool.cfg per toolset, generate IP, only central build tree, location of modelsim_project_files.txt, support multiple  --technology.

tools/hdltool_readme.txt

@@ -492,7 +492,7 @@ a) modelsim_config.py command line arguments:
    etc.
    
    Instead of the --compile option it is also an option to define a separate modelsim_compile.py script.
-
+   
 b) quartus_config.py command line arguments:
    --lib       : default create all qsf, qip, qpf, when specified only create project files for listed libraries
    --compile   : default do not synthesise the projects, when specified run Quartus to synthesize and create a sof.
@@ -524,17 +524,83 @@ f) Generate Quartus IP key
    around the qsys-generate command. The generate_ip.sh seems an unnecessary intermediate step if the IP is 
    generated automatically. The IP could be generated automatically based on a megawizard key or a qsys key that
    has the description file as value. The advantage of a generate_ip.sh script is that it can hide whether the
-   MegaWizard or QSYS needs to be used to generate the IP, so in that way a 'quartus_generate_ip' key can fit both.
-   Eg. a --generate_ip command line argument for quartus_config.py (rather than a separate quartus_generate_ip.py
-   script) can then generate the IP for all libraries that have such a key. The IP can then be generated outside the
-   SVN tree. For generated IP that is kept in SVN that IP would then need to be copied to the build tree.
+   MegaWizard or QSYS needs to be used to generate the IP, so in that way a 'quartus_generate_ip' key can fit both:
+   
+     quartus_copy_files =
+         generate_ip.sh
+         <technology>_<hdl_lib_name>.qsys
+     quartus_generate_ip = generate_ip.sh
+   
+   The 'quartus_copy_files' key is used to copy the IP generation source file and the generation script to the
+   build directory. The 'quartus_generate_ip' key identifies the script that needs to be ran when the IP has to be
+   generated. Eg. a --generate_ip command line argument for quartus_config.py (rather than a separate
+   quartus_generate_ip.py script) can then generate the IP for all libraries that have such a key. The IP can then
+   be generated outside the SVN tree. The $IP_DIR path compile_ip.tcl needs to be adjusted to generated/ and the
+   IP then gets generated in:
+   
+      $HDL_BUILD_DIR/quartus/<hdl_lib_name>/generated
+   
+   For generated IP that is kept in SVN that IP could still remain there.
+   
    The hdllib.cfg should then also define a build dir, eg.:
     
      build_dir_ip = $HDL_BUILD_DIR
     
    or build_dir_megawizard and build_dir_qsys? But then perhaps build_dir_synth should become build_dir_quartus?
+   The $HDL_BUILD_DIR now has a modelsim and quartus subdir:
+    
+      $HDL_BUILD_DIR/modelsim       -- made by modelsim_config.py using tool_name_sim from hdltool.cfg
+      $HDL_BUILD_DIR/quartus        -- made by quartus_config.py using tool_name_synth from hdltool.cfg
+   
+   The IP can be put in a subdir
+   
+      $HDL_BUILD_DIR/quartus_ip     -- made by quartus_config.py using a new tool_name_ip from hdltool.cfg
+      
+   or can it be put in the tool_name_synth directory:
    
-g) regression test script
+      $HDL_BUILD_DIR/quartus
+      
+   or do we need tool_name_megawizard and tool_name_qsys to beable to create:
+   
+      $HDL_BUILD_DIR/megawizard     -- Altera MegaWizard
+      $HDL_BUILD_DIR/qsys           -- Altera QSYS
+      $HDL_BUILD_DIR/coregen        -- Xilinx
+      
+   Probably it is not so important whether the IP is generated by MegaWizard or Qsys, because that selection is
+   already covered by the generate_ip.sh scripts. In the hdltool.cfg both MegaWizard and Qsys can be regarded as
+   being part of the Quartus tool. Therefore using tool_name_ip provides sufficient distinction in IP build
+   sub directory. However the IP could also be generated into the tool_name_synth build directory and then even
+   the tool_name_ip key is not needed, because the tool_name_synth sub directory also suits the Quartus IP
+   generation.
+   
+   Conclusion:
+   - Using build_dir_synth is also sufficient/suitable to define the build subdirectory for IP generation.
+   
+g) hdltool.cfg per toolset
+   . Is the hdltool.cfg necessary/useful at all?
+   . The model_tech_dir key in hdltool.cfg depends on the modelsim version that is defined in the toolset. The
+     model_tech_dir gives the path to the modelsim.ini that needs to be included in the mpf, because without the
+     IEEE and STD libraries are not known anymore after the mpf is loaded.
+   . Should we define a dedicated hdltool.cfg for each toolset similar as with the unb1 and unb2 toolsets that are
+     specified with the run_modelsim and run_quartus startup scripts. The hdltool_<toolset>.cfg then needs to be
+     specified via a --toolset command line option. For --toolset unb1 the hdltool_unb1.cfg then becomes eg.:
+     
+       tool_name_sim = modelsim_6_6c
+       tool_name_synth = quartus_11_1
+       model_tech_dir = /home/software/Mentor/6.6c/modeltech
+     
+     and for unb2 the hdltool_unb2.cfg then becomes eg:
+     
+       tool_name_sim = modelsim_10.4
+       tool_name_synth = quartus_14_1
+       model_tech_dir = /home/software/Mentor/10.4/modeltech
+   
+     Currently the 6.6c modelsim.ini is used even if Modelsim 10.4 is ran.
+     
+   Conclusion:
+   - Keep hdltool.cfg, but define dedicated hdltool_<toolset>.cfg and add --toolset command line option.
+
+h) regression test script
    - To simulate all self-checking VHDL test benches and report the result. 
    - To simulate all self-checking Python MM - VHDL test case / test benches and report the result. 
    The pure HDL tests can be identified by the values of some 'regression_test_hdl' key. The value indicates the HDL
@@ -543,14 +609,28 @@ g) regression test script
    HDL test bench. Note that the pure VHDL test benches could be perphaps also be regarded as a special case of the
    Python MM - VHDL tests, ie. as a test without MM.
 
-h) multiple libRootDirs for finding hdllib.cfg files
+i) multiple libRootDirs for finding hdllib.cfg files
    Currently hdlib.cfg files are search from one rootDir by find_all_dict_file_paths() in common_dict_file.py. It
    would be usefule to be able to specify multiple rootDirs for the search path. This allows finding eg. all
    hdllib.cfg in two different directory trees without having to specifiy their common higher directory root which
    could be a very large tree to search through. Furthermore by being able to specify the rootDirs more precisely
    avoids finding unintended hdllib.cfg files.
   
-  
+j) Central build tree or local build directory
+   The get_lib_build_dirs() in hdl_config.cfg provides the option to build the sources locally in the library
+   directory or in a central build tree. The central build tree is preferred, because the local build in the library
+   is scattered and fills the SVN tree with build files. The local build option is not used. Therefore it may be
+   better and more clear to completely remove the support to do a local build from get_lib_build_dirs().
+   
+k) Support multiple --technology
+   It should be possible to define multiple technologies at the --technology option. As long as Modelsim supports 
+   these technolgies (ie the technology libraries are available) then unused technologies are not disturbing and 
+   then they also do not cause simulation load errors with the 'modelsim_search_libraries' key.
+   
+l) Location of modelsim_project_files.txt
+   Default the modelsim_project_files.txt is now created in the SVN directory set by 'toolRootDir'/modelsim. Instead
+   the modelsim_project_files.txt should better be created in the build directory 'build_dir_sim'/modelsim/.
+   
       
 101) More ideas