Merge branch 'main' into feature/hw-vectorization-pass

Author: mafeguimaraes

.github/copilot-instructions.md

@@ -0,0 +1,20 @@
+# Copilot build & test guidance
+
+- Default to the integration docker image in `CIRCT_INTEGRATION_IMAGE` (set by the Copilot setup workflow and the `utils/run-docker.sh` default; currently `ghcr.io/circt/images/circt-integration-test:v19.2`) when compiling or testing.
+- Run inside that image via `./utils/run-docker.sh ./utils/run-tests-docker.sh "$CIRCT_INTEGRATION_IMAGE"` or `docker run` with the repo root bind-mounted.
+- When cloning or checking out, ensure submodules are present (`git submodule update --init --recursive` if needed).
+- Configure builds from the repo root with Ninja, matching the README:
+  ```
+  cmake -G Ninja llvm/llvm -B build \
+    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
+    -DLLVM_ENABLE_ASSERTIONS=ON \
+    -DLLVM_TARGETS_TO_BUILD=host \
+    -DLLVM_ENABLE_PROJECTS=mlir \
+    -DLLVM_EXTERNAL_PROJECTS=circt \
+    -DLLVM_EXTERNAL_CIRCT_SOURCE_DIR=$PWD \
+    -DLLVM_ENABLE_LLD=ON
+  ```
+- Build everything with `ninja -C build check-circt`; use `ninja -C build bin/circt-opt` or `ninja -C build bin/firtool` for tool-only builds.
+- Keep Python bindings enabled when needed via `-DMLIR_ENABLE_BINDINGS_PYTHON=ON -DCIRCT_BINDINGS_PYTHON_ENABLED=ON`.
+- For PyCDE and the ESI runtime, add `-DCIRCT_ENABLE_FRONTENDS=PyCDE -DESI_RUNTIME=ON` (keep Python bindings on). Test with `ninja -C build check-pycde` (PyCDE only) and `ninja -C build check-pycde-integration` (these integration tests exercise both PyCDE and the ESI runtime and are the only ESIRuntime tests).
+- Prefer the integration image and the setup steps workflow for reliable dependencies; only fall back to host builds when explicitly requested.

.github/workflows/copilot-setup-steps.yml

@@ -0,0 +1,28 @@
+name: Copilot setup steps
+
+on:
+  workflow_dispatch:
+  push:
+    paths:
+      - .github/workflows/copilot-setup-steps.yml
+
+permissions:
+  contents: read
+
+jobs:
+  copilot-setup-steps:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Pre-pull integration docker image
+        env:
+          CIRCT_INTEGRATION_IMAGE: ghcr.io/circt/images/circt-integration-test:v19.2
+        run: |
+          echo "CIRCT_INTEGRATION_IMAGE=$CIRCT_INTEGRATION_IMAGE" >> $GITHUB_ENV
+          docker pull "$CIRCT_INTEGRATION_IMAGE"
+      - name: Summarize defaults
+        run: |
+          {
+            echo "### CIRCT Copilot setup"
+            echo "- Integration image: $CIRCT_INTEGRATION_IMAGE"
+            echo "- Default build directory: build"
+          } >> "$GITHUB_STEP_SUMMARY"

.github/workflows/esiRuntimePublish.yml

@@ -17,8 +17,6 @@ jobs:
       fail-fast: false
       matrix:
         config:
-          - os: ubuntu-24.04
-            cibw_build: cp38-manylinux_x86_64
           - os: ubuntu-24.04
             cibw_build: cp39-manylinux_x86_64
           - os: ubuntu-24.04
@@ -29,8 +27,8 @@ jobs:
             cibw_build: cp312-manylinux_x86_64
           - os: ubuntu-24.04
             cibw_build: cp313-manylinux_x86_64
-          - os: windows-2022
-            cibw_build: cp38-win_amd64
+          - os: ubuntu-24.04
+            cibw_build: cp314-manylinux_x86_64
           - os: windows-2022
             cibw_build: cp39-win_amd64
           - os: windows-2022
@@ -41,6 +39,8 @@ jobs:
             cibw_build: cp312-win_amd64
           - os: windows-2022
             cibw_build: cp313-win_amd64
+          - os: windows-2022
+            cibw_build: cp314-win_amd64
 
     steps:
       - name: Get CIRCT
@@ -68,7 +68,7 @@ jobs:
           & "${env:VCPKG_INSTALLATION_ROOT}/vcpkg" --triplet x64-windows install zlib grpc
 
       - name: Install cibuildwheel
-        run: python -m pip install cibuildwheel==2.23.3
+        run: python -m pip install cibuildwheel==3.3.0
 
       - name: Build wheels
         if: runner.os != 'Windows'

README.md

@@ -54,7 +54,7 @@ For more information, please see our longer [charter document](docs/Charter.md).
 
 ## Getting Started
 
