Define preliminary hdllib.cfg key names for quartus_generate_ip and...

Define preliminary hdllib.cfg key names for quartus_generate_ip and regression_test_hdl, regression_test_py_sim.diff

tools/hdltool_readme.txt

@@ -501,27 +501,33 @@ d) *_copy_files keys
 
 e) modelsim_search_libraries
    Do not explicitely list all -L libraries at this modelsim_search_libraries key, but instead only the technology
-   name(s). The modelsim_config.py can then itself add the required -L string to the simulation configurations.
+   name(s). The modelsim_config.py can then itself add the required -L string to the simulation configurations. In
+   theory all simulation configurations could get the -L libraries even if they do not need them. This would make
+   the modelsim_search_libraries key obsolete and avoid bothering hdllib.cfg with it.
    
-
-f) create Quartus IP key
+f) Generate Quartus IP key
    The generate_ip.sh scripts for generating the MegaWizard or QSYS IP components in fact are merely a wrapper script
    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. Eg. a --create_ip command line argument for quartus_config.py (or a separate
-   quartus_create_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. The hdllib.cfg should then also define a build dir, eg.:
+   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.
+   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 purhaps build_dir_synth should become build_dir_quartus?
+   or build_dir_megawizard and build_dir_qsys? But then perhaps build_dir_synth should become build_dir_quartus?
    
 g) 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 tests can be identified by the values of some test_* or verify_* key. The pure VHDL test benches could be 
-   purphaps also be regarded as a special case of the Pyhton MM - VHDL tests, ie. as a test without MM.
+   The pure HDL tests can be identified by the values of some 'regression_test_hdl' key. The value indicates the HDL
+   test bench. For Python test cases it is probably easier and more clear to define another key eg.
+   'regression_test_py_sim'. The values they may contain the entire command to run the Python test case with the
+   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
    Currently hdlib.cfg files are search from one rootDir by find_all_dict_file_paths() in common_dict_file.py. It