iCE40/ghdl - clone of https://github.com/ghdl/ghdl

diff options

author	Tristan Gingold <tgingold@free.fr>	2019-10-21 19:28:18 +0200
committer	Tristan Gingold <tgingold@free.fr>	2019-10-21 19:28:18 +0200
commit	92c75a0cbf315abe01b25b60f064941b3fadd80a (patch)
tree	eabedba5f347cede43ab9b9335ee145e9d4c31b4 /src/vhdl
parent	4894a7e85b327c24e26545b3a76d36b8bf7ef8d9 (diff)
download	ghdl-92c75a0cbf315abe01b25b60f064941b3fadd80a.tar.gz ghdl-92c75a0cbf315abe01b25b60f064941b3fadd80a.tar.bz2 ghdl-92c75a0cbf315abe01b25b60f064941b3fadd80a.zip

vhdl-prints: handle restrict in vunit.

Diffstat (limited to 'src/vhdl')

-rw-r--r--

src/vhdl/vhdl-prints.adb

1 files changed, 2 insertions, 0 deletions

.. program:: ghdl .. _USING:Invoking: Invoking GHDL ############# The form of the :program:`ghdl` command is ``ghdl command [options...]``. There are multiple available commands, but these general rules apply: * The first argument selects the command. The options are used to slightly modify the action. * No option is allowed before the command. Except for the run command, no option is allowed after a filename or a unit name. .. HINT:: If the number of options is large and the command line length is beyond the system limit, you can use a response file. An argument that starts with a ``@`` is considered as a response file; it is replaced by arguments read from the file (separated by blanks and end of line). .. HINT:: Only the most common commands and options are shown here. For the most advanced and experimental features see section :ref:`REF:Command`. .. WARNING:: During analysis and elaboration GHDL may read the ``std`` and ``ieee`` files. The location of these files is based on the prefix, which is (in order of priority): * the :option:`--PREFIX` command line option * the :envvar:`GHDL_PREFIX` environment variable * a built-in default path. It is a hard-coded path on GNU/Linux, and it corresponds to the value of the ``HKLM\Software\Ghdl\Install_Dir`` registry entry on Windows. You should use the :option:`--disp-config` command to display and debug installation problems. Design building commands ======================== The most commonly used commands of GHDL are those to analyze and elaborate a design. .. index:: cmd analysis Analysis [``-a``] --------------------- .. option:: -a <[options...] file...> Analyzes/compiles one or more files, and creates an object file for each source file. Any argument starting with a dash is an option, the others are filenames. No options are allowed after a filename argument. GHDL analyzes each filename in the given order, and stops the analysis in case of error (remaining files are not analyzed). See :ref:`GHDL:options`, for details on the GHDL options. For example, to produce debugging information such as line numbers, use: ``ghdl -a -g my_design.vhdl``. .. index:: cmd elaboration .. _Elaboration:command: Elaboration [``-e``] ------------------------ .. option:: -e <[options...] primary_unit [secondary_unit]> Re-analyzes all the configurations, entities, architectures and package declarations, and creates the default configurations and the default binding indications according to the LRM rules. It also generates the list of object files required for the executable. Then, it links all these files with the runtime library. * The elaboration command, :option:`-e`, must be followed by a name of either: * a configuration unit * an entity unit * an entity unit followed by a name of an architecture unit Name of the units must be a simple name, without any dot. You can select the name of the `WORK` library with the :option:`--work=NAME` option, as described in :ref:`GHDL:options`. See section :ref:`Top_entity`, for the restrictions on the root design of a hierarchy. * If the GCC/LLVM backend was enabled during the compilation of GHDL, the elaboration command creates an executable containing the code of the VHDL sources, the elaboration code and simulation code to execute a design hierarchy. The executable is created in the current directory and the the filename is the name of the primary unit, or for the latter case, the concatenation of the name of the primary unit, a dash, and the name of the secondary unit (or architecture). Option :option:`-o` followed by a filename can override the default executable filename. * If mcode is used, this command elaborates the design but does not generate anything. Since the run command also elaborates the design, this can be skipped. .. WARNING:: This elaboration command is not a complete elaboration in terms of the VHDL standard. The actual elaboration is performed at runtime. Therefore, in order to get a complete VHDL elaboration without running the simulation, ``ghdl --elab-run --no-run`` is required. .. index:: cmd run Run [``-r``] ---------------- .. option:: -r <[options...] primary_unit [secondary_unit] [simulation_options...]> Runs/simulates a design. The options and arguments are the same as for the :ref:`elaboration command <Elaboration_command>`. * GGC/LLVM: simply, the filename of the executable is determined and it is executed. Options are ignored. You may also directly execute the program. The executable must be in the current directory. * mcode: the design is elaborated and the simulation is launched. As a consequence, you must use the same options used during analysis. This command exists for three reasons: * You are using GCC/LLVM, but you don't need to create the executable program name. * It is coherent with the :option:`-a` and :option:`-e` commands. * It works with mcode implementation, where the executable code is generated in memory. See section :ref:`USING:Simulation`, for details on options. .. index:: cmd elaborate and run Elaborate and run [``--elab-run``] -------------------------------------- .. option:: --elab-run <[elab_options...] primary_unit [secondary_unit] [run_options...]> Acts like the elaboration command (see :option:`-e`) followed by the run command (see :option:`-r`). .. index:: cmd checking syntax Check syntax [``-s``] ------------------------- .. option:: -s <[options] files> Analyze files but do not generate code. This command may be used to check the syntax of files. It does not update the library. .. index:: cmd analyze and elaborate Analyze and elaborate [``-c``] ---------------------------------- .. option:: -c <[options] file... -<e|r> primary_unit [secondary_unit]> .. HINT:: With GCC/LLVM, :option:`-e` should be used, and :option:`-r` with mcode. The files are first parsed, and then a elaboration is performed, which drives an analysis. Effectively, analysis and elaboration are combined, but there is no explicit call to :option:`-a`. With GCC/LLVM, code is generated during the elaboration. With mcode, the simulation is launched after the elaboration. All the units of the files are put into the `work` library. But, the work library is neither read from disk nor saved. Therefore, you must give all the files of the `work` library your design needs. The advantages over the traditional approach (analyze and then elaborate) are: * The compilation cycle is achieved in one command. * Since the files are only parsed once, the compilation cycle may be faster. * You don't need to know an analysis order. * This command produces a smaller executable, since unused units and subprograms do not generate code. .. HINT:: However, you should know that most of the time is spent in code generation and the analyze and elaborate command generates code for all units needed, even units of ``std`` and ``ieee`` libraries. Therefore, according to the design, the time for this command may be higher than the time for the analyze command followed by the elaborate command. .. WARNING:: This command is still under development. In case of problems, you should go back to the traditional way. Design rebuilding commands ========================== Analyzing and elaborating a design consisting of several files can be tricky, due to dependencies. GHDL has a few commands to rebuild a design. .. index:: cmd importing files Import [``-i``] ------------------- .. option:: -i <[options] file...> All the files specified in the command line are scanned, parsed and added into the libraries but as not yet analyzed. No object files are created. Its purpose is to localize design units in the design files. The make command will then be able to recursively build a hierarchy from an entity name or a configuration name. .. HINT:: * Note that all the files are added to the work library. If you have many libraries, you must use the command for each library. * Since the files are parsed, there must be correct files. However, since they are not analyzed, many errors are tolerated by this command. See :option:`-m`, to actually build the design. .. index:: cmd make Make [``-m``] ----------------- .. option:: -m <[options] primary [secondary]> Analyze automatically outdated files and elaborate a design. The primary unit denoted by the ``primary`` argument must already be known by the system, either because you have already analyzed it (even if you have modified it) or because you have imported it. A file may be outdated because it has been modified (e.g. you have just edited it), or because a design unit contained in the file depends on a unit which is outdated. This rule is of course recursive. * With option :option:`--bind`, GHDL will stop before the final linking step. This is useful when the main entry point is not GHDL and you're linking GHDL object files into a foreign program. * With option :option:`-f` (force), GHDL analyzes all the units of the work library needed to create the design hierarchy. Outdated units are recompiled. This is useful if you want to compile a design hierarchy with new compilation flags (for example, to add the *-g* debugging option). The make command will only re-analyze design units in the work library. GHDL fails if it has to analyze an outdated unit from another library. The purpose of this command is to be able to compile a design without prior knowledge of file order. In the VHDL model, some units must be analyzed before others (e.g. an entity before its architecture). It might be a nightmare to analyze a full design of several files if you don't have the ordered list of files. This command computes an analysis order. The make command fails when a unit was not previously parsed. For example, if you split a file containing several design units into several files, you must either import these new files or analyze them so that GHDL knows in which file these units are. The make command imports files which have been modified. Then, a design hierarchy is internally built as if no units are outdated. Then, all outdated design units, using the dependencies of the design hierarchy, are analyzed. If necessary, the design hierarchy is elaborated. This is not perfect, since the default architecture (the most recently analyzed one) may change while outdated design files are analyzed. In such a case, re-run the make command of GHDL. .. index:: cmd generate makefile Generate Makefile [``--gen-makefile``] -------------------------------------- .. option:: --gen-makefile <[options] primary [secondary]> This command works like the make command (see :option:`-m`), but only a makefile is generated on the standard output. .. index:: --gen-depends command Generate dependency file command [``--gen-depends``] ---------------------------------------------------- .. option:: --gen-depends <[options] primary [secondary]> Generate a Makefile containing only dependencies to build a design unit. This command works like the make and gen-makefile commands (see :option:`-m`), but instead of a full makefile only dependencies without rules are generated on the standard output. Theses rules can then be integrated in another Makefile. .. _GHDL:options: Options ======= .. index:: IEEE 1164 .. index:: 1164 .. index:: IEEE 1076.3 .. index:: 1076.3 .. HINT:: Besides the options described below, `GHDL` passes any debugging options (those that begin with :option:`-g`) and optimizations options (those that begin with :option:`-O` or :option:`-f`) to `GCC`. Refer to the `GCC` manual for details. .. index:: WORK library .. option:: --work=<NAME> Specify the name of the ``WORK`` library. Analyzed units are always placed in the library logically named ``WORK``. With this option, you can set its name. By default, the name is ``work``. `GHDL` checks whether ``WORK`` is a valid identifier. Although being more or less supported, the ``WORK`` identifier should not be an extended identifier, since the filesystem may prevent it from working correctly (due to case sensitivity or forbidden characters in filenames). `VHDL` rules forbid you from adding units to the ``std`` library. Furthermore, you should not put units in the ``ieee`` library. .. option:: --workdir=<DIR> Specify the directory where the ``WORK`` library is located. When this option is not present, the ``WORK`` library is in the current directory. The object files created by the compiler are always placed in the same directory as the ``WORK`` library. Use option :option:`-P` to specify where libraries other than ``WORK`` are placed. .. option:: --std=<STD> Specify the standard to use. By default, the standard is ``93c``, which means VHDL-93 accepting VHDL-87 syntax. For details on ``STD`` values see section :ref:`VHDL_standards`. .. option:: --ieee=<VER> .. index:: ieee library .. index:: synopsys library .. index:: mentor library Select the ``IEEE`` library to use. ``VER`` must be one of:


context:
space:
mode: