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

Subversion Repositories radiohdl

[/] [radiohdl/] [trunk/] [doc/] [hdltool_readme.txt] - Blame information for rev 4

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 4 danv
 
2
g) Tool start scripts
3
 
4
The definitions for actually running Modelsim and Quartus are not kept in the ~/.bashrc file or the setup script but are
5
set in a tool start script:
6
 
7
  ${RADIOHDL_GEAR}/modelsim/run_modelsim      # calls set_quartus and starts the Modelsim GUI for simulation
8
  ${RADIOHDL_GEAR}/quartus/run_quartus        # calls set_quartus and starts the Quartus GUI for synthesis
9
 
10
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,
11
the advantages of using a seperate tool start script is:
12
 
13
  - different versions of the tool can be started in parallel on the same machine, because the tool start script settings
14
    only apply to the started tool environment
15
 
16
 
17
 
18
i) How to start Quartus for RadioHDL
19
 
20
For building a SOPC system use:
21
  > run_sopc      unb1 unb1_minimal_sopc
22
  > run_app       unb1 unb1_minimal_sopc             # calls: run_bsp, run_reg, run_mif
23
  > run_app_clean unb1 unb1_minimal_sopc app=unb_osy
24
  > run_qcomp     unb1 unb1_minimal_sopc
25
  > run_all_sopc  unb1 unb1_minimal_sopc             # sequentially running: run_sopc + run_app + run_qcomp
26
  > run_rbf       unb1 unb1_minimal_sopc
27
  > run_sof       unb1 unb1_minimal_sopc 0
28
 
29
For building a QSYS system use:
30
  > run_qsys      unb1 unb1_minimal_qsys
31
  > run_sopc      unb1 unb1_minimal_sopc     # (normally not needed but the unb1_minimal_qsys revision has a GENERATE sopc-OR-qsys section)
32
  > run_app       unb1 unb1_minimal_qsys use=qsys
33
  > run_qcomp     unb1 unb1_minimal_qsys
34
  > run_all_qsys  unb1 unb1_minimal_qsys     # sequentially running: run_qsys + run_app + run_qcomp
35
  > run_rbf       unb1 unb1_minimal_qsys
36
  > run_sof       unb1 unb1_minimal_qsys 0
37
 
38
 
39
j) How to start Modelsim for UNB
40
 
41
GUI:
42
 
43
  > unb_msim &        # for UNB
44
  > aaf_msim &        # for AARTFAAC
45
  > paasar_msim &     # for PAASAR
46
 
47
See the setup_unb.sh environment script and ASTRON_RP_1354_unb_minimal.pdf for more description.
48
 
49
 
50
n) How to use RadioHDL for Lofar RSP
51
 
52
* The Lofar Station firmware is kept in a separate SVN repository at:
53
 
54
    https://svn.astron.nl/Station
55
 
56
  The firmware for the RSP board is kept in:
57
 
58
    https://svn.astron.nl/Station/trunk/RSP
59
 
60
  In setup_radiohdl.sh add the path to the local SVN checkout of the Station
61
  firmware:
62
 
63
    export RSP=${SVN}/../Station/trunk/RSP
64
 
65
  and add ${RADIOHDL_GEAR}/ise to the PATH environment variable.
66
 
67
* To compile the Xilinx ISE10.1.03 models with Modelsim 6.6c under linux do:
68
 
69
  The compxlib adds the Xilinx libraries to the [libraries] section in the
70
  /home/software/Mentor/6.6c/modeltech/modelsim.ini file. Therefore make
71
  sure to first copy this original installation modelsim.ini file, so that
72
  we can restore it.
73
 
74
    cd /home/software/modelsim_xilinx_libs/ise/10.1.03
75
    sudo mkdir vhdl
76
    sudo mkdir verilog
77
    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
78
    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
79
 
80
  Use the library mappings in the modelsim.ini that was modified by compxlib
81
  to create:
82
 
83
    tools/ise/create hdl_libraries_ip_virtex4.txt
84
 
