-
Notifications
You must be signed in to change notification settings - Fork 0
Add energy monitor #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
JiacongSun
commented
Oct 7, 2025
- 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
There was a problem hiding this 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.
clmcsn
left a comment
There was a problem hiding this 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:
- Clarify in the RTL files under which cases they have been tested (both parameters setting and input stimuli) as a warning for future reuse.
- Trim and remove unused lines and unnecessary files (see comments)
- Add source files to the Bender.yml
- 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. | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 :))
There was a problem hiding this comment.
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. | |||
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
|
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. |