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.
|