-
Notifications
You must be signed in to change notification settings - Fork 21
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
compiler cleanliness patches and incorporation of HLS APT #1470
Conversation
replace this with a while loop instead to be more clear about the possibility of rounding errors affecting performance
Canceled the PR Validation since I am just making sure this builds with warnings-as-errors. |
Is it because the branch Rory used was not rebased to the version of trunk that had my update for the CI? |
That's why I think this wasn't caught while test-building that branch, but I still don't know why this wasn't caught in previous rounds of more strict building since this code has been there for awhile. 🤷 Doesn't really matter, this is an easy fix. |
crap, this just revealed more issues https://github.com/LDMX-Software/ldmx-sw/actions/runs/10960598567/job/30435575518?pr=1470 the good news is that it builds and runs when not treating warnings-as-errors and so its not super urgent |
…umbering of digi collections
- update digis{1,2,3} collection variable names - remove useless (int) casts - remove unused int index = count variables
Some of the new stuff is in ldmx-sw/TrigScint/CMakeLists.txt Lines 32 to 37 in 5598eaa
it's resurfucing again |
I fixed up our internal stuff, all that's left is the HLS stuff.
which, as you point out @tvami , can probably be silenced by informing CMake that the HLS headers are not our problem. |
we include them as a SYSTEM include in central CMakeLists.txt and specifying them as SYSTEM informs CMake and its downstream compilers to avoid analyzing them since they aren't our problem
So in the end, this is not just something we can hide under the rug, there is some issue in the input in
the track level seems fine |
This gave me the idea to just use ldmx-sw/TrigScint/include/TrigScint/Firmware/objdef.h Lines 26 to 30 in 6c08a49
I /think/ this got past the error on my local computer so I'm pushing it here to double check. Edit: nevermind. This didn't work locally. |
I was thinking if we could just set the defaults it would fix it, but given that this is C-style, I dont think we can do that. I think having
would actually solve the problem, but we cant do that, right? |
I don't know if this code needs to be C-style or if that was just most convenient when trying to write the emulation. |
OK, I tried, it doesnt work anyway... :( |
I tried if getting rid of
|
And honestly I dont understand what's happening here
isnt |
A[i] is an alignment matrix. The idea is that the three layers (Pad1, Pad2, and Pad3) may be translated w.r.t eachother and said translation may be determined by the vector A as we only care how they are misaligned in one axis (the axis of granularity of the TS). The factor (i - A[1] + A[0]) only becomes nontrivial if A[1] and A[0] are different indicating an initially misaligned state. This will be important when we first start checking LDMX because if there is alignment issues we wont see it without scanning A. |
I see, thanks @rodwyer100 ! |
ehh
it doesnt like anything with |
hey @tomeichlersmith @rodwyer100 @bryngemark |
It should be okay to initialize it with certain values. I didn't understand your most current comment. Did that not work? |
Sorry now your second to most current. Edit: Ah I see. It doesn't like the ap_int<12> instantiation. I don't see why it wouldn't; Ill look at it but it should be allowed. |
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.
If pushed in some changes that I explored to fix the problem. Although they did not fix it, I think it still makes sense to have them in, and this PR could be a general fixup PR. I tagged Rory for some specific questions below.
Otherwise I think we should merge this, have a separate PR for the inclusion of the HLS stuff
for (int i = 0; i < NCENT; ++i) { | ||
for (int j = 0; j < COMBO; ++j) { | ||
for (int k = 0; k < 2; ++k) { | ||
LOOKUP[i][j][k] = ap_int<12>(0); |
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 hope putting this to zero is fine
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 clone this branch and check gimme a sec. The logic in the array does mean some default values will be bad, but 0 may be an okay one.
float one = (float)c.Pad1.Cent; | ||
float two = (float)c.Pad2.Cent; | ||
float three = (float)c.Pad3.Cent; | ||
float mean = (one + two + three) / 3.0; | ||
ap_int<12> Cent = (ap_int<10>)((int)(mean)); | ||
ap_int<12> Cent = (ap_int<12>)((int)(mean)); |
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 really think this should be as I change it, but please check
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 will not significantly affect the firmware part of this equation. If it agrees still on track positions, it will also work. I will clone this branch and check gimme a sec.
So something has been scrambled. I don't know which change did it, but I will need to inspect things before this gets commited. The track number distribution is very high; it is producing a high fake rate. |
Personally, I would rather keep a fork of HLS_arbitrary_precision and just redirect our submodule to our fork. Similar to G4DarkBreM, I just think there is a possibility that this code would be used in other applications (LDMX or not) and so keeping it separate would be helpful. |
but it's such a small repo... having it as a submodule has the advantage that if it changes we can just update it whenever we think it's needed. But this did not and does not change even when it should (see the PR from Shahzad a year ago). And then for your argument about using in other applications: for outside ldmx I doubt people would take an ldmx-sw fork instead of having their own fork. And then for inside ldmx, isnt that an argument to have it in our software directly? |
Yea.. you've convinced me I'll put them in Tools and update the CMake |
Tools/HLS_Arbitrary_Precision_Types/include/ap_impl/ap_private.h
Outdated
Show resolved
Hide resolved
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.
Nice! We are now back to be able to compile with the strict requirements. I hope Rory can find what change changed the track distributions
@rodwyer100 I am going to merge this even though it certainly contains the issues that you have observed just because there is a lot of code being introduced. I think your other PR #1473 can be a location for patches while you are introducing the hit stagger. |
I figured out what happened. Its a small change thats needed which won't change what was done. I will include it in my hit branch alongside a rebased branch |
replace this with a while loop instead to be more clear about the possibility of rounding errors affecting performance
For some reason, this only was shown on
trunk
after merging in unrelated (but in TrigScint?) code #1461 .Check List