wu-arch/chipyard
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

move hier docs

Browse Source
This commit is contained in:
Harrison Liew
2023-02-24 15:05:35 -08:00
parent 7566eae213
commit eb155a604f
2 changed files with 4 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/VLSI/Advanced-Usage.rst
View File

@@ -22,14 +22,6 @@ The Make-based build system provided supports using Hammer without using RTL gen
``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:
@@ -103,6 +95,6 @@ With the Synopsys plugin, hierarchical RTL and gate-level simulation is supporte
* ``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.
* ``-$(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.

3
docs/VLSI/Basic-Flow.rst
View File

@@ -297,6 +297,9 @@ For example, if we choose to specifiy the previously mentioned ``GemminiRocketCo
In this specification, ``vlsi.inputs.hierarchical.mode`` indicates the manual specification of the heirarchy tree (which is the only mode currently supported by Hammer), ``vlsi.inputs.hiearchical.top_module`` sets the root of the hierarchical tree, ``vlsi.inputs.hierarchical.manual_modules`` enumerates the tree of hierarchical modules, and ``vlsi.inputs.hierarchical.manual_placement_constraints`` enumerates the floorplan for each module.
For more information about the Hammer hierarchical flow and specifying the hierarchy and constraints, visit the `Hammer documentation <https://hammer-vlsi.readthedocs.io/en/stable/Hammer-Use/Hierarchical.html>`__.
.. Note:: You must generate the hierarchical hierarchy BEFORE running the ``make buildfile`` target. This is because Hammer encodes its hierarchical flow graph in a generated Makefile in ``$(OBJ_DIR)/hammer.d``. If you modify your physical hierarchy, you must wipe and regenerate this Makefile. Finally, it is important to always override the ``VLSI_TOP`` variable to be the hierarchical block that you are working on. This is required for hierarchical simulation and power flows.
.. Specifying a Custom Floorplan
.. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^