.. program:: ghdl .. _QuickStart:adder: `Full adder` module and testbench ================================= Unlike :ref:`Heartbeat `, the target hardware design in this example is written using the synthesisable subset of `VHDL`. It is a `full adder `_ described in a file named :file:`adder.vhdl`: .. literalinclude:: adder.vhdl :language: vhdl You can :ref:`analyse ` this design file, ``ghdl -a adder.vhdl``, and try to execute the `adder` design. But this is useless, since nothing externally visible will happen. In order to check this full adder, a :dfn:`testbench` has to be run. The :dfn:`testbench` is a description of how to generate inputs and how to check the outputs of the Unit Under Test (UUT). This one is very simple, since the adder is also simple: it checks exhaustively all inputs. Note that only the behaviour is tested, timing constraints are not checked. A file named :file:`adder_tb.vhdl` contains the testbench for the adder: .. literalinclude:: adder_tb.vhdl :language: vhdl As usual, you should analyze the file, ``ghdl -a adder_tb.vhdl``. .. HINT:: Then, if required, :ref:`elaborate ` the testbench: ``ghdl -e adder_tb``. You do not need to specify which object files are required, since `GHDL` knows them and automatically adds them. Now, it is time to :ref:`run ` the testbench, ``ghdl -r adder_tb``, and check the result on screen:: adder_tb.vhdl:52:7:(assertion note): end of test If your design is rather complex, you'd like to inspect signals as explained in :ref:`Heartbeat `. See section :ref:`simulation_options`, for more details on other runtime options. it/xen/xen/tree/xen/common/softirq.c?h=4.0.3-rc1&id=859492d2216cd8fe9924018d5bc738b78603627d'>treecommit diff stats

path: root/xen/common/softirq.c

blob: 17e850b3f674550f1e3eefd66582026096f6cfac (plain)