Added:

100) To do
101) More ideas

tools/hdltool_readme.txt

@@ -33,6 +33,10 @@ Contents:
 
 8) Design revisions
   
+100) To do
+101) More ideas
+
+
 
 
 1) Introduction 
@@ -462,3 +466,79 @@ Each revision should at least have a 'hdllib.cfg' file and a toplevel .vhd file.
 In the toplevel vhdl file you can specify the 'g_design_name' generic (in this example 'unb1_minimal_qsys').
 And in 'hdllib.cfg' you specify the libraries and keys you need, in this case 'unb1_minimal'.
 
+
+
+100) To do
+
+a) modelsim_config.py command line arguments:
+   --lib         : default create all mpf, when specified only create project files for listed libraries
+   --technology  : default create mpf for all libraries, when specified only keep the libraries that are needed for 
+                   the listed technologies
+   --compile     : default do not build the libraries,  when specified also run 'mk clean all' and then 'mk all'
+   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.
+   etc.   
+   
+   Instead of the --compile option it is also an option to define a separate quartus_compile.py script.
+   
+c) quartus_* keys
+   The quartus_* keys are now source oriented. Instead it may be better to redefine thme as target oriented. Eg. a
+   quartus_qsf key that defines to create a qsf file using the intormation listed in the values.
+   
+d) *_copy_files keys
+   - The copy_files() method in hdl_config.py currently uses shutil.rmtree(buildPath), this is probably too risky and
+     needs to be made more save to avoid that accidentally some wrong dir tree is removed.
+   - The source and destination directory definition needs to be made somewhat more clear. The path can be absolute or
+     relative. The relative path can be from hdllib.cfg location in SVN or from the build dir. The direction van be
+     from build dir to dir in SVN or vice versa, or to any directory location.
+
+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.
+   
+
+f) create 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.:
+    
+     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?
+   
+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.
+
+   
+      
+101) More ideas
+
+a) zip script
+   - zip all required libraries for a certain level library --> useful for somebody who wants to reuse a library.
+   - zip all tool environent code --> useful for somebody who wants touse our tool flow but not our HDL.
+   
+b) support dynamic generation of IP
+   Very preliminary ideas:
+   Currently the MegaWizard or QSYS component description file is fixed and created manually in advance via the 
+   GUI. In future the component description file could be created based on parameters that are defined in the
+   hdllib.cfg or even parameters that depend on the requirements from the design. In a dynamic flow the hdllib.cfg
+   for IP could even not exist as a file, but only as a dictionary in the script. 
+   
+c) Link RadioHDL developments with the OneClick MyHDL developments.
+   The hdllib.cfg dictionary format seems useful also in the OneClick flow. For some created libraries the hdllib.cfg
+   may not exist as a file and but only as the dictionary in the script. The various methods in modelsim_config.py
+   and quartus_config.py can also be reused in a OneClick flow.
+ 
+   
\ No newline at end of file