85
  The modelsim_config.py using hdl_libraries_ip_virtex4.txt to map the Xilinx
86
  library files in each HDL library project files. Therefore the central
87
  mapping in the Modelsim installation modelsim.ini file is unwanted and not
88
  needed.
89
 
90
* Create tools/hdl_buildset_rsp.cfg HDL tool configuration dictionary file for buildset 'rsp'
91
 
92
* Create bash scripts to start up ISE based on the buildset 'rsp' in tools/ise:
93
    run_ise
94
        \--> set_ise
95
                \--> ise_version.sh
96
                \--> ise_generic.sh
97
 
98
  This is similar as for other tools like Modelsim, Quartus. The advantage of
99
  this approach is that the tool settings are only made when the tool is ran
100
  and not in the .bashrc file. These bash scripts are kept in SVN and thus the
101
  same tool settings are used by all engineers.
102
 
103
* Add 'rsp' buildset for Modelsim and ISE versions to tools/modelsim/set_modelsim.
104
 
105
* To start the ISE GUI do:
106
  > run_ise rsp &
107
 
108
* To start the Modelsim GUI do:
109
  > run_modelsim rsp &
110
 
111
 
112
3) HDL environment configuration files
113
 
114
d) hdl_buildset_.cfg key descriptions
115
 
116
- project_dir_depth_sim =
117
    The project file will be located in the build dir or at some levels deeper in the build dir.
118
    These optional extra subdirectory levels allow for relative file reference from project file
119
    location. This is useful to be able to keep memory initialisation files in the library build
120
    directory that are referred to using some fixed ../../ path in the HDL code.
121
    . project_deeper_subdir = '' when project_dir_depth_ = 0 or not in tool_dict
122
    . project_deeper_subdir = 'p/' when project_dir_depth_ = 1
123
    . project_deeper_subdir = 'p/p/' when project_dir_depth_ = 2,
124
    . project_deeper_subdir = 'p/p/p/' when project_dir_depth_ = 3, etc
125
 
126
- project_dir_depth_synth =
127
    Same purpose as project_dir_depth_sim, but for synthesis project file location in build tree.
128
 
129
 
130
 
131
5) Build directory location
132
 
133
The Modelsim and Quartus build location central outside the $HDL sources directory tree, whereby the
134
subdirectory names are defined by the corresponding keysin the hdl_buildset_.cfg:
135
 
136
  ${RADIOHDL_BUILD_DIR}//
137
 
138
eg.
139
 
140
  ${RADIOHDL_BUILD_DIR}/unb1/modelsim/common
141
 
142
The advantage of the central directory build tree is that it can easily be removed (using rm -rf) and
143
recreated (using modelsim_config.py and quartus_config.py). For synthesis recreation of targets like sof files can take much
144
time though.
145
 
146
 
147
 
148
100) To do
149
 
150
a) quartus_* keys and synth_top_level_entity
151
   . The quartus_* keys are now source oriented. Instead it may be better to redefine them as target oriented. Eg. a
152
     quartus_create_qsf key that defines to create a qsf file using the information listed in the values.
153
     Whether a key is source oriented or target oriented depends on whether its files are used for one or more targets.
154
     In general if a file is used for more targets then source oriented is preferred to avoid having to list the file
155
     name twice. If a file is used only for one target then target oriented is preferred to be more clear about the
156
     purpose of the key.
157
   . The synth_top_level_entity enforces the creation of a qpf and qsf. This kind of hidden behavior is not so nice.
158
     Instead it is more clear to have an explicit quartus_create_qpf and quartus_create_qsf key to define this.
159
 
160
b) Generate Quartus IP key
161
   The generate_ip.sh scripts for generating the MegaWizard or QSYS IP components in fact are merely a wrapper script
162
   around the qsys-generate command. The generate_ip.sh may seem an unnecessary intermediate step if the IP is
163
   generated automatically. The IP could be generated automatically based on a megawizard key or a qsys key that
164
   has the description file as value. However the advantage of a generate_ip.sh script is that it can hide whether the
165
   MegaWizard or QSYS needs to be used to generate the IP, so in that way a 'quartus_generate_ip' key can fit both:
166
 
167
     quartus_copy_files =
168
         generate_ip.sh
169
         _.qsys
170
     quartus_generate_ip = generate_ip.sh
171
 
172
   The 'quartus_copy_files' key is used to copy the IP generation source file and the generation script to the
173
   build directory. The 'quartus_generate_ip' key identifies the script that needs to be ran when the IP has to be
174
   generated. Eg. a --generate_ip command line argument for quartus_config.py (rather than a separate
175
   quartus_generate_ip.py script) can then generate the IP for all libraries that have such a key. The IP can then
176
   be generated outside the SVN tree. The $IP_DIR path compile_ip.tcl needs to be adjusted to generated/ and the
177
   IP then gets generated in:
178
 
179
      $RADIOHDL_BUILD_DIR//quartus//generated
180
 
181
   For generated IP that is kept in SVN that IP could still remain there.
182
 
183
   The hdllib.cfg should then also define a IP toolname subdirectory in build dir, eg.:
184
 
185
     // = $RADIOHDL_BUILD_DIR/qsys        or
186
                                         $RADIOHDL_BUILD_DIR/megawizard
187
 
188
   or more general $RADIOHDL_BUILD_DIR/ip?
189
   The $RADIOHDL_BUILD_DIR now has a modelsim and quartus subdir:
190
 
191
      $RADIOHDL_BUILD_DIR//modelsim       -- made by modelsim_config.py using sim_tool_name from hdl_buildset_.cfg
192
      $RADIOHDL_BUILD_DIR//quartus        -- made by quartus_config.py using synth_tool_name from hdl_buildset_.cfg
193
 
194
   The IP can be put in a subdir using eg 'ip_tool_name' = quartus_ip:
195
 
196
      $RADIOHDL_BUILD_DIR//quartus_ip     -- made by quartus_config.py using a new ip_tool_name from hdl_buildset_.cfg
197
 
198
   or can it be put in the synth_tool_name directory:
199
 
200
      $RADIOHDL_BUILD_DIR//quartus
201
 
202
   or do we need tool_name_megawizard and tool_name_qsys to be able to create:
203
 
204
      //
205
      $RADIOHDL_BUILD_DIR/unb1/megawizard     -- Altera MegaWizard
206
      $RADIOHDL_BUILD_DIR/unb1/qsys           -- Altera QSYS
207
      $RADIOHDL_BUILD_DIR/unb1/coregen        -- Xilinx
208
 
209
   Probably it is not so important whether the IP is generated by MegaWizard or Qsys, because that selection is
210
   already covered by the generate_ip.sh scripts. In the hdl_buildset_.cfg both MegaWizard and Qsys can be regarded as
211
   being part of the Quartus tool. Therefore using ip_tool_name provides sufficient distinction in IP build
212
   sub directory. However the IP could also be generated into the synth_tool_name build directory and then even
213
   the ip_tool_name key is not needed, because the synth_tool_name sub directory also suits the Quartus IP
214
   generation.
215
 
216
   Conclusion:
217
   - Using synth_tool_name = quartus is also sufficient/suitable to define the build subdirectory for IP generation.
218
     Having a dedicate ip_tool_name could be nice, to more clearly see in the build tree which libraries have IP.
219
 
220
c) regression test script
221
   * For pure HDL tests the modelsim_regression_test.py script can simulate VHDL test benches that are listed at
222
     the 'regression_test_vhdl' key and report the result.
223
   * For Python test cases another key can be defined 'regression_test_py_hdl'. The values they may contain the entire command
224
     to run the Python test case with the HDL test bench. Note that the pure VHDL test benches could be perphaps also be
225
     regarded as a special case of the Python MM - VHDL tests, ie. as a test without MM.
226
   * Another bash or Python script that synthesises a set of designs to check that they still run through synthesis ok.
227
 
