OpenCores
URL https://opencores.org/ocsvn/radiohdl/radiohdl/trunk

Subversion Repositories radiohdl

[/] [radiohdl/] [trunk/] [doc/] [hdltool_readme.txt] - Diff between revs 4 and 7

Show entire file | Details | Blame | View Log

Rev 4 Rev 7
Line 1... Line 1...
 
Author E. Kooistra, ASTRON:
 
This hdltool_readme.txt is a stripped down with left over content. All removed
 
content is now moved and restructured in the RadioHDL markdown (*.md)
 
documentation.
 
 
 
Contents:
 
 
 
1) Introduction
 
 
 
2) Tool environment setup
 
  l) UniBoard2 device family
 
  m) Upgrading the IP for new version of Quartus or for another device family
 
 
g) Tool start scripts
3) HDL environment configuration files
 
  b) Target configuration scripts
The definitions for actually running Modelsim and Quartus are not kept in the ~/.bashrc file or the setup script but are
  c) hdl_buildset_.cfg key sections
set in a tool start script:
 
 
 
  ${RADIOHDL_GEAR}/modelsim/run_modelsim      # calls set_quartus and starts the Modelsim GUI for simulation
 
  ${RADIOHDL_GEAR}/quartus/run_quartus        # calls set_quartus and starts the Quartus GUI for synthesis
 
 
 
The paths to these tool start scripts are defined in setup_radiohdl.sh. In addition to the advantages mentioned above for the environment setup scripts,
 
the advantages of using a seperate tool start script is:
 
 
 
  - different versions of the tool can be started in parallel on the same machine, because the tool start script settings
 
    only apply to the started tool environment
 
 
 
 
 
 
 
i) How to start Quartus for RadioHDL
 
 
 
For building a SOPC system use:
 
  > run_sopc      unb1 unb1_minimal_sopc
 
  > run_app       unb1 unb1_minimal_sopc             # calls: run_bsp, run_reg, run_mif
 
  > run_app_clean unb1 unb1_minimal_sopc app=unb_osy
 
  > run_qcomp     unb1 unb1_minimal_sopc
 
  > run_all_sopc  unb1 unb1_minimal_sopc             # sequentially running: run_sopc + run_app + run_qcomp
 
  > run_rbf       unb1 unb1_minimal_sopc
 
  > run_sof       unb1 unb1_minimal_sopc 0
 
 
 
For building a QSYS system use:
 
  > run_qsys      unb1 unb1_minimal_qsys
 
  > run_sopc      unb1 unb1_minimal_sopc     # (normally not needed but the unb1_minimal_qsys revision has a GENERATE sopc-OR-qsys section)
 
  > run_app       unb1 unb1_minimal_qsys use=qsys
 
  > run_qcomp     unb1 unb1_minimal_qsys
 
  > run_all_qsys  unb1 unb1_minimal_qsys     # sequentially running: run_qsys + run_app + run_qcomp
 
  > run_rbf       unb1 unb1_minimal_qsys
 
  > run_sof       unb1 unb1_minimal_qsys 0
 
 
 
 
 
j) How to start Modelsim for UNB
 
 
 
GUI:
 
 
 
  > unb_msim &        # for UNB
 
  > aaf_msim &        # for AARTFAAC
 
  > paasar_msim &     # for PAASAR
 
 
 
See the setup_unb.sh environment script and ASTRON_RP_1354_unb_minimal.pdf for more description.
 
 
 
 
 
n) How to use RadioHDL for Lofar RSP
 
 
 
* The Lofar Station firmware is kept in a separate SVN repository at:
 
 
 
    https://svn.astron.nl/Station
 
 
 
  The firmware for the RSP board is kept in:
 
 
 
    https://svn.astron.nl/Station/trunk/RSP
 
 
 
  In setup_radiohdl.sh add the path to the local SVN checkout of the Station
 
  firmware:
 
 
 
    export RSP=${SVN}/../Station/trunk/RSP
 
 
 
  and add ${RADIOHDL_GEAR}/ise to the PATH environment variable.
 
 
 
* To compile the Xilinx ISE10.1.03 models with Modelsim 6.6c under linux do:
9) RadioHDL directory structure
 
  a) applications
 
  b) boards
 
  c) libraries
 
  d) software
 
  e) tools
 
  f) sub directories
 
 
  The compxlib adds the Xilinx libraries to the [libraries] section in the
100) To do
  /home/software/Mentor/6.6c/modeltech/modelsim.ini file. Therefore make
  b) Generate Quartus IP key
  sure to first copy this original installation modelsim.ini file, so that
  f) Improve support IP for multiple FPGA device types and Quartus tool versions
  we can restore it.
  g) Improve buildset_name scheme
 
  h) Declare IP libraries to ensure default binding in simulation.
 
 
    cd /home/software/modelsim_xilinx_libs/ise/10.1.03
