Skip to content

Conversation

@JiacongSun
Copy link
Contributor

  • Add energy monitor RTL and related submodule in a separate folder
  • Add related testbenches
  • Add the dtformat converter, the interface required by the analog island
  • Add dtformat converter testbench

@JiacongSun JiacongSun requested review from clmcsn and Copilot October 7, 2025 16:50
@JiacongSun JiacongSun self-assigned this Oct 7, 2025
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds a comprehensive energy monitor module for hardware implementation along with related testbenches and format converters. The implementation includes an energy calculation system that computes Hamiltonian energy for spin-weight matrices with bias terms and scaling factors.

  • Adds energy monitor RTL module with pipeline support and control logic
  • Implements testbenches for all energy monitor components and submodules
  • Adds dtformat converter for 2's complement to signed magnitude conversion

Reviewed Changes

Copilot reviewed 29 out of 29 changed files in this pull request and generated 9 comments.

Show a summary per file
File Description
hw/unit_tests/partial_energy_calc/ Testbench and build files for partial energy calculation module
hw/unit_tests/energy_monitor/ Comprehensive testbenches for the main energy monitor module
hw/unit_tests/dtformat_converter/ Testbench for data format conversion module
hw/unit_tests/adder_tree/ Testbench for adder tree summation module
hw/unit_tests/accumulator/ Testbench for accumulator module
hw/rtl/lib/bp_pipe.sv Backpressure pipeline module for configurable pipeline stages
hw/rtl/energy_monitor/ Core energy monitor RTL modules including control logic and computation units
hw/rtl/dtformat_converter.sv Data format converter from 2's complement to signed magnitude
ci/ut-run.sh Fix for GUI flag logic in test runner script
Comments suppressed due to low confidence (2)

hw/unit_tests/energy_monitor/README.md:1

  • Corrected spelling of 'Incrimental' to 'Incremental'.
# Energy Monitor Testbench

hw/unit_tests/accumulator/tb_accumulator.sv:1

  • Overflow detection logic is incorrect. Line 52 compares sign bits incorrectly - should compare accum_reg[ACCUM_WIDTH-1] == data_i[IN_WIDTH-1] since data_i has IN_WIDTH bits, not ACCUM_WIDTH.
// Copyright 2025 KU Leuven.

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Copy link
Collaborator

@clmcsn clmcsn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Jiacong,

before approval i would like you to:

  1. Clarify in the RTL files under which cases they have been tested (both parameters setting and input stimuli) as a warning for future reuse.
  2. Trim and remove unused lines and unnecessary files (see comments)
  3. Add source files to the Bender.yml
  4. Add energy monitor test to the ci pipeline every time we push to github. See if it is possible to trigger the test only if we change the files related to the block.

Thank youuu! Very good job!

@@ -0,0 +1,25 @@
// Copyright 2025 KU Leuven.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This module is too small: 1 assign block! (up to 10-15 lines, you should always put them inline, unless those 15 lines are a common block that is reused somewhere else)
You should just put it in the top module and comment with e.g. //bit selection mux logic

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The top module better not mix with the data processing part, right? It should keep a clear view of the architecture. Otherwise, it does not appear well-structured in terms of hierarchy.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree. You can have a look at bigger and more mature designs (from CVA6 core to ibex that are at industry standard level).

You put something in another file only if it is a major block or if it is a library component, but not a single assign line.

Nevertheless, you can keep it like this as you are the designer and it is fair to be your choice

// Accumulation test
// use random data, random valid signal and random enable signal
initial begin
wait (clear_test_done == 1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit hacky! You might want to use tasks for future tb, they are the same thing but you can call in one single initial block

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will keep it simple as this is a test for a leaf module.

// Testcases
// Test patterns for adder tree
logic signed [N*DATAW-1:0] test_a[NUM_TESTS] = '{
{N{8'sd0}}, // All zeros
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not the most extensive test, but OK for now. We can work on a more practical and automated way to test blocks. E.g., use some python scripts to generate random input vectors

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will keep it simple as this is a test for a leaf module.


module tb_adder_tree;

localparam int N = 256; // number of inputs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we have a different configuration?
Maybe add to the RTL blocks under which cases they have been tested (so we don't reuse them in other cases :))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will keep it simple as this is a test for a leaf module.

@@ -0,0 +1,363 @@
// Copyright 2025 KU Leuven.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The testing procedure should be a bit more structured:

  • Smoke test (simple input)
  • Corner case (trigger special behavior)
  • Random heavy testing (100 is not enough, you should go for 1 million!)

Each test should be contained in a separate file and easily inspectable by eye to verify its solidity.
This should also be the case for the correctness check routines. I would finally write this in even another language (e.g., Python) to ensure even more that we are doing something that makes sense.
I am not asking to change it, but I would like to start a better way to test that will make our lives easier as well (tb are a pain)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good advice. To be done after finishing the entire RTL.

@JiacongSun
Copy link
Contributor Author

In the current version, energy_monitor's state machine is updated so that the weight fetching and computation happen in parallel. Now for #spins=256, it takes 256+1 cycles (extra one for spin fetching).

The tb has been fixed and a random test with 1_000_000 test cases have been verified successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants