diff --git a/ai_assistant_sample/ai_assistant.py b/CGRA-Flow-sample/ai_assistant.py similarity index 94% rename from ai_assistant_sample/ai_assistant.py rename to CGRA-Flow-sample/ai_assistant.py index 538c4f5..587f989 100644 --- a/ai_assistant_sample/ai_assistant.py +++ b/CGRA-Flow-sample/ai_assistant.py @@ -52,14 +52,20 @@ 7. If goal is 'low_power': prefer smaller area, lower memory usage, balanced FU count. ## Available FU Types (for tile configuration): -- Compute: add, mul, div, shift, logic -- Floating-point: fadd, fmul, fdiv, fmul_fadd, fadd_fadd, vfmul -- Control: cmp, sel, phi, loop_control -- Memory: mem, mem_indexed, constant -- Other: return, grant, alloca, type_conv +- Integer Arithmetic: alu (add/sub), mul, div, shift, mac +- Logic: logic (and/or/not/xor), cmp (icmp/fcmp), sel +- Floating-point: fadd, fmul, fdiv, fmul_fadd, fadd_fadd +- Memory: mem (load/store), mem_indexed, alloca, gep, memset +- Type: type_conv, constant +- Control: phi, return, branch, loop_control +- Data Movement: data_mov, ctrl_mov, reserve, data +- Grants: grant +- Vector: vadd, vmul, vfmul, vector IMPORTANT: By default, all FU types should be enabled in every tile whenever we design a CGRA. -The full FU list is: ["add", "mul", "div", "fadd", "fmul", "fdiv", "logic", "cmp", "sel", "type_conv", "vfmul", "fadd_fadd", "fmul_fadd", "loop_control", "phi", "constant", "mem", "mem_indexed", "shift", "return", "alloca", "grant"] +The full FU list is: ["alu", "mul", "div", "shift", "mac", "logic", "cmp", "sel", "fadd", "fmul", "fdiv", "fmul_fadd", "fadd_fadd", "mem", "mem_indexed", "alloca", "gep", "memset", "type_conv", "constant", "phi", "return", "branch", "loop_control", "data_mov", "ctrl_mov", "reserve", "data", "grant", "vadd", "vmul", "vfmul", "vector"] +IMPORTANT: Use exactly these FU names. Do NOT use instruction names (e.g., use "alu" not "add", use "mem" not "load"). +For low_power designs, you may remove some FUs, but ALWAYS keep at minimum: alu, mul, cmp, sel, phi, constant, mem, gep, return, branch, data_mov, ctrl_mov, reserve, data, grant When recommending CGRA configurations, provide THREE options: @@ -72,7 +78,7 @@ "data_spm_kb": <4-64>, "multi_cgra_rows": <1-4>, "multi_cgra_columns": <1-4>, - "fu_types": ["add", "mul", "div", ...], + "fu_types": ["alu", "mul", "div", ...], "explanation": "" }, "balanced": { @@ -82,7 +88,7 @@ "data_spm_kb": <4-64>, "multi_cgra_rows": <1-4>, "multi_cgra_columns": <1-4>, - "fu_types": ["add", "mul", ...], + "fu_types": ["alu", "mul", ...], "explanation": "" }, "low_power": { @@ -92,7 +98,7 @@ "data_spm_kb": <4-64>, "multi_cgra_rows": <1-4>, "multi_cgra_columns": <1-4>, - "fu_types": ["add", "mul", ...], + "fu_types": ["alu", "mul", ...], "explanation": "" } } @@ -127,18 +133,15 @@ # Kernel examples with DFG characteristics and recommended configurations ALL_FU_TYPES = [ - "add", "mul", "div", - "fadd", "fmul", "fdiv", + "alu", "mul", "div", "shift", "mac", "logic", "cmp", "sel", - "type_conv", - "vfmul", - "fadd_fadd", "fmul_fadd", - "loop_control", "phi", - "constant", - "mem", "mem_indexed", - "shift", - "return", "alloca", + "fadd", "fmul", "fdiv", "fmul_fadd", "fadd_fadd", + "mem", "mem_indexed", "alloca", "gep", "memset", + "type_conv", "constant", + "phi", "return", "branch", "loop_control", + "data_mov", "ctrl_mov", "reserve", "data", "grant", + "vadd", "vmul", "vfmul", "vector", ] RAG_KERNEL_DATABASE = { diff --git a/CGRA-Flow-sample/cases.txt b/CGRA-Flow-sample/cases.txt new file mode 100644 index 0000000..a7b3d62 --- /dev/null +++ b/CGRA-Flow-sample/cases.txt @@ -0,0 +1,30 @@ +# CtrlMemDynamicRTL +pytest ../mem/ctrl/test/CtrlMemDynamicRTL_test.py -xvs +# Tile translation. +pytest ../tile/test/TileRTL_test.py -xvs +# Controller +pytest ../controller/test/ControllerRTL_test.py -xvs +# CGRA template translation. +pytest ../cgra/test/CgraTemplateRTL_test.py -xvs +# TODO: Need to check vector/heterogneous modules exist in the generated Verilog. +# CGRA simulation/translation (including heterogeneous, kingmesh, vector). +pytest ../cgra/test/CgraRTL_test.py -xvs +# Ring network simulation. +pytest ../noc/PyOCN/pymtl3_net/ringnet/test/RingNetworkRTL_test.py +# CGRAs are interconnected with ring topology. The CGRA contains +# separate crossbars (for tiles and FUs), crossbar-based data memory (for multi-bank), and controller. +pytest ../multi_cgra/test/RingMultiCgraRTL_test.py -xvs +# Multi-cgra with mesh topology. +pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_verilog_homo_2x2_4x4 -xvs +# Const Queue +pytest ../mem/const/test/ConstQueueDynamicRTL_test.py -xvs +# Data Mem +pytest ../mem/data/test/DataMemControllerRTL_test.py -xvs +# MeshMultiCgraTemplateRTL Test +pytest ../multi_cgra/test/MeshMultiCgraTemplateRTL_test.py -xvs +# Generate FIR scalar .v file with explicit file & module names. +pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_fir_scalar_translation -xvs +# Generate FIR vector global reduce .v file with explicit file & module names. +pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_fir_vector_global_reduce_translation -xvs +# Generate 2x2 Systolic-array .v file with explicit file & module names. +pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_systolic_2x2_2x2_translation -xvs \ No newline at end of file diff --git a/CGRA-Flow-sample/gitmodules.txt b/CGRA-Flow-sample/gitmodules.txt new file mode 100644 index 0000000..d47d02f --- /dev/null +++ b/CGRA-Flow-sample/gitmodules.txt @@ -0,0 +1,27 @@ +[submodule "CGRA-Mapper"] + path = CGRA-Mapper + url = https://github.com/tancheng/CGRA-Mapper +[submodule "CGRA-Benchmark"] + path = CGRA-Benchmark + url = https://github.com/tancheng/CGRA-Benchmark +[submodule "VectorCGRA"] + path = VectorCGRA + url = https://github.com/tancheng/VectorCGRA.git +[submodule "mlir-cgra"] + path = mlir-cgra + url = https://github.com/tancheng/mlir-cgra.git +[submodule "tools/mflowgen"] + path = tools/mflowgen + url = https://github.com/tancheng/mflowgen.git +[submodule "tools/sv2v"] + path = tools/sv2v + url = https://github.com/zachjs/sv2v.git +[submodule "tools/cacti"] + path = tools/cacti + url = https://github.com/tancheng/cacti.git +[submodule "zeonica"] + path = zeonica + url = https://github.com/sarchlab/zeonica.git +[submodule "dataflow"] + path = dataflow + url = https://github.com/coredac/dataflow diff --git a/CGRA-Flow-sample/main.yml b/CGRA-Flow-sample/main.yml new file mode 100644 index 0000000..b0b1b0e --- /dev/null +++ b/CGRA-Flow-sample/main.yml @@ -0,0 +1,304 @@ +name: build + +on: + push: + branches: [ "master" ] + pull_request: + branches: [ "master" ] + +env: + # Customize the CMake build type here (Release, Debug, RelWithDebInfo, etc.) + BUILD_TYPE: Release + +jobs: + build: + # The CMake configure and build commands are platform agnostic and should work equally well on Windows or Mac. + # You can convert this to a matrix build if you need cross-platform coverage. + # See: https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix + runs-on: ubuntu-22.04 + strategy: + fail-fast: false + matrix: + python-version: ["3.9.20", "3.12.8"] + + steps: + - uses: actions/checkout@v3 + with: + submodules: true + + # Update references + - name: Git Submodule Update + run: | + git submodule update --init + + + - name: Install LLVM and Clang for CGRA-Mapper + run: | + dpkg -l | grep llvm + sudo apt-get purge llvm-13 + sudo apt-get purge llvm-14 + sudo apt-get purge llvm-15 + sudo apt-get -y update + sudo apt-get -y install cmake + sudo apt-get -y install llvm-12 llvm-12-dev llvm-12-tools clang-12 + sudo apt-get -y install build-essential + + - name: Configure CMake for CGRA-Mapper + run: cd CGRA-Mapper && mkdir build && cd build && cmake .. + + - name: Build for CGRA-Mapper + working-directory: ${{github.workspace}}/CGRA-Mapper/build + run: make + + - name: Test for CGRA-Mapper + working-directory: ${{github.workspace}}/CGRA-Mapper/test + run: sudo ln -sf /usr/bin/opt-12 /usr/bin/opt && source compile.sh + + - name: Set up Python ${{ matrix.python-version }} for VectorCGRA + uses: actions/setup-python@v3 + with: + python-version: ${{ matrix.python-version }} + - name: VectorCGRA Git Sumbodule Update + run: | + cd VectorCGRA + git submodule update --init + - name: Install Verilator for VectorCGRA + run: | + wget https://github.com/tancheng/pymtl-verilator/raw/master/verilator-travis-4.036.tar.gz + tar -C ${HOME} -xzf verilator-travis-4.036.tar.gz + echo "VERILATOR_ROOT=${HOME}/verilator" >> $GITHUB_ENV + echo "PYMTL_VERILATOR_INCLUDE_DIR=${HOME}/verilator/share/verilator/include" >> $GITHUB_ENV + echo "${HOME}/verilator/bin" >> $GITHUB_PATH + + - name: Check Verilator for VectorCGRA + run: | + echo ${VERILATOR_ROOT} + echo ${PYMTL_VERILATOR_INCLUDE_DIR} + verilator --version + + - name: Install dependencies for VectorCGRA + run: | + sudo apt-get install -y graphviz + sudo apt-get install git libffi-dev + python3 -m venv ${HOME}/venv + source ${HOME}/venv/bin/activate + pip install py==1.11.0 + pip install wheel + pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix + pip install hypothesis + pip install pytest + pip install py-markdown-table + pip install PyYAML + pip list + - name: Test with pytest for VectorCGRA + run: | + cd VectorCGRA + mkdir -p build && cd build + source ${HOME}/venv/bin/activate + pytest .. -v --tb=short + + + - name: Install dependencies for mflowgen + run: | + sudo apt-get install -y yosys + + - name: Build for mflowgen + working-directory: ${{github.workspace}}/tools/mflowgen + run: | + pip install -e . + + - name: Test for mflowgen + working-directory: ${{github.workspace}}/tools/mflowgen + run: | + mkdir build && cd build + mflowgen run --design ../designs/GcdUnit + make 3 + + - name: Build for cacti + working-directory: ${{github.workspace}}/tools/cacti + run: make + + + - name: Install dependencies for sv2v + run: stack upgrade + + - name: Build for sv2v + working-directory: ${{github.workspace}}/tools/sv2v + run: make + + + - name: Install dependencies for tkinter + run: | + sudo apt-get install python3-tk + source ${HOME}/venv/bin/activate + pip install pillow + + - name: Test for tkinter + working-directory: ${{github.workspace}}/ + run: | + mkdir build && cd build + source ${HOME}/venv/bin/activate + + dataflow: + runs-on: ubuntu-22.04 + + steps: + - uses: actions/checkout@v3 + with: + submodules: true + + - name: Git Submodule Update + run: | + git submodule update --init --recursive dataflow/ + + - name: Set up Python 3.11.13 for dataflow + uses: actions/setup-python@v4 + with: + python-version: "3.11.13" + + - name: Download pre-built LLVM for dataflow + env: + LLVM_RELEASE_URL: "https://github.com/tancheng/CGRA-Flow/releases/download/LLVM%406146a88/llvm-project-6146a88-prebuild.tar.xz" + run: | + mkdir -p ${{ github.workspace }}/llvm-project + wget ${LLVM_RELEASE_URL} + tar -xJf llvm-project-6146a88-prebuild.tar.xz -C ./llvm-project + rm llvm-project-6146a88-prebuild.tar.xz + + - name: Install dependencies for dataflow + run: | + sudo apt-get update + sudo apt-get install -y ninja-build graphviz + + - name: Build dataflow + working-directory: ${{github.workspace}}/dataflow + run: | + mkdir -p build && cd build + cmake -G Ninja .. \ + -DCMAKE_PREFIX_PATH=${{github.workspace}}/llvm-project \ + -DCMAKE_CXX_FLAGS="-std=c++17" + ninja + + - name: Install NumPy 1.x for torch-mlir + run: pip install "numpy<2.0" + + - name: Install PyTorch + run: | + wget https://github.com/llvm/torch-mlir/releases/download/snapshot-20231229.1067/torch-2.2.0.dev20231204+cpu-cp311-cp311-linux_x86_64.whl + pip install torch-2.2.0.dev20231204+cpu-cp311-cp311-linux_x86_64.whl + + - name: Install torch-mlir + run: | + wget https://github.com/llvm/torch-mlir/releases/download/snapshot-20231229.1067/torch_mlir-20231229.1067-cp311-cp311-linux_x86_64.whl + pip install torch_mlir-20231229.1067-cp311-cp311-linux_x86_64.whl + + - name: Run dataflow tests + working-directory: ${{github.workspace}}/dataflow + run: | + pip install lit + export PATH="${{github.workspace}}/llvm-project/bin:$PATH" + echo $PATH + which llvm-extract + export TMPDIR="${{github.workspace}}/dataflow/test/e2e" + mkdir -p "${TMPDIR}" + cd ${{github.workspace}}/dataflow/test + lit . -v + + - name: Fix fir output (re-run fir_kernel after fir_vec) + working-directory: ${{github.workspace}}/dataflow + run: | + # fir_vec runs after fir and overwrites the output + # Re-run fir_kernel.mlir to restore the correct fir output + export PATH="${{github.workspace}}/llvm-project/bin:$PATH" + export TMPDIR="${{github.workspace}}/dataflow/test/e2e" + cd ${{github.workspace}}/dataflow/test + lit e2e/fir/fir_kernel.mlir -v + # Copy the newly generated FIR output to a deterministic location for downstream consumption + latest_dir="$(find "${TMPDIR}" -path "*fir_kernel.mlir.tmp.dir" -type d | sort | tail -n 1)" + if [ -z "${latest_dir}" ]; then + echo "Failed to locate fir_kernel.mlir.tmp.dir after rerun" >&2 + exit 1 + fi + mkdir -p "${TMPDIR}/fir" + cp "${latest_dir}/tmp-generated-instructions.yaml" "${TMPDIR}/fir/tmp-generated-instructions.yaml" + if [ -f "${latest_dir}/tmp-generated-instructions.asm" ]; then + cp "${latest_dir}/tmp-generated-instructions.asm" "${TMPDIR}/fir/tmp-generated-instructions.asm" + fi + + - name: Upload dataflow e2e outputs + uses: actions/upload-artifact@v4 + with: + name: dataflow-e2e + path: ${{github.workspace}}/dataflow/test/e2e + + zeonica: + needs: dataflow + runs-on: ubuntu-22.04 + + steps: + - uses: actions/checkout@v3 + with: + fetch-depth: 0 + submodules: false # Disable auto submodule checkout to manually configure URLs + + - name: Git Submodule Update (Zeonica) + run: | + # Update zeonica submodule only (skip nested Zeonica_Testbench submodule) + # CI reads YAML files from dataflow/test/e2e + git submodule update --init zeonica + + - name: Set up Go (for Zeonica) + uses: actions/setup-go@v5 + with: + go-version-file: zeonica/go.mod + cache: true + + - name: Download dataflow e2e outputs + uses: actions/download-artifact@v4 + with: + name: dataflow-e2e + path: ${{github.workspace}}/dataflow/test/e2e + + - name: Run testbenches from dataflow outputs (Zeonica) + working-directory: ${{github.workspace}}/zeonica + run: | + go mod download + WORKDIR="${{github.workspace}}/dataflow/test/e2e" + mapfile -t YAML_FILES < <(find "$WORKDIR" -name tmp-generated-instructions.yaml -print) + if [ "${#YAML_FILES[@]}" -eq 0 ]; then + echo "No tmp-generated-instructions.yaml found under $WORKDIR; skipping testbenches." + exit 0 + fi + for f in "${YAML_FILES[@]}"; do + kernel="$(basename "$(dirname "$f")")" + echo "=== Run testbench for kernel: $kernel ===" + case "$kernel" in + fir) + ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/fir -run TestFir + ;; + # histogram) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/histogram -run TestHistogram + # ;; + # axpy) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/axpy -run TestAxpy + # ;; + # bicg) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/bicg -run TestBicg + # ;; + # gemm) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/gemm -run TestGemm + # ;; + # gemv) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/gemv -run TestGemv + # ;; + # spmv) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/spmv -run TestSpmv + # ;; + # relu) + # ZEONICA_PROGRAM_YAML="$f" go test ./test/testbench/relu -run TestRelu + # ;; + *) + echo "Skip unknown kernel: $kernel" + ;; + esac + done diff --git a/ai_assistant_sample/mode_dark_light.py b/CGRA-Flow-sample/mode_dark_light.py similarity index 100% rename from ai_assistant_sample/mode_dark_light.py rename to CGRA-Flow-sample/mode_dark_light.py diff --git a/CGRA-Flow-sample/python-package.yml b/CGRA-Flow-sample/python-package.yml new file mode 100644 index 0000000..665f61f --- /dev/null +++ b/CGRA-Flow-sample/python-package.yml @@ -0,0 +1,160 @@ +# This workflow will install Python dependencies, run tests and lint with a variety of Python versions +# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python + +name: Python package + +on: + push: + branches: [ "master" ] + pull_request: + branches: [ "master" ] + +jobs: + build: + + runs-on: ubuntu-22.04 + strategy: + fail-fast: false + matrix: + python-version: ["3.9.20", "3.12.8"] + + steps: + - uses: actions/checkout@v3 + with: + # same as `git submodule update --init` to update submodules + submodules: recursive + - name: Set up Python ${{ matrix.python-version }} + uses: actions/setup-python@v3 + with: + python-version: ${{ matrix.python-version }} + + - name: Install Verilator + run: | + wget https://github.com/tancheng/pymtl-verilator/raw/master/verilator-travis-4.036.tar.gz + tar -C ${HOME} -xzf verilator-travis-4.036.tar.gz + echo "VERILATOR_ROOT=${HOME}/verilator" >> $GITHUB_ENV + echo "PYMTL_VERILATOR_INCLUDE_DIR=${HOME}/verilator/share/verilator/include" >> $GITHUB_ENV + echo "${HOME}/verilator/bin" >> $GITHUB_PATH + + - name: Check Verilator + run: | + echo ${VERILATOR_ROOT} + echo ${PYMTL_VERILATOR_INCLUDE_DIR} + verilator --version + + - name: Install dependencies + run: | + sudo apt-get install -y graphviz + sudo apt-get install git libffi-dev + python3 -m venv ${HOME}/venv + source ${HOME}/venv/bin/activate + pip install py==1.11.0 + pip install wheel + pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix + pip install hypothesis + pip install pytest + pip install py-markdown-table + pip install PyYAML + pip list + + - name: Install dependencies for sv2v + run: stack upgrade + - name: Build for sv2v + run: | + mkdir -p ${{github.workspace}}/tools && cd ${{github.workspace}}/tools + git clone https://github.com/zachjs/sv2v.git + cd sv2v + git checkout 9bab0448e32504cef764692018914f0f2f314911 + make + + - name: Install dependencies for mflowgen + run: | + wget https://github.com/YosysHQ/oss-cad-suite-build/releases/download/2024-09-20/oss-cad-suite-linux-x64-20240920.tgz + tar -C ${HOME} -xzf oss-cad-suite-linux-x64-20240920.tgz + export PATH="${HOME}/oss-cad-suite/bin:$PATH" + yosys -V + + - name: Build for mflowgen + run: | + mkdir -p ${{github.workspace}}/tools && cd ${{github.workspace}}/tools + git clone https://github.com/tancheng/mflowgen.git + cd mflowgen + pip install -e . + + - name: Test and translate with pytest + run: | + mkdir -p build && cd build + source ${HOME}/venv/bin/activate + # Simulation across all tests. + pytest .. -v --tb=short + # CtrlMemDynamicRTL + pytest ../mem/ctrl/test/CtrlMemDynamicRTL_test.py -xvs + # Tile translation. + pytest ../tile/test/TileRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # Controller + pytest ../controller/test/ControllerRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # CGRA template translation. + pytest ../cgra/test/CgraTemplateRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # TODO: Need to check vector/heterogneous modules exist in the generated Verilog. + # CGRA simulation/translation (including heterogeneous, kingmesh, vector). + pytest ../cgra/test/CgraRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # Ring network simulation. + pytest ../noc/PyOCN/pymtl3_net/ringnet/test/RingNetworkRTL_test.py + # CGRAs are interconnected with ring topology. The CGRA contains + # separate crossbars (for tiles and FUs), crossbar-based data memory (for multi-bank), and controller. + pytest ../multi_cgra/test/RingMultiCgraRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # Multi-cgra with mesh topology. + pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_verilog_homo_2x2_4x4 -xvs --test-verilog --dump-vtb --dump-vcd + # Const Queue + pytest ../mem/const/test/ConstQueueDynamicRTL_test.py -xvs + # Data Mem + pytest ../mem/data/test/DataMemControllerRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # MeshMultiCgraTemplateRTL Test + pytest ../multi_cgra/test/MeshMultiCgraTemplateRTL_test.py -xvs --test-verilog --dump-vtb --dump-vcd + # Generate FIR scalar .v file with explicit file & module names. + pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_fir_scalar_translation -xvs --test-verilog --dump-vtb --dump-vcd + # Generate FIR vector global reduce .v file with explicit file & module names. + pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_fir_vector_global_reduce_translation -xvs --test-verilog --dump-vtb --dump-vcd + # Generate 2x2 Systolic-array .v file with explicit file & module names. + pytest ../multi_cgra/test/MeshMultiCgraRTL_test.py::test_multi_CGRA_systolic_2x2_2x2_translation -xvs --test-verilog --dump-vtb --dump-vcd + + - name: Test synthesis for CGRA template + run: | + start_time=$(date +%s) + export PATH="${HOME}/oss-cad-suite/bin:$PATH" + cd build + cp CgraTemplateRTL__pickled.v design.v + export PATH="${{github.workspace}}/tools/sv2v/bin:$PATH" + ${{github.workspace}}/tools/sv2v/bin/sv2v design.v > design_sv2v.v + cp design_sv2v.v ${{github.workspace}}/tools/mflowgen/designs/cgra/rtl/outputs/design.v + cd ${{github.workspace}}/tools/mflowgen + mkdir -p build && cd build + mflowgen run --design ../designs/cgra + make 2 + make 3 + end_time=$(date +%s) + duration=$((end_time - start_time)) + echo "Synthesis step duration: $duration seconds" + if [ $duration -gt 900 ]; then + echo "ERROR: Synthesis step took longer than 15 minutes!" + exit 1 + fi + + - name: Use setup-verilator action + uses: veryl-lang/setup-verilator@v1 # Check the marketplace for the latest tag/version + with: + verilator-version: 'v5.026' # Specify the desired version + + - name: Test pure SV tb. + run: | + unset VERILATOR_ROOT + unset PYMTL_VERILATOR_INCLUDE_DIR + mkdir -p build && cd build + verilator --version + verilator --binary -j 0 -Wno-UNOPTFLAT -Wno-WIDTHEXPAND -Wno-TIMESCALEMOD --error-limit 1000 --trace --timing -I../multi_cgra/test/sv_test/ ./MeshMultiCgraRTL__explicit__pickled.v ../multi_cgra/test/sv_test/MeshMultiCgraRTL_2x2_fir_scalar_tb.v --top cgra_test + ./obj_dir/Vcgra_test + verilator --binary -j 0 -Wno-UNOPTFLAT -Wno-WIDTHEXPAND -Wno-TIMESCALEMOD -Wno-WIDTHTRUNC --error-limit 1000 --trace --timing -I../multi_cgra/test/sv_test/ ./MeshMultiCgraRTL__explicit_vector_global_reduce__pickled.v ../multi_cgra/test/sv_test/MeshMultiCgraRTL_2x2_fir_vector_global_reduce_tb.v --top cgra_test + ./obj_dir/Vcgra_test + verilator --binary -j 0 -Wno-UNOPTFLAT -Wno-WIDTHEXPAND -Wno-TIMESCALEMOD -Wno-WIDTHTRUNC -Wno-SELRANGE --error-limit 1000 --trace --timing -I../multi_cgra/test/sv_test/ ./MeshMultiCgraRTL__explicit_systolic_2x2_2x2__pickled.v ../multi_cgra/test/sv_test/MeshMultiCgraRTL_systolic_2x2_2x2_tb.v --top cgra_test + ./obj_dir/Vcgra_test + diff --git a/cgra-flow-docker/Dockerfile b/cgra-flow-docker/Dockerfile index fe9d247..3019b04 100644 --- a/cgra-flow-docker/Dockerfile +++ b/cgra-flow-docker/Dockerfile @@ -27,6 +27,7 @@ RUN apt-get update && apt-get install -y \ ccache \ git \ wget \ + curl \ graphviz \ make \ autoconf \ @@ -34,6 +35,8 @@ RUN apt-get update && apt-get install -y \ libfl-dev \ bison \ libffi-dev \ + libgmp-dev \ + libnuma-dev \ python3.12 \ python3.12-venv \ python3.12-dev \ @@ -115,8 +118,37 @@ RUN cmake -G Ninja .. \ WORKDIR /cgra -# Clone VectorCGRA -RUN git clone https://github.com/tancheng/VectorCGRA.git +# Clone VectorCGRA with submodules +RUN git clone --recursive https://github.com/tancheng/VectorCGRA.git + +# ============================================ +# Synthesis tools (oss-cad-suite, sv2v, mflowgen) +# These are required for the Report Area/Power synthesis flow. +# Installation order: heavy static tools first (better layer caching). +# ============================================ + +# Install oss-cad-suite (provides Yosys and related open-source EDA tools) +# Pinned to 2024-09-20 release for reproducibility — same version used in CI +RUN wget -q https://github.com/YosysHQ/oss-cad-suite-build/releases/download/2024-09-20/oss-cad-suite-linux-x64-20240920.tgz && \ + tar -C /cgra -xzf oss-cad-suite-linux-x64-20240920.tgz && \ + rm oss-cad-suite-linux-x64-20240920.tgz +ENV PATH="/cgra/oss-cad-suite/bin:${PATH}" + +# Install Haskell Stack — required to compile sv2v from source +# Uses upstream installer script; stack binary is placed in /usr/local/bin +RUN curl -sSL https://get.haskellstack.org/ | sh -s -- -d /usr/local/bin + +# Clone and build sv2v (SystemVerilog → Verilog converter) +# Pinned to commit 9bab0448 for reproducibility — same commit used in CI +RUN git clone https://github.com/zachjs/sv2v.git /cgra/sv2v && \ + cd /cgra/sv2v && \ + git checkout 9bab0448e32504cef764692018914f0f2f314911 && \ + stack setup && \ + make +ENV PATH="/cgra/sv2v/bin:${PATH}" + +# Clone mflowgen (ASIC flow manager) — installed as a Python package after venv is set up below +RUN git clone https://github.com/tancheng/mflowgen.git /cgra/mflowgen # Set up Python virtual environment and install dependencies RUN python3.12 -m venv /cgra/venv @@ -131,7 +163,15 @@ RUN pip install --upgrade pip && \ pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix && \ pip install hypothesis && \ pip install pytest && \ - pip install py-markdown-table + pip install py-markdown-table && \ + pip install pyyaml + +# Install mflowgen as a Python package using the already-cloned repo +# Must happen after the venv is activated so the correct pip is used +RUN pip install -e /cgra/mflowgen + +# Smoke-check: fail the Docker build early if any synthesis tool is missing +RUN yosys --version && sv2v --version && mflowgen --help > /dev/null # Set default working directory WORKDIR /cgra diff --git a/openspec/changes/add-verification-page-modules/.openspec.yaml b/openspec/changes/add-verification-page-modules/.openspec.yaml new file mode 100644 index 0000000..fd79bfc --- /dev/null +++ b/openspec/changes/add-verification-page-modules/.openspec.yaml @@ -0,0 +1,2 @@ +schema: spec-driven +created: 2026-03-02 diff --git a/openspec/changes/add-verification-page-modules/design.md b/openspec/changes/add-verification-page-modules/design.md new file mode 100644 index 0000000..7cbdc2e --- /dev/null +++ b/openspec/changes/add-verification-page-modules/design.md @@ -0,0 +1,68 @@ +## Context + +`VerificationTab.jsx` currently renders a static "Under Construction" placeholder. The verification stage is the final step in the CGRA workflow (after Design → Mapping), and users expect to review test results, inspect generated SVerilog, and examine area/power data there. This change delivers the UI scaffold for those three panels, with mocked/static data, so the layout and interaction patterns are established before backend integration. + +The project uses React 19 + MUI 7 with a tab-panel architecture. Other tabs (`MappingTab.jsx`, `DesignTab.jsx`) use a combination of MUI `Box`, `Paper`, `Typography`, and layout components — the same patterns apply here. + +## Goals / Non-Goals + +**Goals:** +- Replace the placeholder in `VerificationTab.jsx` with a three-panel layout +- Implement `TestsPanel`: list of test cases with status icons (pass/fail/pending) +- Implement `SverilogPanel`: read-only code viewer for SystemVerilog source +- Implement `ReportPanel`: area and power metrics in a structured table/card +- Use mocked static data for all panels (no API calls) +- Follow existing MUI + functional-component conventions + +**Non-Goals:** +- Backend integration or real data fetching +- Running actual tests from the UI +- Editing or downloading SVerilog source +- Exporting report data +- Playwright E2E tests for this change (UI-only, no functional behavior) + +## Decisions + +### Decision: Separate sub-components vs. inline in VerificationTab + +**Choice**: Extract each panel into its own file under `src/workspace/verification/`. + +**Rationale**: `MappingTab.jsx` is 400+ lines and already complex with inline sub-sections. Keeping each panel in its own file (`TestsPanel.jsx`, `SverilogPanel.jsx`, `ReportPanel.jsx`) makes future backend wiring straightforward — each file has a clear responsibility and a single import point. The change stays small and reviewable. + +**Alternative considered**: Inline everything in `VerificationTab.jsx`. Rejected because it creates a monolithic file and makes incremental backend addition harder. + +### Decision: Layout — vertical stack of collapsible panels + +**Choice**: Use MUI `Accordion` components stacked vertically, one per panel, with the first panel (`Tests`) expanded by default. + +**Rationale**: Three peer panels compete for vertical space. Accordions let the user focus on one panel at a time without scrolling. This mirrors patterns used in common IDEs and the existing Property Inspector sidebar. MUI `Accordion` is already available in the dependency set. + +**Alternative considered**: Fixed 3-column horizontal split. Rejected because SVerilog code and test lists are both tall content that reads poorly in narrow columns on typical monitor widths. + +### Decision: SVerilog display — `
` / monospace box, no syntax highlighter library
+
+**Choice**: Render SVerilog inside a scrollable MUI `Box` with `fontFamily: 'monospace'` styling and a dark background, with no third-party syntax highlighter.
+
+**Rationale**: Adding a syntax-highlighting library (e.g., `react-syntax-highlighter`, `shiki`) is a new dependency that requires team review. Since this is a UI-scaffold change with mocked data, a styled `
` block is sufficient to validate the layout without dependency risk.
+
+**Alternative considered**: `react-syntax-highlighter`. Deferred to a future backend-integration change.
+
+### Decision: Mocked data co-located in each panel component
+
+**Choice**: Each panel defines its own `MOCK_*` constant at the top of its file.
+
+**Rationale**: Keeps the mock easy to locate and replace when real data arrives. The mock shapes the component's prop interface, so when a parent passes real data the panel just needs a `data` prop swap.
+
+## Risks / Trade-offs
+
+- **Risk**: Accordion default-expand behaviour may feel unexpected if users expect all panels visible at once. → **Mitigation**: Default-expand "Tests" only; document in the component JSDoc that the expand state is uncontrolled and can be made controlled when data is wired up.
+- **Risk**: Monospace box without line numbers may be hard to navigate for long SVerilog files. → **Mitigation**: Acceptable for the mocked-data phase; add line numbers when real output is integrated.
+- **Trade-off**: Three new files adds a small directory to maintain, but the isolation benefit outweighs the overhead.
+
+## Migration Plan
+
+1. Create `src/workspace/verification/` directory
+2. Create `TestsPanel.jsx`, `SverilogPanel.jsx`, `ReportPanel.jsx` with mocked data
+3. Update `VerificationTab.jsx` to import and render all three panels inside MUI Accordions
+4. Verify visually via `npm run dev`
+5. No rollback concern — change is additive, placeholder is trivially restorable
diff --git a/openspec/changes/add-verification-page-modules/proposal.md b/openspec/changes/add-verification-page-modules/proposal.md
new file mode 100644
index 0000000..02369be
--- /dev/null
+++ b/openspec/changes/add-verification-page-modules/proposal.md
@@ -0,0 +1,31 @@
+## Why
+
+The Verification tab currently shows an "Under Construction" placeholder with no functional UI. Users completing a mapping workflow have no place to view test results, inspect generated SVerilog, or review area/power report data for their CGRA design. Adding structured UI panels to this tab makes the verification stage a first-class step in the workflow.
+
+## What Changes
+
+- Replace the placeholder content in `VerificationTab.jsx` with a three-panel layout
+- Add a **Tests** panel: displays a list of test cases with their pass/fail status indicators
+- Add a **SVerilog** panel: shows the generated SystemVerilog source in a read-only code viewer (syntax-highlighted)
+- Add a **Report Area/Power** panel: presents area and power metrics in a structured table or card layout
+- All panels are UI-only; data is static/mocked — no backend integration in this change
+
+## Capabilities
+
+### New Capabilities
+
+- `verification-tests-panel`: Test-case list UI inside the Verification tab, showing test names and pass/fail status
+- `verification-sverilog-panel`: Read-only SVerilog code viewer inside the Verification tab
+- `verification-report-panel`: Area and power metrics display panel inside the Verification tab
+
+### Modified Capabilities
+
+*(none — no existing spec-level requirements are changing)*
+
+## Impact
+
+- **Modified file**: `src/workspace/VerificationTab.jsx` — replaces placeholder with three-panel layout
+- **Possible new components**: `src/workspace/verification/TestsPanel.jsx`, `SverilogPanel.jsx`, `ReportPanel.jsx` (or inlined in VerificationTab)
+- **Dependencies**: MUI components already available; no new npm packages required
+- **No backend changes**, no API changes, no auth changes
+- **No breaking changes**
diff --git a/openspec/changes/add-verification-page-modules/specs/verification-report-panel/spec.md b/openspec/changes/add-verification-page-modules/specs/verification-report-panel/spec.md
new file mode 100644
index 0000000..5d31a82
--- /dev/null
+++ b/openspec/changes/add-verification-page-modules/specs/verification-report-panel/spec.md
@@ -0,0 +1,20 @@
+## ADDED Requirements
+
+### Requirement: Report panel displays area and power metrics
+The Verification tab SHALL include a Report Area/Power panel that presents CGRA area and power metrics in a structured table layout.
+
+#### Scenario: Report panel is visible on the Verification tab
+- **WHEN** the user opens the Verification tab
+- **THEN** the Report Area/Power panel SHALL be present as a collapsible accordion section with the title "Report Area/Power"
+
+#### Scenario: Metrics table renders rows for area and power
+- **WHEN** the Report panel is expanded
+- **THEN** the panel SHALL display a table with at least the following metric rows: Total Area, Cell Area, Net Area, Total Power, Dynamic Power, and Leakage Power
+
+#### Scenario: Each metric row shows a name and value
+- **WHEN** a metric row is rendered
+- **THEN** it SHALL display the metric name in the first column and the metric value (with unit, e.g. "µm²" or "mW") in the second column
+
+#### Scenario: Mocked data is shown when no real report is available
+- **WHEN** the Verification tab is opened without a completed synthesis run
+- **THEN** the Report panel SHALL still render with placeholder/mocked values rather than showing an error or empty state
diff --git a/openspec/changes/add-verification-page-modules/specs/verification-sverilog-panel/spec.md b/openspec/changes/add-verification-page-modules/specs/verification-sverilog-panel/spec.md
new file mode 100644
index 0000000..156d7ff
--- /dev/null
+++ b/openspec/changes/add-verification-page-modules/specs/verification-sverilog-panel/spec.md
@@ -0,0 +1,20 @@
+## ADDED Requirements
+
+### Requirement: SVerilog panel displays generated SystemVerilog source
+The Verification tab SHALL include an SVerilog panel that renders the generated SystemVerilog source code in a read-only, scrollable, monospace code viewer.
+
+#### Scenario: SVerilog panel is visible on the Verification tab
+- **WHEN** the user opens the Verification tab
+- **THEN** the SVerilog panel SHALL be present as a collapsible accordion section with the title "SVerilog"
+
+#### Scenario: Code is displayed in monospace font with dark background
+- **WHEN** the SVerilog panel is expanded
+- **THEN** the code content SHALL be rendered in a monospace font inside a dark-background scrollable container
+
+#### Scenario: Code is read-only
+- **WHEN** the user attempts to interact with the code viewer
+- **THEN** the content SHALL NOT be editable (rendered as `
` or equivalent non-editable element)
+
+#### Scenario: Long source scrolls vertically
+- **WHEN** the SVerilog content exceeds the panel's visible height
+- **THEN** a vertical scrollbar SHALL appear and the content SHALL be fully accessible by scrolling
diff --git a/openspec/changes/add-verification-page-modules/specs/verification-tests-panel/spec.md b/openspec/changes/add-verification-page-modules/specs/verification-tests-panel/spec.md
new file mode 100644
index 0000000..62db597
--- /dev/null
+++ b/openspec/changes/add-verification-page-modules/specs/verification-tests-panel/spec.md
@@ -0,0 +1,20 @@
+## ADDED Requirements
+
+### Requirement: Tests panel displays test case list
+The Verification tab SHALL include a Tests panel that renders a scrollable list of test cases. Each test case entry SHALL display the test name and a status indicator.
+
+#### Scenario: Test list renders with mocked data
+- **WHEN** the user opens the Verification tab
+- **THEN** the Tests panel SHALL be visible and expanded by default, showing at least one test case entry with a name and status icon
+
+#### Scenario: Passed test case appearance
+- **WHEN** a test case has status "pass"
+- **THEN** its status indicator SHALL use a green check-circle icon (MUI `CheckCircleIcon` with `color="success"`)
+
+#### Scenario: Failed test case appearance
+- **WHEN** a test case has status "fail"
+- **THEN** its status indicator SHALL use a red error icon (MUI `ErrorIcon` with `color="error"`)
+
+#### Scenario: Pending test case appearance
+- **WHEN** a test case has status "pending"
+- **THEN** its status indicator SHALL use a grey hourglass icon (MUI `HourglassEmptyIcon` with `color="disabled"`)
diff --git a/openspec/changes/add-verification-page-modules/tasks.md b/openspec/changes/add-verification-page-modules/tasks.md
new file mode 100644
index 0000000..22abdf2
--- /dev/null
+++ b/openspec/changes/add-verification-page-modules/tasks.md
@@ -0,0 +1,51 @@
+## 1. Directory & File Scaffold
+
+- [x] 1.1 Create directory `src/workspace/verification/`
+- [x] 1.2 Create empty file `src/workspace/verification/TestsPanel.jsx`
+- [x] 1.3 Create empty file `src/workspace/verification/SverilogPanel.jsx`
+- [x] 1.4 Create empty file `src/workspace/verification/ReportPanel.jsx`
+
+## 2. TestsPanel Implementation
+
+- [x] 2.1 Define `MOCK_TESTS` array in `TestsPanel.jsx` with at least 5 test cases covering `pass`, `fail`, and `pending` statuses
+- [x] 2.2 Implement the list layout using MUI `List` / `ListItem` components, one row per test case
+- [x] 2.3 Render status icon per test: `CheckCircleIcon` (success) for pass, `ErrorIcon` (error) for fail, `HourglassEmptyIcon` (disabled) for pending
+- [x] 2.4 Display test name as `Typography` `body2` next to the status icon
+- [x] 2.5 Make the list scrollable (set `overflow: 'auto'` and a `maxHeight` on the container)
+- [x] 2.6 Export `TestsPanel` as default export
+
+## 3. SverilogPanel Implementation
+
+- [x] 3.1 Define `MOCK_SVERILOG` string constant in `SverilogPanel.jsx` containing a representative multi-line SystemVerilog snippet (module declaration, ports, logic)
+- [x] 3.2 Render the code in a MUI `Box` with `component="pre"`, `fontFamily: 'monospace'`, dark background (`background: '#1e1e1e'`, `color: '#d4d4d4'`), and `overflow: 'auto'`
+- [x] 3.3 Set a fixed `maxHeight` (e.g., `400px`) so the panel doesn't expand infinitely
+- [x] 3.4 Confirm the container is non-editable (use `
` / `contentEditable` not set)
+- [x] 3.5 Export `SverilogPanel` as default export
+
+## 4. ReportPanel Implementation
+
+- [x] 4.1 Define `MOCK_REPORT_ROWS` array in `ReportPanel.jsx` with entries for: Total Area, Cell Area, Net Area, Total Power, Dynamic Power, Leakage Power — each with a `label`, `value`, and `unit` field
+- [x] 4.2 Render a MUI `Table` with two columns: "Metric" and "Value"
+- [x] 4.3 Map `MOCK_REPORT_ROWS` to `TableRow` elements; display `label` in column 1 and `${value} ${unit}` in column 2
+- [x] 4.4 Add a `TableHead` row with column labels ("Metric", "Value") styled with `fontWeight: 'bold'`
+- [x] 4.5 Wrap the table in `TableContainer` with `Paper` for visual grouping
+- [x] 4.6 Export `ReportPanel` as default export
+
+## 5. VerificationTab Integration
+
+- [x] 5.1 Import `Accordion`, `AccordionSummary`, `AccordionDetails`, and `ExpandMoreIcon` from MUI in `VerificationTab.jsx`
+- [x] 5.2 Import `TestsPanel`, `SverilogPanel`, and `ReportPanel` from the `./verification/` directory
+- [x] 5.3 Remove the existing placeholder (`ConstructionIcon` + Under Construction text)
+- [x] 5.4 Render three `Accordion` panels stacked vertically inside a scrollable `Box`:
+  - Accordion 1: summary "Tests", `defaultExpanded={true}`, content ``
+  - Accordion 2: summary "SVerilog", content ``
+  - Accordion 3: summary "Report Area/Power", content ``
+- [x] 5.5 Style each `AccordionSummary` title with `Typography variant="subtitle1" fontWeight="bold"`
+
+## 6. Visual Verification
+
+- [x] 6.1 Run `npm run dev` and open the app in a browser
+- [ ] 6.2 Navigate to the Verification tab and confirm all three accordions are visible
+- [ ] 6.3 Confirm "Tests" accordion is expanded by default on load
+- [ ] 6.4 Expand the SVerilog accordion and confirm monospace code is readable and scrollable
+- [ ] 6.5 Expand the Report accordion and confirm the two-column metric table renders correctly
diff --git a/openspec/changes/fix-ai-fu-types-mapping/.openspec.yaml b/openspec/changes/fix-ai-fu-types-mapping/.openspec.yaml
new file mode 100644
index 0000000..d1c6cc6
--- /dev/null
+++ b/openspec/changes/fix-ai-fu-types-mapping/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-02-27
diff --git a/openspec/changes/verification-report-area-power/.openspec.yaml b/openspec/changes/verification-report-area-power/.openspec.yaml
new file mode 100644
index 0000000..85cf50d
--- /dev/null
+++ b/openspec/changes/verification-report-area-power/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-03-03
diff --git a/openspec/changes/verification-report-area-power/design.md b/openspec/changes/verification-report-area-power/design.md
new file mode 100644
index 0000000..9a57ba3
--- /dev/null
+++ b/openspec/changes/verification-report-area-power/design.md
@@ -0,0 +1,99 @@
+## Context
+
+The Verification tab already supports two live job-driven flows (SVerilog generation, run-tests) that share a common pattern: submit a job to Supabase, subscribe to real-time row updates, render status in the UI. The `ReportPanel.jsx` exists but only shows hard-coded mock data.
+
+The synthesis pipeline (per `run_tests/python-package.yml` and `ai_assistant_sample/mode_dark_light.py`) is:
+
+1. Take `CgraTemplateRTL__pickled.v` produced by SVerilog generation.
+2. Convert it with **sv2v** → `design_sv2v.v`.
+3. Copy into mflowgen cgra design inputs, run `mflowgen run --design ../designs/cgra` then `make 2` (synthesis setup) and `make 3` (Yosys synthesis).
+4. Parse `3-open-yosys-synthesis/stats.txt` to extract tile area (`Chip area for module` line).
+5. Optionally run **CACTI** to estimate SPM area & power from a config template.
+
+None of the three synthesis tools (oss-cad-suite/Yosys, sv2v, mflowgen) are present in the Docker image today.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Real Synthesize button that runs the full synthesis flow end-to-end inside Docker.
+- Live progress bar (0–100 %) and elapsed-time counter updated from job `info`.
+- Display five metrics: Time cost, Tiles area (mm²), Tiles power, SPM area (mm²), SPM power (mW).
+- Install all required tools in the Docker image.
+- Reuse the existing Supabase job queue and realtime subscription infrastructure.
+
+**Non-Goals:**
+- Layout (OpenROAD) — that is a separate future panel.
+- Tile power from Yosys (Yosys cannot produce dynamic power; shown as `–`).
+- Supporting synthesis for designs other than `CgraTemplateRTL`.
+- Cancelling an in-flight synthesis job.
+- CACTI integration in the first iteration (SPM fields can show `–` until CACTI is added to Docker; see Open Questions).
+
+## Decisions
+
+### 1 — Reuse the existing job queue pattern, add interim `info` progress updates
+
+**Decision**: The executor writes incremental `info` patches to the Supabase `jobs` row at each milestone (e.g., `{ progress: 20, stage: "sv2v" }`). The frontend subscription already fires on every UPDATE; the panel reads `result.progress` and `result.stage` while `status === "running"`.
+
+**Alternative considered**: Server-Sent Events / WebSocket separate channel. Rejected — adds infrastructure complexity; Supabase realtime on the `jobs` row is already wired up and sufficient.
+
+### 2 — Synthesis input: use the verilog file from the most recent successful verilog-generation job
+
+**Decision**: The `synthesis` job payload carries `project_id`. The executor queries Supabase for the latest `verilog-generation` success job for that project and downloads `CgraTemplateRTL__pickled.v` (or `design.v`) from Supabase Storage into a temp directory. This avoids coupling the synthesis job to the SVerilog panel state.
+
+**Alternative considered**: Require the user to run SVerilog generation first and store the path in job info. Rejected — too fragile; the executor should self-heal by fetching the file directly.
+
+### 3 — Docker tooling installation strategy
+
+**Decision**:
+- **oss-cad-suite** (provides Yosys + supporting tools): download static binary tarball from GitHub releases into `/cgra/oss-cad-suite`; add to `PATH`.
+- **sv2v**: clone from `zachjs/sv2v`, checkout the pinned commit `9bab0448`, build with `stack`. Requires installing Haskell `stack` via `curl | sh`. This is slow but deterministic and matches the CI.
+- **mflowgen**: `pip install -e .` from a cloned copy of `tancheng/mflowgen` inside the Docker build; the cgra design files are part of VectorCGRA (already cloned). mflowgen is run from `/cgra/VectorCGRA` context.
+- **CACTI**: deferred (see Open Questions).
+
+**Alternative considered for sv2v**: Use a pre-built binary release. The release artifacts are not universally available for all Linux targets; building from source is safer for Ubuntu 24.04.
+
+### 4 — Progress milestones mapped to percentage values
+
+| Stage | Progress |
+|---|---|
+| Job starts | 0 % |
+| sv2v conversion done | 20 % |
+| mflowgen init (`make 2`) done | 50 % |
+| Yosys synthesis (`make 3`) done | 80 % |
+| Stats parsed, result written | 100 % |
+
+The executor does a Supabase `update` on the job's `info` column at each boundary. The frontend maps `result.progress` directly to the MUI `LinearProgress` value.
+
+### 5 — Frontend: optimistic elapsed-time counter via `setInterval`
+
+**Decision**: The frontend starts a `setInterval(1000)` when `status === "running"` and increments a local `elapsedSeconds` counter. It stops on job completion or error. This avoids depending on server-side timestamps for the UX counter.
+
+### 6 — Tile power shown as `–`
+
+Yosys provides area from `stats.txt` but no power. The result field `tilePower` is always `null`; the UI renders `–` with a tooltip: "Yosys does not provide dynamic power estimation."
+
+## Risks / Trade-offs
+
+- **sv2v build time in Docker** (~5–10 min): Mitigated by using Docker layer caching; sv2v is installed before VectorCGRA so the layer is reused on VectorCGRA updates.
+- **oss-cad-suite download size** (~1 GB): Accepted. It is a one-time Docker build cost.
+- **mflowgen cgra design path**: The design lives inside VectorCGRA at `VectorCGRA/` (or a subpath). The executor must resolve this dynamically from the container's clone location. Mitigation: hard-code `/cgra/VectorCGRA` as the mflowgen design root, add a health-check in the executor that fails early if the path is missing.
+- **Synthesis job duration** (~5–15 min): The frontend shows elapsed time and a spinner; users are warned via a tooltip. No timeout is enforced server-side in v1.
+- **Multiple simultaneous synthesis jobs**: Not guarded; the job queue processes one job at a time per runner instance, so concurrency is only a risk with multiple runners.
+
+## Migration Plan
+
+1. Update Dockerfile — install sv2v, oss-cad-suite, mflowgen; rebuild image.
+2. Add `synthesisExecutor.js` to the runner.
+3. Add `synthesis` case to `jobProcessor.js`.
+4. Add `submitSynthesisJob` to `verificationService.js`.
+5. Rewrite `ReportPanel.jsx` with live job subscription.
+6. No database migrations needed — `info` column is already JSONB.
+7. Smoke-test: submit a synthesis job manually via Supabase console; verify progress updates appear in the UI.
+
+**Rollback**: The old `ReportPanel.jsx` only showed mock data, so reverting the UI change has zero functional regression. The runner executor can simply be removed from `jobProcessor.js`.
+
+## Open Questions
+
+1. **CACTI**: Does the Docker build environment support CACTI's dependencies (gcc, make)? If yes, add CACTI in a follow-up. For v1, SPM fields show `–`.
+2. **mflowgen cgra design location**: Is it at `VectorCGRA/mflowgen/cgra` or elsewhere in the repo? Needs verification against the actual VectorCGRA submodule structure before coding `synthesisExecutor.js`.
+3. **Input verilog file name**: The pickled verilog file name may include a hash suffix (e.g., `CgraTemplateRTL__pickled.v`). The executor must glob for `CgraTemplateRTL__*pickled*.v` rather than use a fixed name.
diff --git a/openspec/changes/verification-report-area-power/proposal.md b/openspec/changes/verification-report-area-power/proposal.md
new file mode 100644
index 0000000..a329db7
--- /dev/null
+++ b/openspec/changes/verification-report-area-power/proposal.md
@@ -0,0 +1,30 @@
+## Why
+
+The "Report Area/Power" panel in the Verification tab currently displays hard-coded mock data, giving users no real insight into the synthesized area and power of their CGRA design. Real synthesis results (tile area from Yosys, SPM area/power from CACTI) are essential for design-space exploration and must be driven by the actual architecture configuration.
+
+## What Changes
+
+- Replace the static mock `ReportPanel.jsx` with a functional component that submits a `synthesis` job and streams results back in real time.
+- Add a `Synthesize` button, a linear progress bar (0–100 %), and a time-cost counter to the panel.
+- Display five result fields from the job output: **Time cost**, **Tiles area**, **Tiles power**, **SPM area**, **SPM power**.
+- Add a new `synthesis` job type to the runner's `jobProcessor.js` / `executeSynthesisJob` executor.
+- Extend `verificationService.js` with `submitSynthesisJob`.
+- Update the Docker image (`cgra-flow-docker/Dockerfile`) to install the tools required for synthesis: **oss-cad-suite** (Yosys), **sv2v** (SV → Verilog converter), and **mflowgen** (Python flow manager). CACTI is included for SPM estimation.
+- Extend the mflowgen `cgra` design inside VectorCGRA (or install it separately in Docker) so `make 2` and `make 3` execute correctly.
+
+## Capabilities
+
+### New Capabilities
+- `synthesis-job`: Backend job executor that runs the full synthesis flow (sv2v → mflowgen/Yosys → stats parsing) inside the Docker container, reports intermediate progress via job `info` updates, and returns tile area, tile power, SPM area, and SPM power in the final job result.
+- `report-area-power-ui`: Frontend React component (`ReportPanel.jsx`) that triggers a `synthesis` job, shows a live progress bar and elapsed-time counter, and renders the returned metrics in a structured table.
+
+### Modified Capabilities
+
+
+## Impact
+
+- **Frontend**: `src/workspace/verification/ReportPanel.jsx` — full rewrite; `src/workspace/services/verificationService.js` — add `submitSynthesisJob`.
+- **Runner**: `runner/jobProcessor.js` — add `synthesis` case; new file `runner/synthesisExecutor.js`.
+- **Docker**: `cgra-flow-docker/Dockerfile` — install oss-cad-suite, sv2v (requires `stack`/Haskell), and mflowgen; optionally CACTI for SPM.
+- **No database schema changes** — reuses the existing `jobs` table and `job.info` JSON field for progress and result.
+- **No breaking changes** to existing job types or UI panels.
diff --git a/openspec/changes/verification-report-area-power/specs/report-area-power-ui/spec.md b/openspec/changes/verification-report-area-power/specs/report-area-power-ui/spec.md
new file mode 100644
index 0000000..d68f125
--- /dev/null
+++ b/openspec/changes/verification-report-area-power/specs/report-area-power-ui/spec.md
@@ -0,0 +1,104 @@
+## ADDED Requirements
+
+### Requirement: Synthesize button is disabled until SVerilog generation is done
+The ReportPanel SHALL accept a `sverilogReady` boolean prop. The "Synthesize" button SHALL be disabled and show a tooltip `"Generate SVerilog first"` when `sverilogReady` is `false`. When `sverilogReady` is `true` and no synthesis job is in flight, the button SHALL be enabled.
+
+#### Scenario: SVerilog not yet generated
+- **WHEN** the ReportPanel renders with `sverilogReady = false`
+- **THEN** the "Synthesize" button is disabled and the tooltip text is `"Generate SVerilog first"`
+
+#### Scenario: SVerilog generated and no job in flight
+- **WHEN** the ReportPanel renders with `sverilogReady = true` and no synthesis job is running
+- **THEN** the "Synthesize" button is enabled
+
+#### Scenario: Job already in flight
+- **WHEN** a synthesis job is currently running
+- **THEN** the "Synthesize" button is disabled regardless of `sverilogReady`
+
+---
+
+### Requirement: Synthesize button submits a synthesis job and subscribes to updates
+When the user clicks "Synthesize" the panel SHALL call `submitSynthesisJob(projectId)` from `verificationService.js` and subscribe to the returned job ID via the existing `subscribeToJob` helper. The subscription SHALL remain active until the job reaches `status = 'success'` or `status = 'failed'`.
+
+#### Scenario: Button click triggers job submission
+- **WHEN** the user clicks "Synthesize"
+- **THEN** a new `synthesis` job row appears in Supabase with `status = 'queued'`
+
+#### Scenario: Subscription cleaned up on unmount
+- **WHEN** the component unmounts while a job is running
+- **THEN** the Supabase realtime subscription is unsubscribed
+
+---
+
+### Requirement: Progress bar reflects job progress
+The panel SHALL display a MUI `LinearProgress` component (determinate mode) whose `value` is derived from `job.info.progress` (0–100). While the job is in state `queued`, progress SHALL show 0. Between progress updates the bar SHALL remain at the last received value.
+
+#### Scenario: Job queued
+- **WHEN** the synthesis job is in `status = 'queued'`
+- **THEN** the progress bar shows 0 %
+
+#### Scenario: Intermediate progress update received
+- **WHEN** the job's `info.progress` changes to 50 via realtime update
+- **THEN** the progress bar renders at 50 %
+
+#### Scenario: Job succeeds
+- **WHEN** the job reaches `status = 'success'`
+- **THEN** the progress bar shows 100 %
+
+---
+
+### Requirement: Elapsed time counter increments while job is running
+The panel SHALL display an elapsed-time counter (in seconds, one decimal place) that starts at 0 when the job transitions to `status = 'running'` and increments every second via `setInterval`. The counter SHALL stop when the job reaches a terminal state (`success` or `failed`).
+
+#### Scenario: Counter starts on running state
+- **WHEN** the job status changes to `running`
+- **THEN** the time counter begins incrementing from 0 every second
+
+#### Scenario: Counter stops on success
+- **WHEN** the job status changes to `success`
+- **THEN** the time counter stops incrementing and displays the final elapsed time
+
+---
+
+### Requirement: Result metrics displayed in a structured table
+On job success the panel SHALL display a table with five rows:
+
+| Row label | Source | Unit |
+|---|---|---|
+| Time cost | `job.info.timeCost` | s |
+| Tiles area | `job.info.tileArea` | mm² |
+| Tiles power | always `–` | — |
+| SPM area | `job.info.spmArea` (or `–` if null) | mm² |
+| SPM power | `job.info.spmPower` (or `–` if null) | mW |
+
+Each row SHALL include a unit suffix next to the value. Null values SHALL render as `–`.
+
+#### Scenario: Tile area value displayed
+- **WHEN** the job result contains `tileArea = 1.23`
+- **THEN** the "Tiles area" row shows `1.23 mm²`
+
+#### Scenario: Tile power always dashes
+- **WHEN** the job result is displayed
+- **THEN** the "Tiles power" row always shows `–` with a tooltip `"Yosys does not provide dynamic power estimation"`
+
+#### Scenario: SPM fields null
+- **WHEN** `job.info.spmArea` and `job.info.spmPower` are both `null`
+- **THEN** both SPM rows show `–`
+
+---
+
+### Requirement: Error state displayed on job failure
+When the job reaches `status = 'failed'` the panel SHALL display a MUI `Alert` with severity `error` showing the `error_message` from the job row. The progress bar SHALL remain at its last value and the time counter SHALL stop.
+
+#### Scenario: Synthesis job fails
+- **WHEN** the job reaches `status = 'failed'` with `error_message = "SVerilog generation must be completed before synthesis."`
+- **THEN** an error alert is visible containing that exact message
+
+---
+
+### Requirement: VerificationTab passes sverilogReady to ReportPanel
+`VerificationTab.jsx` SHALL track whether a successful SVerilog generation result is available for the current project and pass it as the `sverilogReady` prop to `ReportPanel`. A result is considered available when the SverilogPanel has received a successful job completion during the current session or a cached verilog file URL exists in the job result for the project.
+
+#### Scenario: SVerilog panel completes successfully
+- **WHEN** the SverilogPanel receives a successful job result
+- **THEN** `sverilogReady` becomes `true` and the Synthesize button is enabled
diff --git a/openspec/changes/verification-report-area-power/specs/synthesis-job/spec.md b/openspec/changes/verification-report-area-power/specs/synthesis-job/spec.md
new file mode 100644
index 0000000..e23fba4
--- /dev/null
+++ b/openspec/changes/verification-report-area-power/specs/synthesis-job/spec.md
@@ -0,0 +1,93 @@
+## ADDED Requirements
+
+### Requirement: Synthesis job requires a prior successful SVerilog generation
+The system SHALL refuse to start a synthesis job if no successful `verilog-generation` job exists for the given project. The `synthesisExecutor` SHALL query Supabase for the latest `verilog-generation` job with `status = 'success'` for the project before proceeding. If none is found it SHALL mark the synthesis job as `failed` with the error message `"SVerilog generation must be completed before synthesis."`.
+
+#### Scenario: No SVerilog generation job exists
+- **WHEN** a `synthesis` job is claimed for a project that has never had a successful `verilog-generation` job
+- **THEN** the executor marks the job `failed` with error `"SVerilog generation must be completed before synthesis."`
+
+#### Scenario: SVerilog generation exists and succeeded
+- **WHEN** a `synthesis` job is claimed and the project has at least one `verilog-generation` job with `status = 'success'`
+- **THEN** the executor downloads the verilog artifact and continues with the synthesis pipeline
+
+---
+
+### Requirement: Synthesis job type is registered in the runner
+The runner's `jobProcessor.js` SHALL handle `job.type === 'synthesis'` by delegating to `synthesisExecutor.executeSynthesisJob(job)`.
+
+#### Scenario: Job dispatched correctly
+- **WHEN** a job with `type = 'synthesis'` is claimed from the queue
+- **THEN** `executeJob` calls `executeSynthesisJob(job)` without throwing an "Unknown job type" error
+
+---
+
+### Requirement: Synthesis executor reports intermediate progress
+The executor SHALL write incremental updates to the job's `info` column at each pipeline milestone so that the frontend can display a live progress bar.
+
+The mandatory progress milestones are:
+
+| Stage label | `progress` value |
+|---|---|
+| `"sv2v"` | 20 |
+| `"synthesis-init"` | 50 |
+| `"synthesis-run"` | 80 |
+| `"complete"` | 100 |
+
+Each update SHALL be a Supabase `UPDATE` on `jobs.info` with shape `{ progress: , stage: "