101) More ideas
    sudo mkdir vhdl
  a) zip scripts
    sudo mkdir verilog
  b) support dynamic generation of IP
    sudo /home/software/Xilinx/ISE/10.1/ISE/bin/lin/compxlib -s mti_se -f all -l vhdl    -dir vhdl    -p /home/software/Mentor/6.6c/modeltech/linux_x86_64
  c) Link RadioHDL developments with the OneClick MyHDL developments.
    sudo /home/software/Xilinx/ISE/10.1/ISE/bin/lin/compxlib -s mti_se -f all -l verilog -dir verilog -p /home/software/Mentor/6.6c/modeltech/linux_x86_64
 
 
 
  Use the library mappings in the modelsim.ini that was modified by compxlib
102) Know errors
  to create:
 
 
 
    tools/ise/create hdl_libraries_ip_virtex4.txt
 
 
 
  The modelsim_config.py using hdl_libraries_ip_virtex4.txt to map the Xilinx
2) Tool environment setup
  library files in each HDL library project files. Therefore the central
l) UniBoard2 device family
  mapping in the Modelsim installation modelsim.ini file is unwanted and not
 
  needed.
 
 
 
* Create tools/hdl_buildset_rsp.cfg HDL tool configuration dictionary file for buildset 'rsp'
The device family of the Arria10 on UniBoard2 v0 is 10AX115U4F45I3SGES as can be seen at the photo of the FPGA:
 
 
* Create bash scripts to start up ISE based on the buildset 'rsp' in tools/ise:
    $RADIOHDL/boards/uniboard2/libraries/unb2_board/quartus/unb2_board_v0_device_family.JPG
    run_ise
 
        \--> set_ise
 
                \--> ise_version.sh
 
                \--> ise_generic.sh
 
 
 
  This is similar as for other tools like Modelsim, Quartus. The advantage of
The device family is used in:
  this approach is that the tool settings are only made when the tool is ran
- $RADIOHDL/boards/uniboard2/libraries/unb2_board/quartus/unb2_board.qsf
  and not in the .bashrc file. These bash scripts are kept in SVN and thus the
- QSYS IP component files
  same tool settings are used by all engineers.
- QSYS system design file
 
 
 
 
 
m) Upgrading the IP for new version of Quartus or for another device family
 
 
 
On 20 May 2015 Eric manually upgraded all current Arria10 IP to Quartus 15.0 and used the Qsys GUI menu view->device family to set the FPGA that is on UniBoard2 v0.
 
These are the current Qsys IP components for ip_arria10:
 
 
 
    kooistra@dop233 ip_arria10 $ svn status -q
 
    M       ddio/ip_arria10_ddio_in_1.qsys
 
    M       ddio/ip_arria10_ddio_out_1.qsys
 
    M       ddr4_4g_1600/ip_arria10_ddr4_4g_1600.qsys
 
    M       ddr4_8g_2400/ip_arria10_ddr4_8g_2400.qsys
 
    M       fifo/ip_arria10_fifo_dc.qsys
 
    M       fifo/ip_arria10_fifo_dc_mixed_widths.qsys
 
    M       fifo/ip_arria10_fifo_sc.qsys
 
    M       flash/asmi_parallel/ip_arria10_asmi_parallel.qsys
 
    M       flash/remote_update/ip_arria10_remote_update.qsys
 
    M       mac_10g/ip_arria10_mac_10g.qsys
 
    M       phy_10gbase_r/ip_arria10_phy_10gbase_r.qsys
 
    M       phy_10gbase_r_24/ip_arria10_phy_10gbase_r_24.qsys
 
    M       pll_clk125/ip_arria10_pll_clk125.qsys
 
    M       pll_clk200/ip_arria10_pll_clk200.qsys
 
    M       pll_clk25/ip_arria10_pll_clk25.qsys
 
    M       pll_xgmii_mac_clocks/ip_arria10_pll_xgmii_mac_clocks.qsys
 
    M       pll_xgmii_mac_clocks/pll_xgmii_mac_clocks.qsys
 
    M       ram/ip_arria10_ram_cr_cw.qsys
 
    M       ram/ip_arria10_ram_crw_crw.qsys
 
    M       ram/ip_arria10_ram_crwk_crw.qsys
 
    M       ram/ip_arria10_ram_r_w.qsys
 
    M       transceiver_phy_1/transceiver_phy_1.qsys
 
    M       transceiver_phy_48/transceiver_phy_48.qsys
 
    M       transceiver_pll/transceiver_pll.qsys
 
    M       transceiver_pll_10g/ip_arria10_transceiver_pll_10g.qsys
 
    M       transceiver_reset_controller_1/ip_arria10_transceiver_reset_controller_1.qsys
 
    M       transceiver_reset_controller_1/transceiver_reset_controller_1.qsys
 
    M       transceiver_reset_controller_24/ip_arria10_transceiver_reset_controller_24.qsys
 
    M       transceiver_reset_controller_48/ip_arria10_transceiver_reset_controller_48.qsys
 
    M       transceiver_reset_controller_48/transceiver_reset_controller_48.qsys
 
    M       tse_sgmii_gx/ip_arria10_tse_sgmii_gx.qsys
 
    M       tse_sgmii_lvds/ip_arria10_tse_sgmii_lvds.qsys
 
 
 
In addition several other files need to be modified to be able to simulate the IP:
 
 
 
    - the tech_*.vhd files that instantiate the IP component need to have the LIBRARY clause for binding
 
    - 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 library name in the hdllib.cfg of the IP needs to be changed
 
 
 
This concerned these files:
 
 
 
    kooistra@dop233 trunk $ svn status -q
 
    M       libraries/technology/10gbase_r/tech_10gbase_r_arria10.vhd
 
    M       libraries/technology/ddr/tech_ddr_arria10.vhd
 
    M       libraries/technology/flash/tech_flash_asmi_parallel.vhd
 
    M       libraries/technology/flash/tech_flash_remote_update.vhd
 
    M       libraries/technology/ip_arria10/ddio/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/ddr4_4g_1600/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/ddr4_4g_1600/copy_hex_files.tcl
 
    M       libraries/technology/ip_arria10/ddr4_4g_1600/hdllib.cfg
 
    M       libraries/technology/ip_arria10/ddr4_8g_2400/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/ddr4_8g_2400/copy_hex_files.tcl
 
    M       libraries/technology/ip_arria10/ddr4_8g_2400/hdllib.cfg
 
    M       libraries/technology/ip_arria10/flash/asmi_parallel/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/flash/asmi_parallel/hdllib.cfg
 
    M       libraries/technology/ip_arria10/flash/remote_update/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/flash/remote_update/hdllib.cfg
 
    M       libraries/technology/ip_arria10/mac_10g/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/mac_10g/hdllib.cfg
 
    M       libraries/technology/ip_arria10/phy_10gbase_r/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/phy_10gbase_r/hdllib.cfg
 
    M       libraries/technology/ip_arria10/phy_10gbase_r_24/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/phy_10gbase_r_24/hdllib.cfg
 
    M       libraries/technology/ip_arria10/pll_clk125/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/pll_clk125/hdllib.cfg
 
    M       libraries/technology/ip_arria10/pll_clk200/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/pll_clk200/hdllib.cfg
 
    M       libraries/technology/ip_arria10/pll_clk25/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/pll_clk25/hdllib.cfg
 
    M       libraries/technology/ip_arria10/pll_xgmii_mac_clocks/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/pll_xgmii_mac_clocks/hdllib.cfg
 
    M       libraries/technology/ip_arria10/transceiver_pll_10g/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/transceiver_pll_10g/hdllib.cfg
 
    M       libraries/technology/ip_arria10/transceiver_reset_controller_1/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/transceiver_reset_controller_1/hdllib.cfg
 
    M       libraries/technology/ip_arria10/transceiver_reset_controller_24/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/transceiver_reset_controller_24/hdllib.cfg
 
    M       libraries/technology/ip_arria10/tse_sgmii_gx/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/tse_sgmii_gx/hdllib.cfg
 
    M       libraries/technology/ip_arria10/tse_sgmii_lvds/compile_ip.tcl
 
    M       libraries/technology/ip_arria10/tse_sgmii_lvds/hdllib.cfg
 
    M       libraries/technology/mac_10g/tech_mac_10g_arria10.vhd
 
    M       libraries/technology/pll/tech_pll_clk125.vhd
 
    M       libraries/technology/pll/tech_pll_clk200.vhd
 
    M       libraries/technology/pll/tech_pll_clk25.vhd
 
    M       libraries/technology/pll/tech_pll_xgmii_mac_clocks.vhd
 
    M       libraries/technology/technology_select_pkg.vhd
 
    M       libraries/technology/tse/tech_tse_arria10.vhd
 
 
 
Then run generate-all-ip.sh and try to simulate the test benches that verify the IP:
 
 
 
  - tb_eth
 
  - tb_tr_10GbE
 
  - tb_io_ddr
 
 
* Add 'rsp' buildset for Modelsim and ISE versions to tools/modelsim/set_modelsim.
and the try to simulate a design, eg.:
 
 
* To start the ISE GUI do:
  - unb2_minimal
  > run_ise rsp &
 
 
 
* To start the Modelsim GUI do:
 
  > run_modelsim rsp &
 
 
 
 
 
3) HDL environment configuration files
3) HDL environment configuration files
 
 
d) hdl_buildset_.cfg key descriptions
b) Target configuration scripts
 
 
- project_dir_depth_sim =
 
    The project file will be located in the build dir or at some levels deeper in the build dir.
 
    These optional extra subdirectory levels allow for relative file reference from project file
 
    location. This is useful to be able to keep memory initialisation files in the library build
 
    directory that are referred to using some fixed ../../ path in the HDL code.
 
    . project_deeper_subdir = '' when project_dir_depth_ = 0 or not in tool_dict
 
    . project_deeper_subdir = 'p/' when project_dir_depth_ = 1
 
    . project_deeper_subdir = 'p/p/' when project_dir_depth_ = 2,
 
    . project_deeper_subdir = 'p/p/p/' when project_dir_depth_ = 3, etc
 
 
 
- project_dir_depth_synth =
 
    Same purpose as project_dir_depth_sim, but for synthesis project file location in build tree.
 
 
 
 
 
 
 
5) Build directory location
 
 
 
The Modelsim and Quartus build location central outside the $HDL sources directory tree, whereby the
  t3. verify VHDL test benches in simulation - modelsim_regression_test_vhdl.py
subdirectory names are defined by the corresponding keysin the hdl_buildset_.cfg:
 
 
 
  ${RADIOHDL_BUILD_DIR}//
c) Replace SOPC avs2_eth_coe instance
 
 
eg.
Replace in SOPC instance avs_eth_0 with avs_eth_coe by avs2_eth_coe. The eth now uses eth_pkg.vhd from
 
$RADIOHDL. The avs_eth_coe still uses the eth_pkg.vhd from $UNB and this causes duplicate source file
  ${RADIOHDL_BUILD_DIR}/unb1/modelsim/common
error in synthesis. Therefore open the SOPC GUI and replace the instance avs_eth_0 with avs_eth_coe by
 
the avs2_eth_coe component.
The advantage of the central directory build tree is that it can easily be removed (using rm -rf) and
 
recreated (using modelsim_config.py and quartus_config.py). For synthesis recreation of targets like sof files can take much
Make sure that the user_component.ipx is set up oke (see point 2e), because that is needed for SOPC to
time though.
find the new avs2_eth_coe in $RADIOHDL.
 
 
 
 
 
9) RadioHDL directory structure
 
 
 
Currently, the RadioHDL SVN repository is contained within the UniBoard_FP7 SVN repository, at the following URL:
 
 
 
https://svn.astron.nl/UniBoard_FP7/RadioHDL/trunk
 
 
 
The above location might change in the future.
 
 
 
The following sections describe the subdirectories that exist.
 
 
 
a) applications//designs//revisions/
 
                                                    /quartus
 
                                                    /src
 
                                                    /tb
 
                               libraries/
 
 
 
   . Contains firmware applications designs, categorized by project.
 
 
 
b) boards/
 
         /uniboard2a/designs/unb2a_led/quartus
 
                                       src
 
                                       tb
 
                    /libraries/unb2a_board/quartus
 
                                           src
 
                                           tb
 
 
 
   . Contains board-specific support files and reference/testing designs
 
     . /designs/
 
       . Contains application designs that can be run on that board to test board-specific features.
 
     . /libraries/
 
       . Contains board-specific support files, such as firmware modules to communicate with board-specific ICs,
 
         constraint files, pinning files, board settings template files
 
 
 
c) libraries//
 
             base
 
             dsp
 
             external
 
             io
 
             technology/...
 
                        ip_arria10_e3sge3
 
   . See libraries_hierarchy_and_structure.jpg and readme_libraries.txt
 
   . Library of reusable firmware blocks, categorized by function and in which generic functionality is separated
 
     from technology. Within technology another seperation exists between generic technology and hardware-specific IP.
 
   . The library_category external/ contains HDL code that was obtained from external parties (e.g. open source).
 
   . //designs/
 
     . Contains reference designs to synthesize the library block for specific boards.
 
 
 
d) software/
 
   . Intended for software that runs on a PC, such as control/monitoring of boards and programs to capture and process
 
     board output, e.g. sent via Ethernet to the processing machine.
 
 
 
e) tools/
 
   . Contains the RadioHDL tools that are described in this readme file.
 
 
 
f) sub directories
 
The subdirectories that reoccur contain:
 
 
 
   - src/vhdl  : contains vhdl source code that can be synthesised
 
   - tb/vhdl   : contains vhdl source code that can is only for simulation (e.g. test benches, models, stubs)
 
   - quartus   : synthesis specific settings for design that uses Quartus and an Altera FPGA
 
   - vivado    : synthesis specific settings for design that uses Vivado and an Xilinx FPGA
 
   - revisions : contains revisions of a design that only differ in generic settign
 
 
 
The separation of src/vhdl and tb/vhdl VHDL files is not mandatory, but can be convenient. An alternative
 
would be to keep all VHDL in one vhdl/ sub directory. The hdl_lib_uses_synth key in hdllib.cfg typically
 
contains the files from src/vhdl and the hdl_lib_uses_sim key typically contains the files from tb/vhdl.
 
The synthesis will only see the VHDL files that are listed at the hdl_lib_uses_synth key, because the files
 
at the hdl_lib_uses_sim key are not needed for synthesis and could even confuse synthesis (e.g. warnings that
 
file IO ignored because it is not possible to synthesize).
 
 
 
 
 
 
100) To do
100) To do
 
 
a) quartus_* keys and synth_top_level_entity
 
   . The quartus_* keys are now source oriented. Instead it may be better to redefine them as target oriented. Eg. a
 
     quartus_create_qsf key that defines to create a qsf file using the information listed in the values.
 
     Whether a key is source oriented or target oriented depends on whether its files are used for one or more targets.
 
     In general if a file is used for more targets then source oriented is preferred to avoid having to list the file
 
     name twice. If a file is used only for one target then target oriented is preferred to be more clear about the
 
     purpose of the key.
 
   . The synth_top_level_entity enforces the creation of a qpf and qsf. This kind of hidden behavior is not so nice.
 
     Instead it is more clear to have an explicit quartus_create_qpf and quartus_create_qsf key to define this.
 
 
 
b) Generate Quartus IP key
b) Generate Quartus IP key
   The generate_ip.sh scripts for generating the MegaWizard or QSYS IP components in fact are merely a wrapper script
   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 may seem an unnecessary intermediate step if the IP is
   around the 'qmegawiz' and 'qsys-generate' commands. The generate_ip.sh may seem an unnecessary intermediate step if
   generated automatically. The IP could be generated automatically based on a megawizard key or a qsys key that
   the IP is generated automatically. The IP could be generated automatically based on a megawizard key or a qsys key
   has the description file as value. However the advantage of a generate_ip.sh script is that it can hide whether the
   that has the description file as value.
   MegaWizard or QSYS needs to be used to generate the IP, so in that way a 'quartus_generate_ip' key can fit both:
 
 
   A disadvantage of the generate_ip.sh is that currently they use a fixed selection of the buildset_name, so they do not use
     quartus_copy_files =
   the -t argument. An advantage of a generate_ip.sh script is that it can hide whether the MegaWizard or QSYS needs
         generate_ip.sh
   to be used to generate the IP, so in that way a 'quartus_generate_ip' key can fit both. Another advantage is that
         _.qsys
   the generate_ip.sh can call 'qmegawiz' or 'qsys-generate' multiple time and with lots of arguments. Without
     quartus_generate_ip = generate_ip.sh
   generate_ip.sh this would become:
 
 
 
     quartus_generate_ip =
 
       qmegawiz filename and arguments
 
       qmegawiz filename and arguments
 
 
 
   Which is difficult to parse, because arguments can contain spaces and all arguments then have to be on one line.
 
   Within the cfg files only lists of values and lists of value pairs without spaces are supported.
 
   Therefore it is better to define a *_generate_ip key per generate IP tool. This is also more clear, because it shows
 
   in the cfg file which IP generation tool is used.
 
 
 
   The key values are the IP config files that need to be generated. First these IP config files need to be copied
 
   to the build dir using quartus_copy_files. The IP generate command options are then defined by the method that
 
   processes the qmegawiz_generate_ip or qsys_generate_ip key. The options can be complicated, but it appears that they
 
   are the same for all IP, so it is fine to define the options hard coded in the method or by some options txt file:
 
 
 
     qmegawiz_generate_ip =
 
       filename
 
       filename
 
 
 
     qsys_generate_ip = filename
 
 
   The 'quartus_copy_files' key is used to copy the IP generation source file and the generation script to the
   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
   build directory.
   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
   The '*_generate_ip' key identifies the tool script that needs to be ran when the IP has to be generated. The toolscript
   be generated outside the SVN tree. The $IP_DIR path compile_ip.tcl needs to be adjusted to generated/ and the
   can be a dedicated tool script per key, e.g.:
   IP then gets generated in:
 
 
      qmegawiz_generate_ip --> qmegawiz_generate_ip.py
 
      qsys_generate_ip     --> qsys_generate_ip.py
 
 
      $RADIOHDL_BUILD_DIR//quartus//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:
 
 
 
      $RADIOHDL_BUILD_DIR//quartus//generated
 
 
   For generated IP that is kept in SVN that IP could still remain there.
   For generated IP that is kept in SVN that IP could still remain there.
 
 
   The hdllib.cfg should then also define a IP toolname subdirectory in build dir, eg.:
   The hdllib.cfg should then also define a IP toolname subdirectory in build dir, eg.:
 
 
     // = $RADIOHDL_BUILD_DIR/qsys        or
     $RADIOHDL_BUILD_DIR// = $HDL_BUILD_DIR/qsys        or
                                         $RADIOHDL_BUILD_DIR/megawizard
                                                        $HDL_BUILD_DIR/megawizard
 
 
   or more general $RADIOHDL_BUILD_DIR/ip?
   or more general $RADIOHDL_BUILD_DIR/ip?
   The $RADIOHDL_BUILD_DIR now has a modelsim and quartus subdir:
   The $RADIOHDL_BUILD_DIR now has a modelsim and quartus subdir:
 
 
      $RADIOHDL_BUILD_DIR//modelsim       -- made by modelsim_config.py using sim_tool_name from hdl_buildset_.cfg
      $RADIOHDL_BUILD_DIR//modelsim       -- made by modelsim_config.py using sim_tool_name from hdl_buildset_.cfg
      $RADIOHDL_BUILD_DIR//quartus        -- made by quartus_config.py using synth_tool_name from hdl_buildset_.cfg
      $RADIOHDL_BUILD_DIR//quartus        -- made by quartus_config.py using synth_tool_name from hdl_buildset_.cfg
 
 
   The IP can be put in a subdir using eg 'ip_tool_name' = quartus_ip:
   The IP can be put in a subdir using eg 'tool_name_ip' = quartus_ip:
 
 
      $RADIOHDL_BUILD_DIR//quartus_ip     -- made by quartus_config.py using a new ip_tool_name from hdl_buildset_.cfg
      $RADIOHDL_BUILD_DIR//quartus_ip     -- made by quartus_config.py using a new tool_name_ip from hdl_buildset_.cfg
 
 
   or can it be put in the synth_tool_name directory:
   or can it be put in the synth_tool_name directory:
 
 
      $RADIOHDL_BUILD_DIR//quartus
      $RADIOHDL_BUILD_DIR//quartus
 
 
   or do we need tool_name_megawizard and tool_name_qsys to be able to create:
   or do we need tool_name_megawizard and tool_name_qsys to be able to create:
 
 
      //
      $RADIOHDL_BUILD_DIR//
      $RADIOHDL_BUILD_DIR/unb1/megawizard     -- Altera MegaWizard
      $RADIOHDL_BUILD_DIR/unb1/megawizard     -- Altera MegaWizard
      $RADIOHDL_BUILD_DIR/unb1/qsys           -- Altera QSYS
      $RADIOHDL_BUILD_DIR/unb1/qsys           -- Altera QSYS
      $RADIOHDL_BUILD_DIR/unb1/coregen        -- Xilinx
      $RADIOHDL_BUILD_DIR/unb1/coregen        -- Xilinx
 
 
   Probably it is not so important whether the IP is generated by MegaWizard or Qsys, because that selection is
   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 hdl_buildset_.cfg both MegaWizard and Qsys can be regarded as
   already covered by the generate_ip.sh scripts. In the hdl_buildset_.cfg both MegaWizard and Qsys can be regarded as
   being part of the Quartus tool. Therefore using ip_tool_name provides sufficient distinction in IP build
   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 synth_tool_name build directory and then even
   sub directory. However the IP could also be generated into the tool_name_synth build directory and then even
   the ip_tool_name key is not needed, because the synth_tool_name sub directory also suits the Quartus IP
   the tool_name_ip key is not needed, because the tool_name_synth sub directory also suits the Quartus IP
   generation.
   generation.
 
 
 
   Assume that per IP HDL library there can only be one IP tool that generates the IP. This then implies that
 
   it is not necessary to distinghuis between megawizard and qsys per HDL library.
 
 
   Conclusion:
   Conclusion:
   - Using synth_tool_name = quartus is also sufficient/suitable to define the build subdirectory for IP generation.
   - Using synth_tool_name = quartus is also sufficient/suitable to define the build subdirectory for IP generation.
     Having a dedicate ip_tool_name could be nice, to more clearly see in the build tree which libraries have IP.
   - Use dedicated key per IP generation tool:
 
     . qmegawiz_generate_ip  --> generate in //
c) regression test script
     . qsys_generate_ip      --> generate in //
   * For pure HDL tests the modelsim_regression_test.py script can simulate VHDL test benches that are listed at
     so assume that multiple generated IP they can share the generated directory, this  is defined as an
     the 'regression_test_vhdl' key and report the result.
     option in the method that treats the *_generate_ip key, so it could be different per IP generation tool.
   * For Python test cases another key can be defined 'regression_test_py_hdl'. The values they may contain the entire command
   - Use --generate_ip option with quartus_config.py to generate the IP. This option looks for the *_generate_ip keys
     to run the Python test case with the HDL test bench. Note that the pure VHDL test benches could be perphaps also be
     and then executes them. Default this option is not used, because it the IP only needs t obe generated once.
     regarded as a special case of the Python MM - VHDL tests, ie. as a test without MM.
   - Generated IP that is kept in SVN could be copied to the build dir, and then treated as if it was generated.
   * Another bash or Python script that synthesises a set of designs to check that they still run through synthesis ok.
   - The sim files of the generated IP are used by Modelsim as well, via compile_ip.tcl, it is oke that these
 
     generated IP sim files are in the synth_tool_name dir.
d) multiple libRootDirs for finding hdllib.cfg files
   - Having a dedicate tool_name_ip could be nice, to more clearly see in the build tree which libraries have IP and
   The libRootDir is now defined via a the 'lib_root_dir' key in the hdl_buildset_.cfg.
     to bring them at a the same level as sim_tool_name and synth_tool_name.
   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. Support for multiple rootdirs needs to be implemented in
 
   common_dict_file.py because the results from all root dirs need to be in a common object.
 
 
 
e) Python peripherals
 
   The Python peripherals are still in the $UNB/Software/python/peripherals directory. At some time we need to move
 
   these also to RadioHDL. The peripherals could be located central again or local in a src/python directory. A first
 
   step can be to svn copy the $UNB/Software/python dir to ${RADIOHDL_WORK}/software/python to become independent of the
 
   $UNB tree. An intermediate scheme is also possible whereby the periperal is kept local but copied to a central
 
   build/python directory by means of a python_config.py script. The advantage of a central directory is that the periperals
 
   are grouped so that only a single Python search path is needed. The disadvantage of having a fixed central
 
   location in SVN is that peripherals that are application specific also need to be located there. Another option
 
   may be to use a synbolic link from a central directory to each local Python peripheral.
 
 
 
 
 
f) Improve support IP for multiple FPGA device types and Quartus tool versions
f) 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
The IP is FPGA type specific (because it needs to be defined in the Qsys source file) and tool version specific
Line 254... Line 361...
change it may not be necessary to upgrade, but for a major version change or for a device family type (eg. from
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
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
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:
Arria10 we now use Quartus 15.0 and device family of UniBoard2 v0 and the IP for that is kept in:
 
 
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10/
  $RADIOHDL/libraries/technology/ip_arria10/
 
 
This can be renamed in:
This can be renamed in:
 
 
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_15.0/
  $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
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:
to define the FPGA technology as a triplet:
 
 
  ip__device__quartus_
  ip__device__quartus_
 
 
A future version of the IP can be kept in:
A future version of the IP can be kept in:
 
 
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/
  $RADIOHDL/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/
 
 
The technology_pkg.vhd then gets;
The technology_pkg.vhd then gets;
 
 
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_14_1 = ...;
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_14_1 = ...;
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0 = ...;
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0 = ...;
Line 279... Line 386...
 
 
The hdllib.cfg of the specific technology IP library then has key (only one value):
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
  hdl_lib_technology = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
 
 
The hdl_buildset_.cfg can support multiple technologies eg. to be able to simulate a system with more than one FPGA that are
The hdl_buildset_.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):
of different technology (eg. an application with Uniboard1 and Uniboard2):
 
 
  technology_names = ip_stratixiv
  technology_names = ip_stratixiv
                     ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
                     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
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.
by hdl_config.py, so these IP libraries will not be build.
 
 
The build directory currently contains:
The build directory currently contains:
 
 
  //
  $RADIOHDL_BUILD_DIR///
 
 