228
d) multiple libRootDirs for finding hdllib.cfg files
229
   The libRootDir is now defined via a the 'lib_root_dir' key in the hdl_buildset_.cfg.
230
   Currently hdlib.cfg files are search from one rootDir by find_all_dict_file_paths() in common_dict_file.py. It
231
   would be usefule to be able to specify multiple rootDirs for the search path. This allows finding eg. all
232
   hdllib.cfg in two different directory trees without having to specifiy their common higher directory root which
233
   could be a very large tree to search through. Furthermore by being able to specify the rootDirs more precisely
234
   avoids finding unintended hdllib.cfg files. Support for multiple rootdirs needs to be implemented in
235
   common_dict_file.py because the results from all root dirs need to be in a common object.
236
 
237
e) Python peripherals
238
   The Python peripherals are still in the $UNB/Software/python/peripherals directory. At some time we need to move
239
   these also to RadioHDL. The peripherals could be located central again or local in a src/python directory. A first
240
   step can be to svn copy the $UNB/Software/python dir to ${RADIOHDL_WORK}/software/python to become independent of the
241
   $UNB tree. An intermediate scheme is also possible whereby the periperal is kept local but copied to a central
242
   build/python directory by means of a python_config.py script. The advantage of a central directory is that the periperals
243
   are grouped so that only a single Python search path is needed. The disadvantage of having a fixed central
244
   location in SVN is that peripherals that are application specific also need to be located there. Another option
245
   may be to use a synbolic link from a central directory to each local Python peripheral.
246
 
247
 
248
f) Improve support IP for multiple FPGA device types and Quartus tool versions
249
 
250
The IP is FPGA type specific (because it needs to be defined in the Qsys source file) and tool version specific
251
(because some parameters and even port IO may change). Currently there is only one IP directory per FPGA
252
technology (eg. ip_arria10) so there is no further separation into device family type and tool version. The
253
disadvantage of this scheme is that only one version of Quartus can be supported. For a minor version
254
change it may not be necessary to upgrade, but for a major version change or for a device family type (eg. from
255
engineering sample to production sample) change it probably is. To preserve the old version IP it is best to
256
treat the both the FPGA device version id and the Quartus tool version as a new technology. For example for
257
Arria10 we now use Quartus 15.0 and device family of UniBoard2 v0 and the IP for that is kept in:
258
 
259
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10/
260
 
261
This can be renamed in:
262
 
263
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_15.0/
264
 
265
For a directory name it is allowed to use a '.' instead of a '_'. The directory name is not mandatory, but the name convention is
266
to define the FPGA technology as a triplet:
267
 
268
  ip__device__quartus_
269
 
270
A future version of the IP can be kept in:
271
 
272
  ${RADIOHDL_WORK}/libraries/technology/ip_arria10_device_10AX115U4F45I3SGES_quartus_16.0/
273
 
274
The technology_pkg.vhd then gets;
275
 
276
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_14_1 = ...;
277
  c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0 = ...;
278
  c_tech_arria10                                        = c_tech_arria10_device_10AX115U4F45I3SGES_quartus_15_0;  -- optional default
279
 
280
The hdllib.cfg of the specific technology IP library then has key (only one value):
281
 
282
  hdl_lib_technology = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
283
 
284
The hdl_buildset_.cfg can support multiple technologies eg. to be able to simulate a system with more than one FPGA that are
285
of different technology (eg. an application with Uniboard1 and Uniboard2):
286
 
287
  technology_names = ip_stratixiv
288
                     ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0
289
 
290
All libraries that have hdl_lib_technology value that is not in the list of technology_names are removed from the dictionary list
291
by hdl_config.py, so these IP libraries will not be build.
292
 
293
The build directory currently contains:
294
 
295
  //
296
 
297
This scheme is probably still sufficent to also support the FPGA technology as a triplet. However it may be necessary to rename the
298
library key values in the IP hdllib.cfg to contain the full triplet information, so eg.
299
 
300
  hdl_lib_name = ip_arria10_fifo
