diff --git a/tools/hdltool_readme.txt b/tools/hdltool_readme.txt index d722b20eea8f0d03515d910bf81a6cf62fc4c91b..1cdda64d0d746529c71b1ceee2759d8653121512 100644 --- a/tools/hdltool_readme.txt +++ b/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