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

Merge pull request #1368 from ucb-bar/power-mk-fix

Browse Source
This commit is contained in:
Harrison Liew
2023-02-24 15:59:56 -08:00
committed by GitHub
parent 4fbfb69cf2 a146bad526
commit 58590f2abe
3 changed files with 17 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -95,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. 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.

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

@@ -295,8 +295,11 @@ For example, if we choose to specifiy the previously mentioned ``GemminiRocketCo
bottom: 0
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.
In this specification, ``vlsi.inputs.hierarchical.mode`` indicates the manual specification of the hierarchy tree (which is the only mode currently supported by Hammer), ``vlsi.inputs.hierarchical.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, you must 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
.. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

17
vlsi/power.mk
View File

@@ -2,8 +2,9 @@ POWER_CONF = $(OBJ_DIR)/power-inputs.yml
POWER_RTL_CONF = $(OBJ_DIR)/power-rtl-inputs.yml
POWER_SYN_CONF = $(OBJ_DIR)/power-syn-inputs.yml
POWER_PAR_CONF = $(OBJ_DIR)/power-par-inputs.yml
POWER_PAR_HIER_CONF = $(OBJ_DIR)/power-par-$(VLSI_TOP)-inputs.yml
.PHONY: $(POWER_CONF) $(POWER_RTL_CONF) $(POWER_SYN_CONF) $(POWER_PAR_CONF)
.PHONY: $(POWER_CONF) $(POWER_RTL_CONF) $(POWER_SYN_CONF) $(POWER_PAR_CONF) $(POWER_PAR_HIER_CONF)
$(POWER_CONF): $(VLSI_RTL)
mkdir -p $(dir $@)
@@ -45,6 +46,12 @@ $(POWER_PAR_CONF): $(VLSI_RTL)
echo " level: par" >> $@
echo " database: '$(OBJ_DIR)/par-rundir/$(VLSI_TOP)_FINAL'" >> $@
$(POWER_PAR_HIER_CONF): $(VLSI_RTL)
echo "vlsi.core.power_tool: hammer.power.voltus" > $@
echo "power.inputs:" >> $@
echo " level: par" >> $@
echo " database: '$(OBJ_DIR)/par-$(VLSI_TOP)/$(VLSI_TOP)_FINAL'" >> $@
power-rtl: $(POWER_CONF) $(POWER_RTL_CONF) sim-rtl-debug
power-rtl-$(VLSI_TOP): $(POWER_CONF) $(POWER_RTL_CONF) sim-rtl-debug-$(VLSI_TOP)
power-rtl: override HAMMER_POWER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_RTL_CONF)
@@ -64,12 +71,12 @@ redo-power-syn: override HAMMER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_SYN_CO
redo-power-syn-$(VLSI_TOP): override HAMMER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_SYN_CONF)
power-par: $(POWER_CONF) $(POWER_PAR_CONF) sim-par-debug
power-par-$(VLSI_TOP): $(POWER_CONF) $(POWER_PAR_CONF) sim-par-debug-$(VLSI_TOP)
power-par-$(VLSI_TOP): $(POWER_CONF) $(POWER_PAR_HIER_CONF) sim-par-debug-$(VLSI_TOP)
power-par: override HAMMER_POWER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_CONF)
power-par-$(VLSI_TOP): override HAMMER_POWER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_CONF)
power-par-$(VLSI_TOP): override HAMMER_POWER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_HIER_CONF)
redo-power-par: $(POWER_CONF) $(POWER_PAR_CONF)
redo-power-par-$(VLSI_TOP): $(POWER_CONF) $(POWER_PAR_CONF)
redo-power-par-$(VLSI_TOP): $(POWER_CONF) $(POWER_PAR_HIER_CONF)
redo-power-par: override HAMMER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_CONF)
redo-power-par-$(VLSI_TOP): override HAMMER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_CONF)
redo-power-par-$(VLSI_TOP): override HAMMER_EXTRA_ARGS += -p $(POWER_CONF) -p $(POWER_PAR_HIER_CONF)
$(OBJ_DIR)/power-%/power-output-full.json: private override HAMMER_EXTRA_ARGS += $(HAMMER_POWER_EXTRA_ARGS)