-To get started hacking on CIRCT quickly, run the following commands:
+To get started hacking on CIRCT quickly, run the following commands. If you want to include `circt-verilog` in the build, add `-DCIRCT_SLANG_FRONTEND_ENABLED=ON` to the cmake call:
 
 ```sh
 # Clone the repository and its submodules
@@ -69,14 +69,24 @@ cmake -G Ninja llvm/llvm -B build \
     -DLLVM_ENABLE_PROJECTS=mlir \
     -DLLVM_EXTERNAL_PROJECTS=circt \
     -DLLVM_EXTERNAL_CIRCT_SOURCE_DIR=$PWD
+    -DLLVM_ENABLE_LLD=ON
+```
 
-# Run the build
+If you want to build everything about the CIRCT tools and libraries, run below command(also runs all tests):
+```
 ninja -C build check-circt
 ```
 
-The above builds the CIRCT tools and libraries and runs all regression tests.
-If you want to include `circt-verilog` in the build, add `-DCIRCT_SLANG_FRONTEND_ENABLED=ON` to the cmake call.
-You can ask ninja to only build a specific library or tool, such as `ninja -C build circt-opt`.
+If you want to only build a specific part, for example the `circt-opt` tool:
+```sh
+ninja -C build bin/circt-opt
+```
+
+or the `firtool` tool:
+```sh
+ninja -C build bin/firtool
+```
+
 This will only build the necessary parts of LLVM, MLIR, and CIRCT, which can be a lot quicker than building everything.
 
 ### Dependencies

docs/Dialects/FIRRTL/FIRRTLAnnotations.md

@@ -1192,20 +1192,24 @@ Example:
 
 #### ExtractGrandCentralAnnotation
 
-| Property  | Type   | Description                                                  |
-| ---       | ---    | ---                                                          |
-| class     | string | sifive.enterprise.grandcentral.ExtractGrandCentralAnnotation |
-| directory | string | Directory where Grand Central outputs go, except a bindfile  |
-| filename  | string | Filename with full path where the bindfile will be written   |
+| Property  | Type   | Description                                                         |
+| ---       | ---    | ---                                                                 |
+| class     | string | sifive.enterprise.grandcentral.ExtractGrandCentralAnnotation        |
+| directory | string | Directory where Grand Central outputs go, except a bindfile         |
+| filename  | string | Optional filename with full path where the bindfile will be written |
 
 This annotation controls where to "extract" Grand Central collateral from the
-circuit.  This annotation is mandatory and can only appear once if the full
+circuit. This annotation is mandatory and can only appear once if the full
 Grand Central transform pipeline is run in the SFC.  (An error is generated by
 the `ExtractGrandCentralCode` transform.)
 
 The directory member has no effect on the filename member, i.e., the directory
 will not be prepended to the filename.
 
+The filename is optional. When specified, all binds will be emitted to that
+file. When omitted, each module will have an associated bindfile in `directory`
+named `<module>-bind.sv`.
+
 Example:
 ```json
 {

docs/Dialects/HW/RationaleHW.md

@@ -44,8 +44,7 @@ several major contributions:
  1) The `hw` dialect provides unifying structure and
     abstractions that are useful for a wide range of hardware modeling problems.
     It allows other dialects to "mix in" with it to provide higher level
-    functionality. `hw` is roughly akin to the "std" dialect in MLIR (but better
-    curated).
+    functionality.
  2) The `comb` dialect provides a common set of operations for combinational
     logic.  This dialect is designed to allow easy analysis and transformation.
  3) The `sv` dialect provides direct access to a wide variety

docs/GettingStarted.md

@@ -107,6 +107,8 @@ To get something that runs fast, use `-DCMAKE_BUILD_TYPE=Release` or
 you want debug info to go with it.  `Release` mode makes a very large difference
 in performance.
 
+To use the verilog frontend add `-DCIRCT_SLANG_FRONTEND_ENABLED=ON`.
+
 If you plan to use the Python bindings, you should also specify
 `-DCIRCT_BINDINGS_PYTHON_ENABLED=ON`.
 

docs/PythonBindings.md

@@ -107,7 +107,7 @@ Running this script through `python3 silicon.py` should print the following MLIR
 
 ```mlir
 module {
-  hw.module @magic(%a: i42, %b: i42) -> (c: i42) {
+  hw.module @magic(in %a: i42, in %b: i42, out c: i42) {
     %0 = comb.xor %a, %b : i42
     hw.output %0 : i42
   }

docs/VerilogGeneration.md

@@ -91,6 +91,9 @@ The current set of "tool capability" Lowering Options is:
    like `assert`, `assume`, and `cover` will always be emitted with a label. If
    the statement has no label in the IR, a generic one will be created. Some EDA
    tools require verification statements to be labeled.
+ * `disallowDeclAssignments` (default=`false`). If true, always emit assignments
+   (both continuous and blocking) separately rather than inlining them in net and
+   variable declarations.
 
 The current set of "style" Lowering Options is: