From 7566eae213a0da049b1c6e28efb4196818967b85 Mon Sep 17 00:00:00 2001 From: Harrison Liew Date: Fri, 24 Feb 2023 14:56:28 -0800 Subject: [PATCH 1/3] fix & clarify hierarchical flows --- docs/VLSI/Advanced-Usage.rst | 10 +++++++++- vlsi/power.mk | 17 ++++++++++++----- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/docs/VLSI/Advanced-Usage.rst b/docs/VLSI/Advanced-Usage.rst index 07e71884..e5ef18ad 100644 --- a/docs/VLSI/Advanced-Usage.rst +++ b/docs/VLSI/Advanced-Usage.rst @@ -22,6 +22,14 @@ 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 `__. + Under the Hood -------------- To uncover what is happening under the hood, here are the commands that are executed: @@ -95,6 +103,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, 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. diff --git a/vlsi/power.mk b/vlsi/power.mk index d55b965f..5e265a35 100644 --- a/vlsi/power.mk +++ b/vlsi/power.mk @@ -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) From eb155a604f6d87ade28acd7107801156e746641d Mon Sep 17 00:00:00 2001 From: Harrison Liew Date: Fri, 24 Feb 2023 15:05:35 -0800 Subject: [PATCH 2/3] move hier docs --- docs/VLSI/Advanced-Usage.rst | 10 +--------- docs/VLSI/Basic-Flow.rst | 3 +++ 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/docs/VLSI/Advanced-Usage.rst b/docs/VLSI/Advanced-Usage.rst index e5ef18ad..c547b7f9 100644 --- a/docs/VLSI/Advanced-Usage.rst +++ b/docs/VLSI/Advanced-Usage.rst @@ -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 `__. - 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. diff --git a/docs/VLSI/Basic-Flow.rst b/docs/VLSI/Basic-Flow.rst index 1bcaf754..1a730728 100644 --- a/docs/VLSI/Basic-Flow.rst +++ b/docs/VLSI/Basic-Flow.rst @@ -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 `__. + +.. 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 .. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From a146bad526185faa23444d3f3841dd74f3f8b749 Mon Sep 17 00:00:00 2001 From: Harrison Liew Date: Fri, 24 Feb 2023 15:59:33 -0800 Subject: [PATCH 3/3] fix typos --- docs/VLSI/Basic-Flow.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/VLSI/Basic-Flow.rst b/docs/VLSI/Basic-Flow.rst index 1a730728..10c2a9ec 100644 --- a/docs/VLSI/Basic-Flow.rst +++ b/docs/VLSI/Basic-Flow.rst @@ -295,11 +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 `__. -.. 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. +.. 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 .. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^