301
  hdl_library_clause_name = ip_arria10_fifo_lib
302
 
303
then becomes:
304
 
305
  hdl_lib_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo
306
  hdl_library_clause_name = ip_arria10_device_10AX115U4F45I3SGES_quartus_15_0_fifo_lib
307
 
308
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
309
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.
310
Alternatively the hdllib_config.py could support multiple technology version IP libraries that use the same logical library name and use
311
clause.
312
 
313
The purpose is to be able to handle in parallel different FPGA vendors, different FPGA types and different tool version. We do not have
314
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
315
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.
316
 
317
 
318
g) Improve buildset scheme
319
 
320
The buildset defines the combination of Modelsim version and Quartus version. Currently there are buildsets 'unb1', 'unb2' and 'unb2a'. This
321
buildset scheme can be improved because:
322
 
323
- for python they are defined by the hdl_buildset_.cfg, but for the run_* bash scripts they are defined in set_quartus,
324
  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
325
  script must then be ran from the same terminal as where the python config script was used to set the environment variable, because otherwise
326
  the environment variable is not set or may not be correct.
327
- 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?
328
- there is also a 'site' level in the bash scripts set_quartus (is that still needed?)
329
 
330
 
331
h) Declare IP libraries to ensure default binding in simulation.
332
 
333
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.
334
This IP library clause is ignored by synthesis. The IP library must be mapped for simulation, because otherwise Modelsim gives
335
an error when it compiles the VHDL. Therefore the IP library can then not be excluded for simulation with 'hdl_lib_include_ip' key.
336
Alternatively the LIBRARY clause could be omitted if the IP library is added to the -L libraries search list of each simulation configuration the
337
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
338
then that if the IP library is not mapped to a directory then Modelsim will issue an error when it tries to search it.
339
--> 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
340
    for simulation there is no need to exclude IP libraries.
341
 
342
 
343
 
344
101) More ideas
345
 
346
a) zip scripts
347
   A zip script can gather all sources that are needed for a particular RadioHDL view point, eg.
348
 
349
   - zip all required libraries for a certain level library --> useful for somebody who wants to reuse a HDL library.
350
   - zip all code necessary to run Python test cases on HW target --> useful for somebody who only wants to use the HW.
351
   - zip all tool environent code --> useful for somebody who wants to use our tool flow but not our HDL.
352
 
353
   Related to this is (how) can we more clearly divide up the RadioHDL/ directory to eg. reuse only parts of it and
354
   to develop these in other locations/repositories (eg. GIT). Eg. the applications/ directory may not be needed or
355
   even suitable in RadioHDL/ because applications could be kept elsewhere, even in another repository at another
356
   institute.
357
 
358
b) support dynamic generation of IP
359
   Very preliminary ideas:
360
   Currently the MegaWizard or QSYS component description file is fixed and created manually in advance via the
361
   GUI. In future the component description file could be created based on parameters that are defined in the
362
   hdllib.cfg or even parameters that depend on the requirements from the design. In a dynamic flow the hdllib.cfg
363
   for IP could even not exist as a file, but only as a dictionary in the script.
364
 
365
c) Link RadioHDL developments with the OneClick MyHDL developments.
366
   The hdllib.cfg dictionary format seems useful also in the OneClick flow. For some created libraries the hdllib.cfg
367
   may not exist as a file and but only as the dictionary in the script. The various methods in modelsim_config.py
368
   and quartus_config.py can also be reused in a OneClick flow.
369
 
370
 
371
102) Know errors
372
 
373
a) ** Fatal: Error occurred in protected context. when loading a simulation in Modelsim
374
 - Example:
375
   # Loading ip_stratixiv_phy_xaui_lib.ip_stratixiv_phy_xaui_0(rtl)
376
   # ** Fatal: Error occurred in protected context.
377
   #    Time: 0 fs  Iteration: 0  Instance: /tb_<...>//ip_stratixiv_phy_xaui_0_inst////// File: nofile
378
   # FATAL ERROR while loading design
379
 
380
   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.