This scheme is probably still sufficent to also support the FPGA technology as a triplet. However it may be necessary to rename the
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.
library key values in the IP hdllib.cfg to contain the full triplet information, so eg.
 
 
  hdl_lib_name = ip_arria10_fifo
  hdl_lib_name = ip_arria10_fifo
Line 303... Line 410...
then becomes:
then becomes:
 
 
  hdl_lib_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo
  hdl_lib_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo
  hdl_library_clause_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo_lib
  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 buildset, then all these versions can keep
this is a bit awkward. If only one Quartus version and only one device type are supported per buildset_name, 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.
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
Alternatively the hdllib_config.py could support multiple technology version IP libraries that use the same logical library name and use
clause.
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
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
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.
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.
 
 
 
 
g) Improve buildset scheme
g) Improve buildset_name scheme
 
 
The buildset defines the combination of Modelsim version and Quartus version. Currently there are buildsets 'unb1', 'unb2' and 'unb2a'. This
The buildset_name defines the combination of Modelsim version and Quartus version. Currently there are buildset_names 'unb1', 'unb2' and 'unb2a'. This
buildset scheme can be improved because:
buildset_name scheme can be improved because:
 
 
- for python they are defined by the hdl_buildset_.cfg, but for the run_* bash scripts they are defined in set_quartus,
- the buildset_names are tight to a board name 'unb1' (is that oke?) or should we use more general buildset_name names, or do we need a symbolic
  can they be defined in a common source (eg. base on hdl_buildset_.cfg set an environment variable and uses that for bash). The bash
  buildset_name names at all?
  script must then be ran from the same terminal as where the python config script was used to set the environment variable, because otherwise
- there is also a 'site' level in the bash scripts set_modelsim and set quartus (is that still needed?)
  the environment variable is not set or may not be correct.
 
- the buildsets are tight to a board name 'unb1' (is that oke?) or should we use more general buildset names, or do we need a symbolic buildset names at all?
 
- there is also a 'site' level in the bash scripts set_quartus (is that still needed?)
 
 
 
 
 
h) Declare IP libraries to ensure default binding in simulation.
h) Declare IP libraries to ensure default binding in simulation.
 
 
Currently the IP library is declared in the technology VHDL file e.g. like 'LIBRARY ip_arria10_ddr4_4g_1600_altera_emif_150;' in tech_ddr_arria10.vhd.
Currently the IP library is declared in the technology VHDL file e.g. like 'LIBRARY ip_arria10_ddr4_4g_1600_altera_emif_150;' in tech_ddr_arria10.vhd.
Line 337... Line 441...
Modelsim project file. This can be achieved adding the IP library to the modelsim_search_libraries key in the hdl_buildset_unb2.cfg. However the problem is
Modelsim project file. This can be achieved adding the IP library to the modelsim_search_libraries key in the hdl_buildset_unb2.cfg. However the problem is
then that if the IP library is not mapped to a directory then Modelsim will issue an error when it tries to search it.
then that if the IP library is not mapped to a directory then Modelsim will issue an error when it tries to search it.
--> For now keep the 'hdl_lib_include_ip' but only use it for synthesis. For simulation the 'hdl_lib_include_ip' is ignored. Which is fine because
--> For now keep the 'hdl_lib_include_ip' but only use it for synthesis. For simulation the 'hdl_lib_include_ip' is ignored. Which is fine because
    for simulation there is no need to exclude IP libraries.
    for simulation there is no need to exclude IP libraries.
 
 
 
 
 
 
101) More ideas
101) More ideas
 
 
a) zip scripts
a) zip scripts
   A zip script can gather all sources that are needed for a particular RadioHDL view point, eg.
   A zip script can gather all sources that are needed for a particular RadioHDL view point, eg.
 
 
Line 375... Line 477...
   # Loading ip_stratixiv_phy_xaui_lib.ip_stratixiv_phy_xaui_0(rtl)
   # Loading ip_stratixiv_phy_xaui_lib.ip_stratixiv_phy_xaui_0(rtl)
   # ** Fatal: Error occurred in protected context.
   # ** Fatal: Error occurred in protected context.
   #    Time: 0 fs  Iteration: 0  Instance: /tb_<...>//ip_stratixiv_phy_xaui_0_inst////// File: nofile
   #    Time: 0 fs  Iteration: 0  Instance: /tb_<...>//ip_stratixiv_phy_xaui_0_inst////// File: nofile
   # FATAL ERROR while loading design
   # FATAL ERROR while loading design
 
 
   Make sure that the StratixIV IP search libraries are defined by modelsim_search_libraries in the hdl_buildset_.cfg.
   Make sure that the StratixIV IP search libraries are defined by modelsim_search_libraries in the hdl_buildset_.cfg.
 
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.