Merge branch 'master' into ams_experimental

doc/Hammer-Use/Hierarchical.rst

@@ -11,7 +11,7 @@ Hierarchical Hammer Config
 The hierarchal flow is controlled in the ``vlsi.inputs.hierarchal`` namespace. To specify hierarchical mode, you must specify the following keys. In this example, we have our top module set as ``ChipTop``, with a submodule ``ModuleA`` and another submdule ``ModuleAA`` below that (these are names of Verilog modules).
 
 .. code-block:: yaml
-    
+
     vlsi.inputs.hierarchical:
       mode: hierarchical
       top_module: ChipTop
@@ -23,42 +23,31 @@ The hierarchal flow is controlled in the ``vlsi.inputs.hierarchal`` namespace. T
         - ModuleAA
       constraints:
       - ChipTop:
-        - vlsi.core...
-        - vlsi.inputs...
+          vlsi.core...
+          vlsi.inputs...
       - ModuleA:
-        - vlsi.core...
-        - vlsi.inputs...
+          vlsi.core...
+          vlsi.inputs...
       - ModuleAA:
-        - vlsi.core...
-        - vlsi.inputs...
+          vlsi.core...
+          vlsi.inputs...
 
-Note how the configuration specific to each module in ``vlsi.inputs.hierarchical.constraints`` are list items, whereas in a flat flow, they would be at the root level.
+Note how the configuration specific to each module in ``vlsi.inputs.hierarchical.constraints`` appears like they would in a flat flow. This means you can apply meta directives to them as normal, as long as the references are in the same parent dictionary (i.e., key = module name).
+If you have constraints for the same module in multiple files, you can use ``vlsi.inputs.hierarchical.constraints_meta: append`` and the constraints will be combined properly.
 
-Placement constraints for each module, however, are not specified here. Instead, they should be specified in ``vlsi.inputs.hierarchical.manual_placement_constraints``. The parameters such as ``x``, ``y``, ``width``, ``height``, etc. are omitted from each constraint for clarity. In the bottom-up hierarchal flow, instances of submodules are of ``type: hardmacro`` because they are hardened from below.
+.. note::
+    In a bottom-up hierarchical flow, submodule instances must have ``type: hardmacro`` in ``vlsi.inputs.placement_constraints`` because they are hardened from below.
 
-.. code-block:: yaml
+Special considerations for legacy support:
 
-    vlsi.inputs.hierarchical:
-      manual_placement_constraints_meta: append
-      manual_placement_constraints:
-      - ChipTop:
-        - path: "ChipTop"
-          type: toplevel
-        - path: "ChipTop/path/to/instance/of/ModuleA"
-          type: hardmacro
-      - ModuleA:
-        - path: "ModuleA"
-          type: toplevel
-        - path: "ModuleA/path/to/instance/of/ModuleAA"
-          type: hardmacro
-      - ModuleAA:
-        - path: "moduleAA"
-          type: toplevel
+* If each module's ``constraints`` is a list of dicts with a single key/value pair, meta actions are not supported and the entire project configuration must be specified in a single file.
+
+* If placement constraints are specified with ``vlsi.inputs.hierarchical.manual_placement_constraints``, all of a given module's placement constraints must be specified in a single file.
 
 Flow Management and Actions
 ---------------------------
 
-Based on the structure in ``vlsi.inputs.hierarchical.manual_modules``, Hammer constructs a hierarchical flow graph of dependencies. In this particular example, synthesis and place-and-route of ``ModuleAA`` will happen first. Synthesis of ``ModuleA`` will then depend on the place-and-route output of ``ModuleAA``, and so forth. 
+Based on the structure in ``vlsi.inputs.hierarchical.manual_modules``, Hammer constructs a hierarchical flow graph of dependencies. In this particular example, synthesis and place-and-route of ``ModuleAA`` will happen first. Synthesis of ``ModuleA`` will then depend on the place-and-route output of ``ModuleAA``, and so forth.
 
 These are enumerated in the auto-generated Makefile, ``hammer.d``, which is placed in the directory pointed to by the ``--obj_dir`` command line flag when the ``buildfile`` action is run. This action must be run BEFORE executing your flow. If you adjust the hierarchy, you must re-run this action.
 
@@ -93,15 +82,7 @@ In a bottom-up hierarchical flow, is is important to remember that submodules do
 Special Notes & Limitations
 ---------------------------
 
-#. Hammer IR keys propagate up through the hierarchical tree. For example, if ``vlsi.inputs.clocks`` was specified in the constraints for ``ModuleAA`` but not for ``ModuleA``, ``ModuleA`` will inherit ``ModuleAA``'s constraints. Take special care of where your constraints come from, especially for a parent module with more than one submodule. To avoid confusion, it is recommended to specify the same set of keys for every module.
-
-#. Hammer IR keys specified at the root level (i.e. outside of ``vlsi.inputs.hierarchical.constraints``) do not override the corresponding submodule constraints. However, if you add a Hammer IR file using ``-p`` on the command line (after the file containing ``vlsi.inputs.hierarchical.constraints``), those keys are global and override submodule constraints unless a meta action is specified. To avoid confusion, it is recommended to specify all constraints with ``vlsi.inputs.hierarchical.constraints``.
-
-#. Due to the structure of ``vlsi.inputs.hierarchical.constraints`` as a list structure, currently, there are the following limitations:
-
-    * You must include all of the constraints in a single file. The config parser is unable to combine constraints from differnt files because most meta actions do not work on list items (advanced users will need to use ``deepsubst``). This will make it harder for collaboration, and unfortunately, changes to module constraints at a higher level of hierarchy after submodules are hardened will trigger the Make dependencies, so you will need to modify the generated Makefile or use redo-targets.
-
-    * Other issues have been observed, such as the bump API failing (see `this issue <https://github.com/ucb-bar/hammer/issues/401>`_ at the top module level. This is caused by similar mechanisms as above. The workaround is to ensure that bumps are specified at the root level for only the top module and the bumps step is removed from submodule par actions.
+#. Hammer IR keys specified at the root level (i.e. outside of ``vlsi.inputs.hierarchical.constraints``) are overridden by the corresponding submodule constraints. Generally, to avoid confusion, it is recommended to specify all constraints module-by-module with ``vlsi.inputs.hierarchical.constraints``.
 
 #. Most Hammer APIs are not yet intelligent enough to constrain across hierarchical boundaries. For example:
 

e2e/configs-design/pass/mock_hier.yml

@@ -21,13 +21,36 @@ vlsi.inputs.hierarchical:
         - SubModD
     - SubModB:
         - SubModE
-  manual_placement_constraints:
-    - ChipTop: []
-    - SubModA: []
-    - SubModB: []
-    - SubModC: []
-    - SubModD: []
-    - SubModE: []
+  constraints:
+    - ChipTop:
+        vlsi.inputs.placement_constraints:
+        - path: ChipTop
+          type: toplevel
+          x: 0
+          y: 0
+          width: 1000
+          height: 1000
+          margins:
+            left: 0
+            right: 0
+            top: 0
+            bottom: 0
+    - SubModC:
+        vlsi.inputs.placement_constraints:
+        - path: SubModC
+          type: toplevel
+          x: 0
+          y: 0
+          width: 100
+          height: 100
+          margins:
+            left: 0
+            right: 0
+            top: 0
+            bottom: 0
+        vlsi.inputs.power_spec_type: manual
+        vlsi.inputs.power_spec_contents: fake_command
+        par.generate_power_straps_options.by_tracks.strap_layers: [m3, m4, m5]
 
 vlsi.core.synthesis_tool: "hammer.synthesis.mocksynth"
 synthesis.mocksynth.temp_folder: "obj_dir"

e2e/configs-design/pass/mock_hier_addl.yml

@@ -0,0 +1,6 @@
+vlsi.inputs.hierarchical.constraints_meta: append
+vlsi.inputs.hierarchical.constraints:
+  - SubModC:
+      vlsi.inputs.power_spec_type: upf
+      par.generate_power_straps_options.by_tracks.strap_layers: [m6]
+      par.generate_power_straps_options.by_tracks.strap_layers_meta: append

e2e/configs-design/pass/mock_hier_legacy.yml

@@ -0,0 +1,53 @@
+# Generate Make include to aid in flow
+vlsi.core.build_system: make
+
+vlsi.inputs.power_spec_type: "cpf"
+vlsi.inputs.power_spec_mode: "auto"
+
+synthesis.inputs:
+  top_module: "pass"
+  input_files: ["src/pass.v"]
+
+vlsi.inputs.hierarchical:
+  mode: hierarchical
+  top_module: ChipTop
+  config_source: manual
+  manual_modules:
+    - ChipTop:
+        - SubModA
+        - SubModB
+    - SubModA:
+        - SubModC
+        - SubModD
+    - SubModB:
+        - SubModE
+  manual_placement_constraints:
+    - ChipTop: []
+    - SubModA: []
+    - SubModB: []
+    - SubModC:
+      - path: SubModC
+        type: toplevel
+        x: 0
+        y: 0
+        width: 100
+        height: 100
+        margins:
+          left: 0
+          right: 0
+          top: 0
+          bottom: 0
+    - SubModD: []
+    - SubModE: []
+  constraints:
+    - SubModC:
+        vlsi.inputs.power_spec_type: manual
+        vlsi.inputs.power_spec_contents: fake_command
+        par.generate_power_straps_options.by_tracks.strap_layers: [m3, m4, m5]
+
+vlsi.core.synthesis_tool: "hammer.synthesis.mocksynth"
+synthesis.mocksynth.temp_folder: "obj_dir"
+vlsi.core.par_tool: "hammer.par.mockpar"
+vlsi.core.sim_tool: "hammer.sim.mocksim"
+vlsi.core.drc_tool: "hammer.drc.mockdrc"
+vlsi.core.lvs_tool: "hammer.lvs.mocklvs"

hammer/config/config_src.py

@@ -790,9 +790,9 @@ def runtime(self) -> List[dict]:
         return [self._runtime]
 
     @staticmethod
-    def internal_keys() -> Set[str]:
+    def internal_keys() -> List[str]:
         """Internal keys that shouldn't show up in any final config."""
-        return {_CONFIG_PATH_KEY, _NEXT_FREE_INDEX_KEY}
+        return [_CONFIG_PATH_KEY, _NEXT_FREE_INDEX_KEY]
 
     def get_config(self) -> dict:
         """

hammer/config/defaults.yml

@@ -60,13 +60,13 @@ vlsi.technology:
   bump_block_cut_layer: null # Top cut/via layer for blockage under bumps. (Optional[str])
   # Only used if using vlsi.inputs.bumps
   # TODO: remove this after stackup supports vias ucb-bar/hammer#354
-  
+
   tap_cell_interval: 10.0 # Spacing between columns of tap cells (float)
   # Must be overridden by technology plugin defaults or else you will have DRC/latch-up errors.
 
   tap_cell_offset: 0.0 # Offset of the first column of tape cells from the edge of the floorplan (float)
   # Should be overridden by technology plugin defaults.
-  
+
   routing_layers: null # If specified, set/override the [bottom, top] layers used for routing. (Optional[Tuple[int, int]])
   # Both must match the index number (not name) of layers used in the stackup.
 
@@ -103,7 +103,7 @@ vlsi.technology:
 
   timing_lib_pref: "NLDM"
   # Select a timing lib preference, available options include:
-  # NLDM, ECSM, and CCS (lower or upper case acceptable). 
+  # NLDM, ECSM, and CCS (lower or upper case acceptable).
   # If no preference is specified, then the following preference order is followed:
   # NLDM -> ECSM -> CCS
 
@@ -145,7 +145,7 @@ vlsi.inputs:
     manual_modules: [] # Manual hierarchical definitions used only if hierarchical_definition_source is set to manual mode.
     # Should be a list along the lines of [{"module1": "module1_sub1", "module1_sub2", "module2": "module2_sub"}].
 
-    manual_placement_constraints: [] # Manual hierarchical placement constraints used only if hierarchical_definition_source is set to manual mode.
+    manual_placement_constraints: [] # (Deprecated) Manual hierarchical placement constraints used only if hierarchical_definition_source is set to manual mode.
     # Should be a list along the lines of [{"module1": <list of PlacementConstraint structs>}].
 
     constraints: [] # Manual hierarchical constraints. Overrides generic constraints on a per module basis.
@@ -212,7 +212,7 @@ vlsi.inputs:
   custom_sdc_constraints: [] # List of custom sdc constraints to use. (List[str])
   # These are appended after all other generated constraints (clock, pin, delay, load, etc.).
   # IMPORTANT: Since SDC is unitless, you must manually verify that your time & cap units match the tech library's units.
-  
+
   custom_sdc_files: [] # List of custom sdc files to append. (List[str])
   # These are appended after all other generated constraints and custom_sdc_constraints.
 
@@ -328,7 +328,7 @@ vlsi.inputs:
     # type: float
     pitch: 0.0
     global_x_offset: 0.0 # offset the bump map in the x-axis (float)
-    global_y_offset: 0.0 # offset the bump map in the y-axis (float)    
+    global_y_offset: 0.0 # offset the bump map in the y-axis (float)
     cell: "" # cell (str) - Name of the default bump cell
     assignments: [] # assignments - List of BumpAssignment structs. You must specify one of name or no_connect.
     # If both are specified the bump will be left unconnected
@@ -901,7 +901,7 @@ power.inputs:
   #       "write_profile" - profiles all power types on all categories for all the sub-hierarchies for a given design instance (*.fsdb)
   #       "profile" - run plot_profile + dump_profile
   #       "all" - generate all of the above report formats
-  
+
   # examples:
   #   report_configs: [{waveform_path: "/path/to/fsdb", module: "chiptop", levels:3, start_time: "0ns", end_time: "1ns", toggle_signal:"/ChipTop/clock", num_toggles:1, frame_count:1000, report_name: "my_fsdb_report"}]
   #   report_configs: [{waveform_path: "/path/to/fsdb", inst: "ChipTop/system/tile_prci_domain/tile_reset_domain_tile", interval_size: "1ns", output_formats: ["plot_profile"]}]

hammer/config/defaults_types.yml

@@ -58,7 +58,7 @@ vlsi.technology:
 
   # Offset of the first column of tape cells from the edge of the floorplan
   # type: float
-  tap_cell_offset: float 
+  tap_cell_offset: float
 
   # Set the [bottom, top] layer used for routing. (Optional[Tuple[int, int]])
   routing_layers: Optional[list[int]]
@@ -105,7 +105,7 @@ vlsi.inputs:
     manual_placement_constraints: list[dict[str, list]]
 
     # Manual hierarchical constraints. Overrides generic constraints on a per module basis.
-    constraints: list[dict[str, list]]
+    constraints: list[dict[str, Any]]
 
   # ILMs for hierarchical mode.
   ilms: list[dict[str, str]]
@@ -160,9 +160,9 @@ vlsi.inputs:
     y: int
     # pitch (float) - pitch of bumps in microns
     pitch: float
-    # global_x_offset (float) - offset the bump map in the x-axis 
+    # global_x_offset (float) - offset the bump map in the x-axis
     global_x_offset: float
-    # global_y_offset (float) - offset the bump map in the y-axis 
+    # global_y_offset (float) - offset the bump map in the y-axis
     global_y_offset: float
     # cell (str) - Name of the default bump cell
     cell: str
@@ -283,7 +283,7 @@ par:
   # Spacing around blocks and hardmacros in microns
   blockage_spacing: float
 
-  # Ratio between the power blockage + place halo relative to route blockage. Route blockage should be smaller. 
+  # Ratio between the power blockage + place halo relative to route blockage. Route blockage should be smaller.
   power_to_route_blockage_ratio: float
 
   # Top metal layer that is pulled back around blocks and hardmacros

hammer/par/innovus/__init__.py

@@ -108,7 +108,7 @@ def fill_outputs(self) -> bool:
 
     @property
     def output_gds_filename(self) -> str:
-        return os.path.join(self.run_dir, "{top}.gds".format(top=self.top_module))
+        return os.path.join(self.run_dir, "{top}.gds.gz".format(top=self.top_module))
 
     @property
     def output_netlist_filename(self) -> str: