.. _advanced-usage: Advanced Usage ============== Hammer Development and Upgrades ------------------------------- If you need to develop Hammer within Chipyard or use a version of Hammer beyond the latest PyPI release, clone the `Hammer repository `__ somewhere else on your disk. Then: .. code-block:: shell pip install -e To bump specific plugins to their latest commits and install them, you can use the upgrade script from the Chipyard root directory, with arguments for match patterns for the plugin names: .. code-block:: shell ./scripts/upgrade-vlsi.sh If you would like to upgrade your Hammer installation to the latest PyPI release and bump all of your plugins at once, run the above script without arguments. WARNING: this may pull in plugin changes that are newer than the latest Hammer release and cause incompatibility issues. 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= VLSI_TOP= ``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. 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). 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.