109 lines
5.5 KiB
ReStructuredText
109 lines
5.5 KiB
ReStructuredText
.. _advanced-usage:
|
|
|
|
Advanced Usage
|
|
==============
|
|
|
|
Hammer Development
|
|
------------------
|
|
If you need to develop Hammer within Chipyard or use a version of Hammer beyond the latest PyPI release, clone the `Hammer repository <https://github.com/ucb-bar/hammer>`__ somewhere else on your disk. Then:
|
|
|
|
.. code-block:: shell
|
|
|
|
pip install -e <path/to/hammer>
|
|
|
|
Alternative RTL Flows
|
|
---------------------
|
|
The Make-based build system provided supports using Hammer without using RTL generated by Chipyard. To push a custom Verilog module through, one only needs to append the following environment variables to the ``make buildfile`` command (or edit them directly in the Makefile).
|
|
|
|
.. code-block:: shell
|
|
|
|
CUSTOM_VLOG=<your Verilog files>
|
|
VLSI_TOP=<your top module>
|
|
|
|
``CUSTOM_VLOG`` breaks the dependency on the rest of the Chipyard infrastructure and does not start any Chisel/FIRRTL elaboration. ``VLSI_TOP`` selects the top module from your custom Verilog files.
|
|
|
|
Hierarchical Flows
|
|
------------------
|
|
The Make-based build system supports bottom-up hierarchical place-and-route flows. You will need to create your module hierarchy in your input configuration YMLs before running the ``buildfile`` make target. If you change your hierarchy at any point, the ``hammer.d`` file needs to be re-generated.
|
|
|
|
Throughout the execution of the hierarchical flow, you must override the ``VLSI_TOP`` Make variable to the hierarchical submodule that you are currently working on. Otherwise, simulation and power flows will not work properly.
|
|
|
|
For more information about setting up hierarchical flows, see the `Hammer documentation <https://hammer-vlsi.readthedocs.io/en/stable/Hammer-Use/Hierarchical.html>`__.
|
|
|
|
Under the Hood
|
|
--------------
|
|
To uncover what is happening under the hood, here are the commands that are executed:
|
|
|
|
For ``make syn``:
|
|
|
|
.. code-block:: shell
|
|
|
|
./example-vlsi -e /path/to/env.yml -p /path/to/example.yml -p /path/to/inputs.yml --obj_dir /path/to/build syn
|
|
|
|
``example-vlsi`` is the entry script as explained before, ``-e`` provides the environment yml, ``-p`` points to configuration yml/jsons, ``--obj_dir`` speficies the destination directory, and ``syn`` is the action.
|
|
|
|
For ``make par``:
|
|
|
|
.. code-block:: shell
|
|
|
|
./example-vlsi -e /path/to/env.yml -p /path/to/syn-output-full.json -o /path/to/par-input.json --obj_dir /path/to/build syn-to-par
|
|
./example-vlsi -e /path/to/env.yml -p /path/to/par-input.json --obj_dir /path/to/build par
|
|
|
|
A ``syn-to-par`` action translates the synthesis output configuration into an input configuration given by ``-o``. Then, this is passed to the ``par`` action.
|
|
|
|
For more information about all the options that can be passed to the Hammer command-line driver, please see the Hammer documentation.
|
|
|
|
Manual Step Execution & Dependency Tracking
|
|
-------------------------------------------
|
|
It is invariably necessary to debug certain steps of the flow, e.g. if the power strap settings need to be updated. The underlying Hammer commands support options such as ``--stop_after_step``, ``--start_before_step``, and ``--only_step``. These allow you to control which steps of a particular action are executed.
|
|
|
|
Make's dependency tracking can sometimes result in re-starting the entire flow when the user only wants to re-run a certain action. Hammer's build system has "redo" targets such as ``redo-syn`` and ``redo-par`` to run certain actions without typing out the entire Hammer command.
|
|
|
|
Say you need to update some power straps settings in ``new_power_straps.yml`` and want to try out the new settings:
|
|
|
|
.. code-block:: shell
|
|
|
|
make redo-par HAMMER_REDO_ARGS='-p new_power_straps.yml --only_step power_straps'
|
|
|
|
The command that is executed will be:
|
|
|
|
.. code-block:: shell
|
|
|
|
./example-vlsi -e /path/to/env.yml -p /path/to/par-input.json -p new_power_straps.yml --only_step power_straps --obj_dir /path/to/build par
|
|
|
|
Hierarchical RTL/Gate-level Simulation, Power Estimation
|
|
--------------------------------------------------------
|
|
With the Synopsys plugin, hierarchical RTL and gate-level simulation is supported using VCS at the chip-level. Also, rtl-level/post-syn power estimation with Joules and post-par power estimation with Voltus in the Cadence plugin is also supported. Special Make targets are provided in the ``vlsi/`` directory in ``sims.mk`` and ``power.mk``. Here is a brief description:
|
|
|
|
* ``sim-rtl``: RTL-level simulation
|
|
|
|
* ``sim-rtl-debug``: Also write a FSDB waveform
|
|
|
|
* ``sim-syn``: Post-synthesis gate-level simulation
|
|
|
|
* ``sim-syn-debug``: Also write a FSDB waveform
|
|
* ``sim-syn-timing-debug``: Timing-annotated with FSDB waveform
|
|
|
|
* ``sim-par``: Post-par gate-level simulation
|
|
|
|
* ``sim-par-debug``: Also write a FSDB waveform
|
|
* ``sim-par-timing-debug``: Timing-annotated with FSDB waveform
|
|
|
|
* ``power-rtl``: RTL-level power estimation
|
|
|
|
* Note: this will run ``sim-rtl-debug`` first
|
|
|
|
* ``power-syn``: Post-synthesis power estimation
|
|
|
|
* Note: this will run ``sim-syn-debug`` first
|
|
|
|
* ``power-par``: Post-par power estimation
|
|
|
|
* Note: this will run ``sim-par-debug`` first
|
|
|
|
* ``redo-`` can be appended to all above targets to break dependency tracking, like described above.
|
|
|
|
* ``-$(VLSI_TOP)`` suffixes denote simulations/power analysis on a submodule in a hierarchical flow (remember to override this variable, as explained above). Note that you must provide the testbenches for these modules since the default testbench only simulates a Chipyard-based ``ChipTop`` DUT instance.
|
|
|
|
The simulation configuration (e.g. binaries) can be edited for your design. See the ``Makefile`` and refer to Hammer's documentation for how to set up simulation parameters for your design.
|