OpenCores

/radiohdl_programmer_guide.md File deleted

/radiohdl_hdl_buildset_key_descriptions.md File deleted

/radiohdl_hdl_library_key_descriptions.md File deleted

/radiohdl_hdl_tool_quartus.md File deleted

/radiohdl_user_guide.vsdx Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream

radiohdl_user_guide.vsdx Property changes : Deleted: svn:executable ## -1 +0,0 ## -* \ No newline at end of property Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: configuration_file_classes.jpg =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: configuration_file_classes.jpg =================================================================== --- configuration_file_classes.jpg (revision 7) +++ configuration_file_classes.jpg (nonexistent)

configuration_file_classes.jpg Property changes : Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: radiohdl_work_flow.jpg =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: radiohdl_work_flow.jpg =================================================================== --- radiohdl_work_flow.jpg (revision 7) +++ radiohdl_work_flow.jpg (nonexistent)

radiohdl_work_flow.jpg Property changes : Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: raw_config_classes.jpg =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: raw_config_classes.jpg =================================================================== --- raw_config_classes.jpg (revision 7) +++ raw_config_classes.jpg (nonexistent)

raw_config_classes.jpg Property changes : Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: wave_tb_dp_repack_data.jpg =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: wave_tb_dp_repack_data.jpg =================================================================== --- wave_tb_dp_repack_data.jpg (revision 7) +++ wave_tb_dp_repack_data.jpg (nonexistent)

wave_tb_dp_repack_data.jpg Property changes : Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: radiohdl_hdl_tool_modelsim.md =================================================================== --- radiohdl_hdl_tool_modelsim.md (revision 7) +++ radiohdl_hdl_tool_modelsim.md (nonexistent) @@ -1,224 +0,0 @@ -# RadioHDL tool settings for Modelsim - ---- -#### Document history: -|Revision|Date|Author|Affiliation|Modification| -|:---|:---|:---|:---|:---| -|1.0|27 jan 2020|E. Kooistra|ASTRON |Created.| - ---- -#### Contents: -1 Introduction -1.1 Preconditions -2 Creating Modelsim project files -3 Using Modelsim -3.1 Starting the Modelsim GUI -3.2 Compiling the HDL -3.3 Simulating the HDL -3.4 Developing the HDL -4 Appendix: Configuration files -4.1 hdl_tool_modelsim.cfg -4.2 hdllib.cfg keys for Modelsim -5 Appendix: hdl_tool_modelsim.cfg - ---- -#### Terminology: - -- FPGA = Field Programmable Gate Array -- GUI = Graphical User Interface -- HDL = Hardware Description Language -- IP = Intellectual Property -- MPF = Modelsim Project File - ---- -#### References: -[1] radiohdl_user_guide.md -[2] radiohdl_hdl_library_key_descriptions.md - ---- -## 1 Introduction -The RadioHDL package consists of a set of scripts that interpret configuration files and that setup or run other tools for HDL code development [1]. This document describes how to use the following RadioHDL tools for compiling and simulating HDL code with Mentor/Modelsim: - -* **modelsim_config** : to create Modelsim project files (mpf) for simulation of HDL code -* **run_modelsim** : to start the Modelsim GUI and make and compile HDL code in Modelsim and hierarchically add signals to the Modelsim wave window - -### 1.1 Preconditions -Setup the RadioHDL environment as explained in [1]. - -The RadioHDL for Modelsim is configured using a hdl_tool_.cfg = hdl_tool_modelsim.cfg configuration file (see appendix), where the tool_name = modelsim is defined in a hdl_buildset_.cfg configuration file. Here assume we use the quick start example from [1], so with hdl_buildset_qs.cfg and hdl_tool_modelsim.cfg. The HDL source is grouped into one or more HDL libraries that are described by hdllib.cfg configuration files. - ---- -## 2 Creating Modelsim project files -The binaries for Modelsim are built in a separate directory tree under $RADIOHDL_BUILD_DIR. -Use modelsim_config to create the Modelsim project files (mpf) for all your HDL libraries. In this example the quick start buildset 'qs' is used: - -> \> modelsim_config -h -> \> modelsim_config qs - -The modelsim_config script puts the created files and copied files in the build directory, at: - -$RADIOHDL_BUILD_DIR/// - -> For 'buildset_name = qs' and 'sim_tool_name = modelsim' defined in hdl_buildset_qs.cfg this is at: - -> $RADIOHDL_BUILD_DIR/qs/modelsim - -The sub directories follow from the 'hdl_lib_name' key that is defined in the hdllib.cfg configuration files per HDL library. The modelsim_config script finds all hdllib.cfg files within 'lib_root_dirs = ${RADIOHDL_WORK}' that is defined in hdl_buildset_qs.cfg. The lib_root_dirs can list one or more search trees. - -Optionally you can clear this directory before running modelsim_config because everything is recreated: - -> \> rm -rf $RADIOHDL_BUILD_DIR/qs/modelsim - -If the HDL library dependencies change, e.g. because a new VHDL file is added to a library, or if a filename is changed, then it is necessary to rerun the modelsim_config. - -In addition to the Modelsim project files the modelsim_config also generates some auxiliary files that are used by commands.do in run_modelsim as quick reference to all HDL libraries. The central modelsim_project_files.txt at $RADIOHDL_BUILD_DIR/qs/modelsim/ contains a list of the paths to all HDL libraries. Per HDL library there is a _lib_order.txt file that contains a list of all HDL libraries that this HDL library depends on in order. - ---- -## 3 Using Modelsim - -### 3.1 Starting the Modelsim GUI - -To support your work inside Modelsim, RadioHDL comes with a **command.do** file that adds the following useful commands to the Modelsim Transcript command line window: - -* lp = load project -* mk = make project -* as = add signals to the wave window -* ds = delete signals from wave window - -To use these commands with your buildset start the Modelsim GUI with your buildset_name using run_modelsim: - -> \> run_modelsim qs & - -### 3.2 Compiling the HDL -First compile the dp_repack_data library and the libraries that it depends on.In the Modelsim Transcript window load Modelsim project file for HDL library dp_repack_data: -> ModelSim> lp dp_repack_data - -Report current library: -> ModelSim> lp - -Report all libraries in order that dp_repack_data depends on: -> ModelSim> lp all - -Compile all libraries in order that dp_repack_data depends on: -> ModelSim> mk compile all - -Compile only this dp_repack_data library: -> ModelSim> mk compile - -To load another HDL library project e.g. common_pkg, do: -> ModelSim> lp common_pkg - -Report all libraries in order that common_pkg depends on: -> ModelSim> lp all - -Instead of 'mk compile' one can use GNU 'make' for Unix (or make.exe on Windows) and Modelsim 'vmake' via the 'mk' command from **commands.do**. The advantage is that after an initial successful compile of all, any subsequent recompiles after editing a HDL source file only will require recompilation of the HDL source files that depend on it. - -Load Modelsim project file for HDL library dp_repack_data: -> ModelSim> lp dp_repack_data - -Clean build directories and makefiles in $RADIOHDL_BUILD_DIR that were made for dp_repack_data: -> ModelSim> mk clean all - -Make all libraries in order that dp_repack_data depends on and create the makefiles for those libraries: -> ModelSim> mk all - -To make only this dp_repack_data library do: -> ModelSim> mk - -To make only the specific common_pkg library do: -> ModelSim> mk common_pkg - -The first time 'mk all' is called the libraries are compiled and the library makefiles are made. The library makefiles are stored in the library build directories in $RADIOHDL_BUILD_DIR. It is important that all libraries compile OK, because otherwise the library makefiles are not created properly. Therefore if a library fails to compile, then load that library project with 'lp' and keep on doing 'mk compile' until the library compiles OK. Then when it compiles OK do 'mk clean' to clear the library build directory at $RADIOHDL_BUILD_DIR, and then do 'mk' or 'mk all' to compile the library again and create a proper makefile. Repeat this process until also the top level HDL library compiles OK. - -With the proper makefiles for all HDL libraries it is sufficient to use 'mk' to automatically recompile only the HDL source files that changed or that depend on the changed file. Similar with 'mk all' a change in some lower level library HDL file will only cause that the HDL files that depend on it will be recompiled. For a big project with many libraries using 'mk all' is much easier and faster to use than 'mk compile all'. Doing 'mk all' and again 'mk all' should show that the second 'mk all' did not need to recompile any HDL again. - -Note that the dp_repack_data library also depends on the common_pkg library. Therefore when doing the following: - -> ModelSim> lp common_pkg -> ModelSim> mk clean all -> ModelSim> mk all -> ModelSim> lp dp_repack_data -> ModelSim> mk all - -Then the 'mk all' in the dp_repack_data library will not recompile the libraries that were already compiled by the 'mk all' in the common_pkg library. Similar if you clean the common_pkg library while the dp_repack_data library project is loaded: - -> ModelSim> lp dp_repack_data -> ModelSim> mk clean common_pkg -> ModelSim> mk all - -Then the 'mk all' in the dp_repack_data library will recompile and recreate the makefile for the common_pkg library, and then reompile the HDL files in the higher libraries (up to dp_repack_data) that directly or indirectly depend on a HDL file in the common_pkg library. - -If a new VHDL file is added to a library or if a filename is changed, then it is necessary to rerun the modelsim_config and to do 'mk clean' on that library. It is important that Modelsim does not have that library open already, so either quit Modelsim first or 'lp' to another library first, before running modelsim_config. Typically it is not necessary to do 'mk clean all', nor is it necessary to delete the entire $RADIOHDL_BUILD_DIR library subdirectories. - -### 3.3 Simulating the HDL - -The simulation is done using a VHDL test bench (tb). These test bench files are made more recognizable by using the 'tb_' prefix. All HDL files that are listed at the test_bench_files key in the hdllib configuration file will have a simulation configuration icon in the Modelsim GUI. To simulate the tb_repack_data.vhd test bench in the dp_repack_data library do e.g.: - -> ModelSim> lp dp_repack_data -> Manually load simulation by double clicking the tb_repack_data icon in the Modelsim Project window - -Add all signals of 10 levels deep into of test bench hierarchy to the Wave Window: -> ModelSim> as 10 - -Run all until the test bench is done: -> ModelSim> run -a - -This tb_dp_repack_data.vhd test bench is self checking and self stopping. In the Wave window the signals can be observed visually, see Figure 1. - - -![Figure 1](./wave_tb_dp_repack_data.jpg "wave_tb_dp_repack_data.jpg") -Figure 1: Modelsim wave window with hierarchical signals view using 'as' command - -### 3.4 Developing the HDL - -Edit one of the VHDL source files or for example do: - -> \> touch $QS_DIR/cores/dp/dp_pkg/dp_stream_stimuli.vhd - -Then in Modelsim GUI: - -> ModelSim> mk all -> ModelSim> restart -f -> ModelSim> run -a - -The 'mk all' will only compile the touched files and the files that depend on it. The 'restart -f' cleans the wave window but preserves the viewed signal. The 'run -a' runs the simulation. - -The tb in the dp_repack_data library run as long as needed to apply the stimuli, and they are self checking. The tb_repack_data is instantiated into a multi test bench tb_tb_repack_data. By running this tb_tb_repack_data the entire dp_repack_data library gets verified in one simulation. - -To change project library using 'lp ' first the current active simulation needs to be closed using 'quit -sim'. To quit Modelsim entirely, without having to acknowledge the pop up do 'quit -f'. - ---- -## 4 Appendix: configuration files - -### 4.1 hdl_tool_modelsim.cfg - -This appendix describes the keys that are used in the hdl_tool_modelsim configuration file that is located in $RADIOHDL_GEAR/config. - -***model_tech_altera_lib*** -Defines the path to where the compiled component libraries of a certain Quartus version are stored. - - -### 4.2 hdllib.cfg keys for Modelsim - -This appendix describes the keys that are used in the [modelsim_project_file] section of the hdllib.cfg configuration file. Please see [2] for hdllib.cfg configuration file examples that use these Modelsim specific keys. - -***modelsim_copy_files*** -Copy listed all directories and files for simulation with Modelsim, used when tool_name_sim = modelsim in hdltool_.cfg. Can be used to eg. copy wave.do or data files from the source directory to the build directory where the Modelsim project file is. For data files that are read in VHDL the path within the build directory then becomes e.g. data/. - -***modelsim_compile_ip_files*** -This key lists one or more TCL scripts that are executed by the Modelsim mpf before it compiles the rest of the source code. E.g.: - -- compile_ip.tcl : a TCL script that contains external IP sources that are fixed and need to be compiled before the synth_files. For the Altera IP the compile_ip.tcl is derived from the msim_setup.tcl that is generated by the MegaWizard or Qsys [2]. -- copy_hex_files.tcl : a TCL script that is derived fromt yhe msim_setup.tcl and is used to copy ROM/RAM files initialization files from the generated IP directory to the simulation work directory. -- map_ip.tcl : a TCL script that maps a VHDL library name to another location (not use so far). - ---- -## 5 Appendix: hdl_tool_modelsim.cfg - -Tool configuration file for Mentor/Modelsim from $RADIOHDL_GEAR/config. -``` -# configuration file for defining the model installation on this system -model_tech_altera_lib = ${MODELSIM_ALTERA_LIBS_DIR}/${SYNTH_TOOL_VERSION} -``` - - Index: sd_export_variable.jpg =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: sd_export_variable.jpg =================================================================== --- sd_export_variable.jpg (revision 7) +++ sd_export_variable.jpg (nonexistent)

sd_export_variable.jpg Property changes : Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: radiohdl_hdl_buildset_uniboard1.md =================================================================== --- radiohdl_hdl_buildset_uniboard1.md (revision 7) +++ radiohdl_hdl_buildset_uniboard1.md (nonexistent) @@ -1,245 +0,0 @@ -# RadioHDL buildset for UniBoard1 - ---- -#### Document history: -|Revision|Date|Author|Affiliation|Modification| -|:---|:---|:---|:---|:---| -|1.0|27 jan 2020|E. Kooistra|ASTRON|Created.| - ---- -#### Contents: -1 Introduction -1.1 Scope -1.2 RadioHDL commands -2 Workflow -2.1 Preconditions -2.2 Setup RadioHDL -2.2.1 Source project settings -2.2.2 Source RadioHDL settings -2.3 Check the RadioHDL configuration -2.4 Create intermediate product files and project files -2.4.1 Compile standard Altera component libraries for Modelsim simulation -2.4.2 Pre-generate custom Altera IP blocks for simulation and synthesis -2.4.3 Create project files for simulation -2.4.4 Create project files for synthesis -2.4.5 Create an IP block design for a design library in your project -2.5 Simulate the HDL project -2.6 Synthesize the HDL project -3 Appendix: hdl_buildset_unb1.cfg - -#### References: -[1] radiohdl_user_guide.md -[2] A. Gunst, A. Szomoru, G. Schoonderbeek, E. Kooistra, D. van der Schuur, H. Pepping, "The application of UniBoard as a beam former for APERTIF", Experimental Astronomy, Volume 37, Issue 1, pp 55-67, February 2014, doi:10.1007/s10686-013-9366-x. -[3] radiohdl_hdl_tool_modelsim.md -[4] radiohdl_hdl_tool_quartus.md -[5] radiohdl_hdl_buildset_key_descriptions.md - ---- -# 1 Introduction - -## 1.1 Scope -The RadioHDL package offers scripts to ease and speed up HDL code development. The RadioHDL User Guide describes the general concept s of RadioHDL [1]. This RadioHDL for UniBoard1 user guide describes how to use RadioHDL for developing HDL applications on UniBoard1. The UniBoard1 [2] is an electronic board with 8 Altera Stratix IV FPGAs, that was developed by ASTRON and JIVE within the RadioNET FP7 program, - -This user guide serves as an advanced start example for other projects. It describes how RadioHDL is used for the UniBoard1 at ASTRON (2019) to develop HDL firmware from source code to working FPGA image. There is too much HDL code involved and too much dependency on vendor tools to make this example publicly available as a working example. For a publicly working example please try the quick start example from [1]. - -## 1.2 RadioHDL commands -The HDL development for UniBoard1 involves vendor tools from Mentor/Modelsim for simulation and Intel/Altera for synthesis. For this RadioHDL offers the following command line commands: - -* **check_config** to verify dependencies between hdl_buildset and hdl_tool configuration files -* **compile_altera_simlibs** to compile standard Altera component libraries for simulation with Modelsim -* **generate_ip_libs** to pre-generate customized IP components using Altera MegaWizard or Altera QSYS -* **modelsim_config** to create project files for Modelsim simulation -* **quartus_config** to create project files for Quartus synthesis -* **run_sopc** to generate a Altera SOPC memory mapped bus with NiosII -* **run_qsys** to generate a Altera QSYS memory mapped bus with NiosII -* **run_modelsim** to start Mentor Modelsim GUI for simulation -* **run_quartus** to start Altera Quartus GUI for synthesis -* **run_qcomp** to synthesize a top level design from the command line -* **run_rbf** to create an Altera FPGA rbf file from an FPGA sof file - -The scripts that start with 'run_' typically are bash scripts that invoke tools. The other scripts are typically Python3 scripts that manage the build directory tree and e.g. tool project files. Please see [3] and [4] for more information on how to use Modelsim and Quartus with RadioHDL. Please see [5] for hdllib.cfg configuration file examples that are used by **generate_ip_libs**, **modelsim_config** and **quartus_config**. - ---- -## 2 Workflow - -### 2.1 Preconditions - -RadioHDL uses Python3 and bash. Python3 is used to interpret the configuration files and to create target files, bash is used to setup and invoke tools. Install a version of: - -- Modelsim in $MENTOR_DIR/ (Modelsim version 6.6c or higher) -- Quartus in $ALTERA_DIR (version 11.1 for UniBoard1) - -and take care of all vendor specific environment variables in your own .bashrc or local .profile file. For example Altera and Modelsim needs the key LM_LICENSE_FILE to be defined. So the .bashrc file contains the lines: - -> export MENTOR_DIR= -> export ALTERA_DIR= -> export MODELSIM_ALTERA_LIBS_DIR= -> export LM_LICENSE_FILE= - - -### 2.2 Setup RadioHDL - -#### 2.2.1 Source Project settings -The UniBoard1 HDL source code is available in a source directory tree at hdl/. Setup RadioHDL development environment for a project at hdl/ using a corresponding init_hdl.sh. - -> \> cd /hdl -> \> . ./init_hdl.sh - -The init_hdl.sh defines: - -- RADIOHDL_WORK directory for where the source code resides -- RADIOHDL_BUILD_DIR directory for where the targets will be build - -The init_hdl.sh copies version controlled ${RADIOHDL_WORK}/hdl_user_components.ipx into the Altera dir's at $ALTERA_DIR//ip/altera/user_components.ipx. This Altera user_components.ipx contains the search paths that Altera SOPC builder and Altera QSYS use. - -> **NOTE:** Altera says that you can use your personal user_components.ipx file in ~/.altera.quartus/ip//ip_search_path for this kind of additional paths but tests show that this does not work for all tools of Altera. Therefore the user_components.ipx file is copied to the Altera installation directory. - -#### 2.2.2 Source RadioHDL settings - -The init_hdl.sh can automatically also source init_radiohdl.sh, or source these RadioHDL settings separately: - -> \> . /init_radiohdl.sh - -The init_radiohdl.sh from the RadioHDL package defines: - -- RADIOHDL_GEAR directory of where the init_radiohdl.sh is located -- RADIOHDL_BUILD_DIR = ${RADIOHDL_BUILD_DIR}/build if not already defined -- RADIOHDL_CONFIG = ${RADIOHDL_GEAR}/config if not already defined - -The init_radiohdl.sh extends: - -- PATH with ${RADIOHDL_GEAR}/core, ${RADIOHDL_GEAR}/quartus, ${RADIOHDL_GEAR}/modelsim -- PYTHONPATH with ${RADIOHDL_GEAR}/core, ${RADIOHDL_GEAR}/components - -### 2.3 Check the RadioHDL configuration - -The hdl_buildset_unb1.cfg defines the buildset 'unb1' for build target files for UniBoard1. Since there are some dependencies between the hdl_buildset configuration file and the hdl_tool configuration files there is a utility that checks (most) values in these files. To check the content of the file hdl_buildset_unb1.cfg and the hdl_tool_modelsim.cfg and hdl_tool_quartus.cfg files it refers to do - -> \> check_config unb1 - -Once the configuration files are correct you can start using the RadioHDL utilities. - - -### 2.4 Create intermediate product files and project files - -#### 2.4.1 Compile standard Altera component libraries for Modelsim simulation - -This only needs to be done once when a new version of Modelsim or new version of Quartus is used. - -> \> compile_altera_simlibs unb1 -- creates build/unb1/hdl_libraries_ip_stratixiv.txt -- creates build/quartus/ simulation models of Altera components that need to be moved manually using 'mv' or 'sudo mv' to $MODELSIM_ALTERA_LIBS_DIR/, because that is where Modelsim expects them. - -> **NOTE:** For Modelsim versions newer than about version10 this compile_altera_simlibs script must be used and not the tools/Launch simulation library compiler in the Quartus GUI, because the libraries have to be compiled with the 'vlib -type directory' option to be able to use 'mk all' in Modelsim. - -#### 2.4.2 Pre-generate custom Altera IP blocks for simulation and synthesis - -The custom IP needs to be generated before it can be simulated or synthesized. To make all custom IP libraries for the 'unb1' buildset do: - -> \> generate_ip_libs unb1 -- creates build/unb1/qmegawiz/ - -> **NOTE:** The Altera tools make use of the /tmp directory intensively. Unfortunately these tools do not cleanup the files they created there. We ran into major problems when working with more than one user on the same machine: -> 1. /tmp/compute_pll_temp and /tmp must have write-access for anyone (rwxrwxrwx) -> 2. run 'rm -rf /tmp/alt* /tmp/public*' before running generate_ip_libs - - -#### 2.4.3 Create project files for simulation - -> \> modelsim_config unb1 -- creates build/unb1/modelsim/ with Modelsim project files (mpf) for simulation -- creates build/unb1/modelsim/modelsim_project_files.txt for Modelsim commands.do, that lists all HDL libraries in their hierarchical order for compilation. -- creates build/unb1/modelsim/technology_select_pkg.vhd to select stratixiv technology for UniBoard1 - - -#### 2.4.4 Create project files for synthesis - -> \> quartus_config unb1 -- creates build/unb1/quartus/ with Quartus files for synthesis -- creates build/unb1/quartus/technology_select_pkg.vhd to select stratixiv technology for UniBoard1 - -The quartus_config creates the Quartus qpf, qsf for a top level design library and Quartus qip files all libraries. If a new VHDL file is added to a library or if a filename is changed, then it is necessary to rerun the quartus_config. Typically it is not necessary to do delete the entire $RADIOHDL_BUILD_DIR library of the design directory, but it can be necessary to make sure that Quartus is not 'confused' by obsolete files in that build directory. Make sure that any image files that needs to be kept are saved elsewhere, before deleting the build directory of the design library. - - -#### 2.4.5 Create an IP block design for a design library in your project - -Dependent of which tool you like to use you can run run_sopc (older) or run_qsys (newer) to generate the control interface of your design. - -> \> run_sopc unb1 unb1_minimal_sopc -- creates memory mapped bus block with NiosII master using Altera SOPC - -> \> run_qsys unb1 unb1_minimal_qsys -- creates memory mapped bus block with NiosII master using Altera QSYS - -Syntax: - -> run_qsys [] -> run_sopc [] - -Both utilities only differ in name not in functionality. The is a HDL library directory that needs to exist under $RADIOHDL_BUILD_DIR/${buildset}/quartus. If no respectively is specified during the invocation, then the utility will look for a file with the name .qsys or .sopc in the project directory. - -After generating all necessary files the utility will also build the software for the NiosII application using the RadioHDL run_app script. This run_app calls run_bsp and run_reg. The run_reg calls run_mif. For the FPGA designs on UniBoard the NiosII software application is fixed, because it implements the monitoring and control protocol interface between the 1GbE port and the memory mapped bus that is generated by SOPC or QSYS. The NiosII is the master on the memory mapped bus, and the slaves are configurable dependent on the design. - -> **NOTE:** The sopc_builder from Altera uses Java and Java expects that it is started from an Xterm (environment DISPLAY must be set) otherwise it stops with an error. - - -### 2.5 Simulate the HDL project - -To simulate test benches within the hdl project for UniBoard using the Modelsim GUI do: - -> \> run_modelsim unb1 & - -In simulation the entire unb1_minimal design can be simulated. The NiosII and memory mapped bus are not simulated. Instead the access to the memory mapped slaves is simulated using file IO. - -### 2.6 Synthesize the HDL project - -The way to start quartus is using the script **run_quartus**. This script sets up the environment variables that match the buildset and then start quartus itself. To synthesize a top level design within the hdl project for UniBoard using the Quartus GUI do: - -> \> run_quartus unb1 & - -To synthesize the unb1_minimal_sopc top level design from the command line do: - -> \> run_qcomp unb1 unb1_minimal_sopc - -To synthesize the unb1_minimal_qsys top level design from the command line do: - -> \> run_qcomp unb1 unb1_minimal_qsys - -The run_qcomp script can also rerun the synthesis for multiple seeds by using its --seed option. To translate the FPGA image sof file into an rbf file for use in a flash on UniBoard do: - -> \> run_rbf unb1 unb1_minimal_sopc -> \> run_rbf unb1 unb1_minimal_qsys - ---- -## 3 Appendix: hdl_buildset_unb1.cfg - -Buildset configuration file for Uniboard1 from $RADIOHDL_GEAR/config. -``` -buildset_name = unb1 -technology_names = ip_stratixiv -family_names = stratixiv -block_design_names = sopc - -synth_tool_name = quartus -synth_tool_version = 11.1 -sim_tool_name = modelsim -sim_tool_version = 6.6c - -lib_root_dirs = ${RADIOHDL_WORK}/libraries - ${RADIOHDL_WORK}/applications - ${RADIOHDL_WORK}/boards - -[quartus] -quartus_dir = ${ALTERA_DIR}/ - -[modelsim] -modelsim_dir = ${MENTOR_DIR}//modeltech -modelsim_platform = linux_x86_64 -modelsim_search_libraries = - # stratixiv only - altera_ver lpm_ver sgate_ver altera_mf_ver altera_lnsim_ver - stratixiv_ver stratixiv_hssi_ver stratixiv_pcie_hip_ver - altera lpm sgate altera_mf altera_lnsim stratixiv stratixiv_hssi - stratixiv_pcie_hip -``` - Index: radiohdl_user_guide.md =================================================================== --- radiohdl_user_guide.md (revision 7) +++ radiohdl_user_guide.md (nonexistent) @@ -1,324 +0,0 @@ -# RadioHDL User Guide - -### *Speed up HDL development* - ---- -#### Document history: -|Revision|Date|Author|Affiliation|Modification| -|:---|:---|:---|:---|:---| -|0.5|11 dec 2018|R. Overeem |ASTRON|Initial HDL user manual docx.| -|1.0|27 jan 2020|E. Kooistra|ASTRON|Created, based on HDL user manual docx and hdltool_readme.txt.| - ---- -#### Contents: -1 Introduction -2 Quick start using simulation in Modelsim -2.1 Preconditions -2.2 Setup RadioHDL -2.3 Create Modelsim Project files -2.4 Simulate the HDL test bench in Modelsim -2.5 Utilities -2.5.1 check_config -2.5.2 modify_configfiles -3 Setting up the RadioHDL environment -3.1 Environment variables -3.2 Configuration files kinds -3.2.1 hdl_buildset_.cfg -3.2.2 hdl_tool_.cfg -3.2.3 hdllib.cfg -4 RadioHDL concepts and features -4.1 Clean enviroment -4.2 Copy files -4.3 Top level design library -4.4 Design revisions -5 Adding your own tools -5.1 New hdl_tool_.cfg file -5.2 New directory -5.3 Extend generate_ip_libs -6 Appendix: RadioHDL configuration file schema basics - ---- -#### Terminology: - -- FPGA = Field Programmable Gate Array -- GUI = Graphical User Interface -- HDL = Hardware Description Language -- IP = Intellectual Property -- MPF = Modelsim Project File - ---- -#### References: -[1] radiohdl_hdl_buildset_key_descriptions.md -[2] radiohdl_hdl_buildset_uniboard1.md -[3] radiohdl_hdl_tool_modelsim.md -[4] radiohdl_hdl_tool_quartus.md -[5] radiohdl_hdl_library_key_descriptions.md -[6] radiohdl_programmer_guide.md - ---- -## 1 Introduction -The RadioHDL package offers tools for setting up, automating and maintaining the HDL source code, IP code and tools for programming FPGAs. The RadioHDL package consists of a set of scripts that interpret configuration files and that setup or run other tools. Currently RadioHDL supports vendor tools like Modelsim and Quartus, but other vendor tools can be added easily to the package. - -The parameters for the HDL source libraries, the vendor IP blocks, the build tools and the target FPGA are kept in configuration files. The configuration files and source files are the inputs for the RadioHDL tools. The output is a build target that depends on which build tool is used. The build target can e.g. be a project file for Modelsim to simulate the HDL, a project file for Quartus to synthesize the HDL, a report log from a regression test that simulated the HDL. Figure 1 shows how RadioHDL fits in the build flow from source to target. The configuration files and source files are kept in one or more source directory trees that can be under version control, while the target files are built in a separate build directory tree. The RadioHDL is configured using three different kinds of configuration files: - -- one central hdl_buildset_.cfg configuration file per set of FPGA technology and tools and tool versions, -- one central hdl_tool_.cfg configuration file per vendor tool, -- multiple local hdllib.cfg configuration files, one per HDL library. - -After setting up the configuration files for the tools and the source files, RadioHDL can create for the selected buildset all libraries for simulation, create all IP libraries, find out dependencies, generate project files and do a lot more of these labour-intensive tasks automatically. - -![Figure 1](./radiohdl_work_flow.jpg "radiohdl_work_flow.jpg") -Figure 1: RadioHDL flow from source to target - -The main benefit of RadioHDL is that it speeds up HDL development by providing a uniform and automated way of using tools and building code. The disadvantage of using RadioHDL is that it requires an initial effort to support a vendor tool and to maintain this support with changes in vendor tool versions. However in practice it has appeared worth the effort to use and maintain RadioHDL. - -RadioHDL is open source, see [LICENSE.md](../LICENSE.md). The name RadioHDL reflects that it was first used for HDL development in FPGA projects for radio astronomy, see [NOTICE.md](../NOTICE.md) and [CREDITS.md](../CREDITS.md), but it can be applied for any HDL development project. This user guide focusses on how to use RadioHDL. The internal working of the RadioHDL scripts is described in the RadioHDL gear programmer guide [6]. - ---- -## 2 Quick start using simulation in Modelsim - -This quick start uses the following RadioHDL tools for Mentor/Modelsim: - -* **modelsim_config** : to create Modelsim project files (mpf) for simulation of HDL code -* **run_modelsim** : to start the Modelsim GUI and make and compile HDL code in Modelsim and hierarchically add signals to the Modelsim wave window - -See [1] for more detailed information on using RadioHDL with Modelsim. -See [2] for more a more advanced example of using RadioHDL with Modelsim and Quartus, so including synthesis - - -### 2.1 Preconditions - -RadioHDL uses Python3 and bash. Python3 is used to interpret the configuration files nad to create target files, bash is used to setup and invoke tools. - -Install a version of Modelsim in $MENTOR_DIR/ (version 6.6c and 10.4 and Questasim have been used) and take care of all vendor specific environment variables in your own .bashrc or local .profile file. For example Altera and Modelsim needs the key LM_LICENSE_FILE to be defined. So the .bashrc file contains the lines: - -> export MENTOR_DIR= -> export LM_LICENSE_FILE=: - -### 2.2 Set up RadioHDL - -Create a directory at some location $QS_DIR to store the quick start (QS) example. Copy the example init_qs.sh from the RadioHDL installation directory to $QS_DIR and download the common_pkg, dp_pkg and dp_repack_data HDL libraries from OpenCores and put them in $QS_DIR. - -> ls -$QS_DIR/init_qs.sh -$QS_DIR/cores/common/common_pkg -$QS_DIR/cores/dp/dp_pkg -$QS_DIR/cores/dp/dp_repack_data - -Source init_qs.sh from within $QS_DIR to set the RadioHDL environment variables RADIOHDL_WORK and RADIOHDL_BUILD_DIR for the quick start (qs) project. - -> \> . ./init_qs.sh - -The example hdl_buildset_qs.cfg in the RADIOHDL_GEAR/config directory of RadioHDL installation directory defines which Modelsim version should be used. The sim_tool_version key in the hdl_buildset_qs.cfg defines the subdirectory of the installation of the Modelsim simulation tool in $MENTOR_DIR. In the example hdl_buildset_qs.cfg the sim_tool_version = 6.6c, indicating that the Modelsim tool version is installed at $MENTOR_DIR/6.6c/. If necessary change this to your sim_tool_version = and $MENTOR_DIR/. - -Source init_radiohdl.sh to create $RADIOHDL_GEAR that points to and to add search paths within $RADIOHDL_GEAR to $PATH and to $PYTHONPATH - -> \> . .//init_radiohdl.sh - -Now the environment variables that are important for using RadioHDL and that are also depicted in Figure 1) have been defined. - -### 2.3 Create Modelsim project files - -Use RadioHDL to build Modelsim simulation project files (*.mpf) for the quick start HDL libraries - -> \> modelsim_config qs - -The modelsim_config script puts the created files and copied files in the build directory, at: - -> $RADIOHDL_BUILD_DIR/qs/modelsim - -### 2.4 Simulate the HDL test bench in Modelsim - -Start the Modelsim simulation GUI using: - -> \> run_modelsim qs & - -The run_modelsim also sources a commands.do script in Modelsim that adds the following -useful Modelsim Transcript command line commands: - -* lp = load project -* mk = make project -* as = add signals hierarchically to the wave window -* ds = delete signals from wave window - -To compile the HDL code do in the Modelsim Transcript window: - -> ModelSim> lp dp_repack_data -> ModelSim> mk all - -To simulate the HDL code first double click tb_dp_repack_data icon in the Modelsim Project window to load the test bench (tb) into the simulator and then in the Modelsim Transcript window do. - -> ModelSim> as 10 -> ModelSim> run -a - -The signals in this tb_dp_repack_data.vhd test bench can be observed visually in Modelsim Wave window, see Figure 2. - -![Figure 2](./wave_tb_dp_repack_data.jpg "wave_tb_dp_repack_data.jpg") -Figure 2: Modelsim wave window with hierarchical signals view using 'as' command - -### 2.5 Utilities - -### 2.5.1 check_config -The utility **check_config** checks key-value dependencies between the hdl_buildset configuration file and the hdl_tool configuration files. - -### 2.5.2 modify_configfiles -The utility **modify_configfiles** implements a tiny menu system that enables you to add, remove or change keys in all hdllib.cfg files of a certain buildset. - ---- -## 3 Setting up RadioHDL environment - -### 3.1 Environment variables - -The following environment variables are important for RadioHDL: - -* RADIOHDL_GEAR : Points to the main directory where your checked out the RadioHDL package. This is the location where this init_radiohdl.sh file is located. Do not change this variable. -* RADIOHDL_BUILD_DIR : Points to the directory where RadioHDL will store all its result files. If this variable is not already set when init_radiohdl.sh is run, then it will be set to point to $RADIOHDL_WORK/build. -* RADIOHDL_CONFIG : Points to the directory where RadioHDL expects the hdl_buildset and hdl_tool configuration files. If this variable is not already set when init_radiohdl.sh is run, then it will be set to point to $RADIOHDL_GEAR/config. -* RADIOHDL_WORK : Points to the root directory of the your project that will use RadioHDL. - - -### 3.2 Configuration files kinds - -The configuration files define key-value pairs, see the appendix for the details of the schema. There are three different kinds of configuration files in RadioHDL. The hdl_buildset configurations file and hdl_tool configuration file are central and define the global keys that hold for the whole HDL project. The hdllib configuration files define keys that apply per HDL library. The key values from the hdl_buildset configuration file can be used in the hdllib configuration files by referring to the hdl_build set key as . An HDL project in RadioHDL typically targets a certain FPGA board and has an hdl_buildset configuration file for that board. The hdl_buildset configuration file identifies the hdl_tool configuration files for the tools that are needed to build HDL and it points to the directory tree(s) that contain the HDL libraries that are needed for the HDL application(s) that can run on the FPGA board. - - -#### 3.2.1 hdl_buildset_.cfg - -An hdl_buildset_.cfg configuration file defines the combination of FPGA type, tools, IP libraries and versions that are needed to build a target. The buildset_name is used as command line option in RadioHDL scripts to identify the buildset. The buildset_name is typically an abbreviation that identifies the target FPGA board hardware and a version, e.g. 'unb1' for a version 1 of an FPGA board called 'UniBoard'. If the same board is used, but with another set of tool versions, then that could be identified by e.g. 'unb1_a' and have a buildset file called hdl_buildset_unb1_a.cfg. The hdl_buildset configuration files are kept centrally at $RADIOHDL_CONFIG. To structure the hdl_buildset configuration file it can be divided into sections that group keys per included tool. The section headers are identified between square brackets [tool_name] - -#### 3.2.2 hdl_tool_.cfg - -RadioHDL looks for '*_tool_name' keys in the hdl_buildset configuration file to find the tool names that the buildset uses for e.g. simulation and synthesis. In this way RadioHDL knows which hdl_tool_ configuration file it needs to use to setup these tools. Typically there is one tool configuration file that covers multiple versions of that tool. The hdl_tool configuration files are kept centrally at $RADIOHDL_CONFIG. - -Although most keys in a hdl_tool configuration file are tool specific, there are some keys RadioHDL will always search for in a hdl_tool configuration file. RadioHDL will always search for keys ending in '_paths' and '_environment_variables' for keys that begin with: - -- the tool_name of that hdl_tool configuration file (e.g. quartus_paths and quartus_environment_variables) -- the block_design_names you mentioned in your hdl_buildset configuration file (e.g. sopc, qsys) -- the word 'user', so you can always add your own paths and environment variables with the keys user_paths and user_environment_variables. - -#### 3.2.3 hdllib.cfg - -The HDL code is organised in one or more (can be many) HDL libraries. Each HDL Library has a local hdllib.cfg configuration file that defines the sources and supported tools. All HDL files are grouped into libraries. The rule is that each HDL file is compiled in only one HDL library. If a component is used in another library, then it is instantiated in VHDL using ., where the hdl_library_clause_name is defined in the hdllib.cfg. Although the creation of these hdllib.cfg files may take some time, you will definitely save time on the long run. An HDL library can define a: - -* module library with HDL that is reused in other libraries -* top level library with a top level entity that maps on the IO of the FPGA. - -For RadioHDL there is no difference in HDL libraries. A top level library that is used for synthesis has a synth_top_level_entity key. RadioHDL search for all hdllib.cfg files in the directory tree(s) that are specified by the lib_root_dirs key in the hdl_buildset configuration file. Typically the hdllib configuration points to sources that are located in the same directory as where the hdllib.cfg is located or in its sub directories, however relative or absolute paths to sources elsewhere are also allowed. - -The hdllib can distinguish between source HDL that can be synthesized (at synth_files key), HDL code that is used only in test benches for simulation (at test_bench_files key) and test benches that are selected to be part of a simulation regression test (at regression_test_vhdl key).. - -The hdllib.cfg files are used by many utilities from the RadioHDL package. To structure the hdllib.cfg file, it can be divided into sections that group keys that are used for a specific target. The section headers are identified between square brackets [target_name]. The first part of an hdllib.cfg file has no section header as these keys are available for all target scripts. The keys within a section are applicable to the corresponding tool script. For example: - -- section [modelsim_project_file] contains key-value pairs for modelsim_config -- section [quartus_project_file] contains key-value pairs for quartus_config -- section [generate_ip_libs] contains key-value pairs for generate_ip_libs - -Future target scripts can have their own [target_name] header in the hdllib.cfg to keep the files more organised. - ---- -## 4 RadioHDL concepts and features - -### 4.1 Clean environment - -The RadioHDL settings are only active in the terminal where RadioHDL was started. Therefore it is possible to run different buildsets in different terminals on the same machine. When the terminal is closed, then also all RadioHDL settings vanish as well. - -### 4.2 Copy files - -RadioHDL has _copy_files keys that can be used to copy files from the source directory tree to anywhere in the build directory tree. The file may also be copied to multiple locations in the build tree. This can be useful if different tools need the same source file, but at different locations. - -A file may also be copied to another file. This can be useful to keep several variants of a file in the source tree, but only use one variant with a fixed filename in the build tree. The hdllib.cfg configuration can then refer to the file in the build tree. - -### 4.3 Top level design library - -A synth_top_level_entity key in the hdllib.cfg of an HDL library indicates that the HDL library is a design library that can be synthesized to yield an FPGA image. A design library should not depend on another design library, because then there may occur conflicting or double design constraints for Quartus. Therefore it is not advised to directly use VHDL from a design library in other libraries. A proper solution is to put these VHDL files in a separate library and then use them from that library. Another solution (i.e. work around) is to break the rule that an HDL file should only be compiled once in one library and then also compile it in the design library that needs to reuse it. - -### 4.4 Design revisions - -A design in this context is a top level entity in a HDL library that can be synthesized to create a FPGA image that can run on an FPGA. Within a design, several design revisions can be made that all use the same HDL source code from the base design, but with different generic settings at the top level entity. To keep these design revisions separate, add a directory 'revisions/' in the base design directory, which contains a list of subdirectories. Each subdirectory is a revision. The base design 'unb1_minimal' can be uses as an example: - -> designs/unb1_minimal/hdllib.cfg -> designs/unb1_minimal/revisions/unb1_minimal_sopc/hdllib.cfg -> designs/unb1_minimal/revisions/unb1_minimal_qsys/hdllib.cfg - -The base design library unb1_minimal/hdllib.cfg contains the source code. Each design revision library also has a hdllib.cfg file and a top level VHDL file that wraps the top level VHDL file from unb1_minimal. The wrapper file makes the generic settings for the specific revision. In addition it is useful to specify a 'g_design_name' generic that can be used to store a string in the FPGA that can be read out to know which design revision runs on the FPGA. In this example for UniBoard1 the 'g_design_name' for the revisions is 'unb1_minimal_qsys' or 'unb1_minimal_qsys'. - -When a design library has revisions, then the base library should not include keys for synthesis. Instead the synthesis is only done for the revisions. The base library contains all the VHDL source files. The revision hdllib.cfg should not refer to these base library VHDL files (i.e. using a relative path via ../../), but instead it should instantiate the top level base entity using the base design library name. This to follow the rule that a HDL file is only compiled in one HDL library. - ---- -## 5 Adding your own tools - -The RadioHDL package as described in this user guide is based on the tools Modelsim and Quartus. If you are using the same tools, then everything should work in your environment after you checked/modified the configuration files in $RADIOHDL_CONFIG. But what if you are using others tool like e.g. Xilinx Vivado? In that case you have to create some new configuration files, some directories and (unfortunately) extend one script. This chapter guides you through this process. - -### 5.1 New hdl_tool_.cfg file - -Assume you want to add Vivado to RadioHDL, then create in $RADIOHDL_CONFIG a file named hdl_tool_vivado.cfg and put in that file Vivado specific paths and environment variables. There are no required keys in configuration files of the type hdl_tool, so you are free to choose your own key names. Note: the script you create in the following section uses the definitions you create in the hdl_tool file. - -### 5.2 New directory - -Every tool has its own directory in $RADIOHDL_GEAR. In this directory we expect a script named set_ to be present, that accepts the buildset_name as an argument. That script sets up the whole environment, so that the tool can be used, e.g. extend paths, setup environment variables, etc. Look in e.g. set_modelsim and set_quartus how to get access to the information that is stored in your configuration files in the $RADIOHDL_CONFIG. So to add e.g. to add Vivado: - -- create a directory $RADIOHDL_GEAR/vivado -- inside this directory make a script set_vivado that sets up the Vivado environment using the information that is configured in the hdl_buildset and hdl_tool files. - -### 5.3 Extend generate_ip_libs - -Currently generate_ip_libs supports three IP generation tools from Altera: qmegawiz, qsys-generate and quartus_sh. These IP tools are configured in the hdl_tool_quartus.cfg file (key ip_tools) and implemented as special functions in generate_ip_libs. If you need different IP generation tools you should add them to the ip_tools key and add an extra function in generate_ip_libs. This generate_ip_libs script is the one place (left) where tool specific code is part of a RadioHDL script. In a future release of RadioHDL this should be solved in a more generic way, but for now you have to add a function to generate_ip_libs, when you are using a tool other than qmegawiz, qsys-generate or quartus_sh for creating your IP libraries. - -The main flow of generate_ip_libs is: - -- read the hdl_buildset file of the buildset you started the program with. -- search for hdllib.cfg files in all directories mentioned in the key lib_root_dirs -- read the hdl_tool_.cfg file where tool_name is the value of the key synth_tool_name in your buildset file. -- read the value of the key ip_tools in this hdl_tool file which is a list of tools you use for creating the IP libraries. Each of these ip_tools have their own _default_options key to configure the default options of that command. -- finally it loops over all buildset.technology_names, all tool.ip_tools and all hdllibs that where read in, to see if there is a match in technology and ip_tool with the information in the hdllibs. -- for each match found in these nested loops it calls a function called run_ that is part of the generate_ip_libs program. - -So if you are using other ip_tools then the three mentioned above you have to add a run_ function to generate_ip_libs and extend the if-then-else construction in the main loop with a call to that function. And you have to setup your configuration files in the right way of course. Take a look at the other run_ functions in generate_ip_libs for what to implement. Basically it constructs a shell script that runs the IP tool and analyses the exit-code of the execution. No rocket science. - ---- -## 6 Appendix: RadioHDL configuration file schema basics - -A RadioHDL configuration file is a collection of key-value pairs. Key and value are separated with the assignment char '='. Everything after (and including) a '#' char till the end of the line is treated as comment and is skipped in the interpretation of the files. -``` - this_is_a_key = and this is the value # except for this comment. -``` -The files can be divided into sections. A section marker is a line that starts with '[', contains a string and ends with ']'. Sections can be used to group keys that are only used by certain tool scripts and may be ignored by other tool scripts. Key names in different sections must still be unique in the entire configuration file. -``` - [start of a new section] - key = value -``` -To make the files easier to read and maintain for humans each value can be defined in more than one line where spacing is trivial. This makes is easy to define values that consist of more than one item. Actually, the concept of 'value' is implemented as 'being everything between the assignment char and the start of the next key or the start of a section. Newline characters are translated into a single space. -``` - invitationlist = John & Marry, - Robert, - Sandra and Naomi, -``` -This is equivalent with: -``` - invitationlist = John & Marry, Robert, Sandra and Naomi, -``` -You can use environment variables in values: -``` - lib_root_dirs = ${RADIOHDL_WORK} -``` -Keys are always in lowercase even when the name of the key will be used as environment variable. RadioHDL takes care that the key names are converted to uppercase in these cases. - -You can refer to a value of another key by placing the name of that key between '<' and '>'. Key word substitution can happen local within a file or global between files: - -- Local: A key name can be used for key value substitution in other key values within the same cfg file at . -- Global: A key name in the hdl_buildset cfg file can be used to substitute in key values in hdllib cfg files: e.g. - -For example: -``` - tool_name = quartus - tool_version = 12.3 - tool_location = /home/software/\/\/bin -``` - -Key values can be e.g.: - -* Single value : e.g 'hdl_lib_name' key -* List of values : e.g. 'synth_files' key -* List of value pairs : e.g '*_copy_files' key - -The pairs in '*_copy_files' are separated by a space and therfore the values can not contain a space. Index: HDL User manual.docx =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDL User manual.docx =================================================================== --- HDL User manual.docx (nonexistent) +++ HDL User manual.docx (revision 4)

HDL User manual.docx Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: HDL User manual.pdf =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDL User manual.pdf =================================================================== --- HDL User manual.pdf (nonexistent) +++ HDL User manual.pdf (revision 4)

HDL User manual.pdf Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: HDL programmers manual.docx =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDL programmers manual.docx =================================================================== --- HDL programmers manual.docx (nonexistent) +++ HDL programmers manual.docx (revision 4)

HDL programmers manual.docx Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: HDL programmers manual.pdf =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDL programmers manual.pdf =================================================================== --- HDL programmers manual.pdf (nonexistent) +++ HDL programmers manual.pdf (revision 4)

HDL programmers manual.pdf Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: HDLgear overview.pptx =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDLgear overview.pptx =================================================================== --- HDLgear overview.pptx (nonexistent) +++ HDLgear overview.pptx (revision 4)

HDLgear overview.pptx Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: HDLgear.eap =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: HDLgear.eap =================================================================== --- HDLgear.eap (nonexistent) +++ HDLgear.eap (revision 4)

HDLgear.eap Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: hdltool_readme.txt =================================================================== --- hdltool_readme.txt (revision 7) +++ hdltool_readme.txt (revision 4) @@ -1,357 +1,250 @@ -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: +g) Tool start scripts -1) Introduction +The definitions for actually running Modelsim and Quartus are not kept in the ~/.bashrc file or the setup script but are +set in a tool start script: -2) Tool environment setup - l) UniBoard2 device family - m) Upgrading the IP for new version of Quartus or for another device family - -3) HDL environment configuration files - b) Target configuration scripts - c) hdl_buildset_.cfg key sections - -9) RadioHDL directory structure - a) applications - b) boards - c) libraries - d) software - e) tools - f) sub directories - -100) To do - b) Generate Quartus IP key - f) Improve support IP for multiple FPGA device types and Quartus tool versions - g) Improve buildset_name scheme - h) Declare IP libraries to ensure default binding in simulation. - -101) More ideas - a) zip scripts - b) support dynamic generation of IP - c) Link RadioHDL developments with the OneClick MyHDL developments. - -102) Know errors + ${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: -2) Tool environment setup -l) UniBoard2 device family + - 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 -The device family of the Arria10 on UniBoard2 v0 is 10AX115U4F45I3SGES as can be seen at the photo of the FPGA: - $RADIOHDL/boards/uniboard2/libraries/unb2_board/quartus/unb2_board_v0_device_family.JPG + +i) How to start Quartus for RadioHDL -The device family is used in: -- $RADIOHDL/boards/uniboard2/libraries/unb2_board/quartus/unb2_board.qsf -- QSYS IP component files -- QSYS system design file +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 -m) Upgrading the IP for new version of Quartus or for another device family +j) How to start Modelsim for UNB -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: +GUI: - 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 + > unb_msim & # for UNB + > aaf_msim & # for AARTFAAC + > paasar_msim & # for PAASAR -In addition several other files need to be modified to be able to simulate the IP: +See the setup_unb.sh environment script and ASTRON_RP_1354_unb_minimal.pdf for more description. - - 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: +n) How to use RadioHDL for Lofar RSP - 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 +* The Lofar Station firmware is kept in a separate SVN repository at: + + https://svn.astron.nl/Station -Then run generate-all-ip.sh and try to simulate the test benches that verify the IP: + 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 - - tb_eth - - tb_tr_10GbE - - tb_io_ddr + 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: -and the try to simulate a design, eg.: + The compxlib adds the Xilinx libraries to the [libraries] section in the + /home/software/Mentor/6.6c/modeltech/modelsim.ini file. Therefore make + sure to first copy this original installation modelsim.ini file, so that + we can restore it. + + cd /home/software/modelsim_xilinx_libs/ise/10.1.03 + sudo mkdir vhdl + sudo mkdir verilog + 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 + 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 - - unb2_minimal + Use the library mappings in the modelsim.ini that was modified by compxlib + to create: + tools/ise/create hdl_libraries_ip_virtex4.txt + + The modelsim_config.py using hdl_libraries_ip_virtex4.txt to map the Xilinx + library files in each HDL library project files. Therefore the central + 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' -3) HDL environment configuration files +* Create bash scripts to start up ISE based on the buildset 'rsp' in tools/ise: + run_ise + \--> set_ise + \--> ise_version.sh + \--> ise_generic.sh + + This is similar as for other tools like Modelsim, Quartus. The advantage of + this approach is that the tool settings are only made when the tool is ran + and not in the .bashrc file. These bash scripts are kept in SVN and thus the + same tool settings are used by all engineers. -b) Target configuration scripts +* Add 'rsp' buildset for Modelsim and ISE versions to tools/modelsim/set_modelsim. + +* To start the ISE GUI do: + > run_ise rsp & + +* To start the Modelsim GUI do: + > run_modelsim rsp & - t3. verify VHDL test benches in simulation - modelsim_regression_test_vhdl.py -c) Replace SOPC avs2_eth_coe instance - -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 -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. - -Make sure that the user_component.ipx is set up oke (see point 2e), because that is needed for SOPC to -find the new avs2_eth_coe in $RADIOHDL. +3) HDL environment configuration files - -9) RadioHDL directory structure +d) hdl_buildset_.cfg key descriptions -Currently, the RadioHDL SVN repository is contained within the UniBoard_FP7 SVN repository, at the following URL: +- 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 -https://svn.astron.nl/UniBoard_FP7/RadioHDL/trunk +- project_dir_depth_synth = + Same purpose as project_dir_depth_sim, but for synthesis project file location in build tree. -The above location might change in the future. + -The following sections describe the subdirectories that exist. +5) Build directory location -a) applications//designs//revisions/ - /quartus - /src - /tb - libraries/ - - . Contains firmware applications designs, categorized by project. +The Modelsim and Quartus build location central outside the $HDL sources directory tree, whereby the +subdirectory names are defined by the corresponding keysin the hdl_buildset_.cfg: -b) boards/ - /uniboard2a/designs/unb2a_led/quartus - src - tb - /libraries/unb2a_board/quartus - src - tb + ${RADIOHDL_BUILD_DIR}// + +eg. - . 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 + ${RADIOHDL_BUILD_DIR}/unb1/modelsim/common + +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 +time though. -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. +100) To do -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 +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 The generate_ip.sh scripts for generating the MegaWizard or QSYS IP components in fact are merely a wrapper script - around the 'qmegawiz' and 'qsys-generate' commands. The generate_ip.sh may seem 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. + around the qsys-generate command. The generate_ip.sh may seem 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. However 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: - A disadvantage of the generate_ip.sh is that currently they use a fixed selection of the buildset_name, so they do not use - the -t argument. An 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. Another advantage is that - the generate_ip.sh can call 'qmegawiz' or 'qsys-generate' multiple time and with lots of arguments. Without - 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 + quartus_copy_files = + generate_ip.sh + _.qsys + quartus_generate_ip = generate_ip.sh - qsys_generate_ip = filename - The 'quartus_copy_files' key is used to copy the IP generation source file and the generation script to the - build directory. + 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: - The '*_generate_ip' key identifies the tool script that needs to be ran when the IP has to be generated. The toolscript - can be a dedicated tool script per key, e.g.: + $RADIOHDL_BUILD_DIR//quartus//generated - qmegawiz_generate_ip --> qmegawiz_generate_ip.py - qsys_generate_ip --> qsys_generate_ip.py - - 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. - The hdllib.cfg should then also define a IP tool name subdirectory in build dir, eg.: + The hdllib.cfg should then also define a IP toolname subdirectory in build dir, eg.: - $RADIOHDL_BUILD_DIR// = $HDL_BUILD_DIR/qsys or - $HDL_BUILD_DIR/megawizard + // = $RADIOHDL_BUILD_DIR/qsys or + $RADIOHDL_BUILD_DIR/megawizard or more general $RADIOHDL_BUILD_DIR/ip? 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//quartus -- made by quartus_config.py using synth_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 - The IP can be put in a subdir using eg 'tool_name_ip' = quartus_ip: + The IP can be put in a subdir using eg 'ip_tool_name' = quartus_ip: - $RADIOHDL_BUILD_DIR//quartus_ip -- made by quartus_config.py using a new tool_name_ip from hdl_buildset_.cfg + $RADIOHDL_BUILD_DIR//quartus_ip -- made by quartus_config.py using a new ip_tool_name from hdl_buildset_.cfg 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: - $RADIOHDL_BUILD_DIR// + // $RADIOHDL_BUILD_DIR/unb1/megawizard -- Altera MegaWizard $RADIOHDL_BUILD_DIR/unb1/qsys -- Altera QSYS $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 - 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 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 + 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 + sub directory. However the IP could also be generated into the synth_tool_name 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 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: - Using synth_tool_name = quartus is also sufficient/suitable to define the build subdirectory for IP generation. - - Use dedicated key per IP generation tool: - . qmegawiz_generate_ip --> generate in // - . qsys_generate_ip --> generate in // - so assume that multiple generated IP they can share the generated directory, this is defined as an - option in the method that treats the *_generate_ip key, so it could be different per IP generation tool. - - Use --generate_ip option with quartus_config.py to generate the IP. This option looks for the *_generate_ip keys - and then executes them. Default this option is not used, because it the IP only needs t obe generated once. - - Generated IP that is kept in SVN could be copied to the build dir, and then treated as if it was generated. - - 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. - - Having a dedicate tool_name_ip could be nice, to more clearly see in the build tree which libraries have IP and - to bring them at a the same level as sim_tool_name and synth_tool_name. - + Having a dedicate ip_tool_name could be nice, to more clearly see in the build tree which libraries have IP. +c) regression test script + * For pure HDL tests the modelsim_regression_test.py script can simulate VHDL test benches that are listed at + the 'regression_test_vhdl' key and report the result. + * For Python test cases another key can be defined 'regression_test_py_hdl'. 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. + * Another bash or Python script that synthesises a set of designs to check that they still run through synthesis ok. + +d) multiple libRootDirs for finding hdllib.cfg files + The libRootDir is now defined via a the 'lib_root_dir' key in the hdl_buildset_.cfg. + 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 The IP is FPGA type specific (because it needs to be defined in the Qsys source file) and tool version specific @@ -363,11 +256,11 @@ 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: - $RADIOHDL/libraries/technology/ip_arria10/ + ${RADIOHDL_WORK}/libraries/technology/ip_arria10/ This can be renamed in: - $RADIOHDL/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_15.0/ + ${RADIOHDL_WORK}/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 to define the FPGA technology as a triplet: @@ -376,7 +269,7 @@ A future version of the IP can be kept in: - $RADIOHDL/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/ + ${RADIOHDL_WORK}/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/ The technology_pkg.vhd then gets; @@ -388,7 +281,7 @@ 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): technology_names = ip_stratixiv @@ -399,7 +292,7 @@ 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 library key values in the IP hdllib.cfg to contain the full triplet information, so eg. @@ -412,7 +305,7 @@ hdl_lib_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo 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_name, 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, 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. Alternatively the hdllib_config.py could support multiple technology version IP libraries that use the same logical library name and use clause. @@ -422,14 +315,17 @@ 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_name scheme +g) Improve buildset scheme -The buildset_name defines the combination of Modelsim version and Quartus version. Currently there are buildset_names 'unb1', 'unb2' and 'unb2a'. This -buildset_name scheme can be improved because: +The buildset defines the combination of Modelsim version and Quartus version. Currently there are buildsets 'unb1', 'unb2' and 'unb2a'. This +buildset scheme can be improved because: -- 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 - buildset_name names at all? -- there is also a 'site' level in the bash scripts set_modelsim and set quartus (is that still needed?) +- for python they are defined by the hdl_buildset_.cfg, but for the run_* bash scripts they are defined in set_quartus, + 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 + script must then be ran from the same terminal as where the python config script was used to set the environment variable, because otherwise + 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. @@ -442,7 +338,9 @@ 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 simulation there is no need to exclude IP libraries. - + + + 101) More ideas a) zip scripts @@ -479,5 +377,4 @@ # Time: 0 fs Iteration: 0 Instance: /tb_<...>//ip_stratixiv_phy_xaui_0_inst////// File: nofile # 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.

Browse

Tools

Subversion Repositories radiohdl

Compare Revisions

Rev 7 → Rev 4