Make ECON readout batched

[tvami]

Maybe this resolves #266 ?

Now the ECON class also does things in batches, I dont know if this makes sense, but like this it's more like how the ROC does it and certainly will be faster.

The following works:

[tamasvami@sdfiana007 pflib]$ time just _test -t "compile/single_register_econd"
cd build && denv ./test-pflib -t compile/single_register_econd
sed: can't read /usr/share/Modules/init/.modulespath: No such file or directory
Running 1 test case...

*** No errors detected

real	0m1.086s
user	0m0.195s
sys	0m0.703s

But we should test it in the real case too, so I'm opening this as a draft for now

[tvami]

I dont understand why the clang format brings in changes to a file I didnt touch at all
fce53f9

EDIT: nvm I understand now, it's that #275 was merged before the CI was run.

[tomeichlersmith]

I think this is great, I just want to test it with a real ECON - unfortunately, the tests run by just test cannot assume we have a connection set up and so they do not double check anything that attempts to talk to an actual board (like ECON's getRegisters).

[tvami]

I just want to test it with a real ECON

Yeah I'd love to do this today, let me know when we can do it together!

[tomeichlersmith]

@cmantill It looks okay to me, but I would like you to weigh in. This batching appears to make things faster when attempting to (for example) DUMP the entire ECON configuration, but I am unsure if it breaks anything.

[tomeichlersmith]

We ran the ECON.DUMP on the same ECON twice in a row. Once on my branch that has no difference between main within ECON and once on this branch.

econd_0_settings_20251121_093052.yaml - on branch with no difference in ECON with main
econd_0_settings_20251121_093114.yaml - on this branch

There are differences between these two DUMPs but I don't know if the parameters that are different are ones that change with time and wed expect them to be different.

[cmantill]

Looks good but I'd like to test it first

[cmantill]

I think this is breaking things - did you change anything in the ECON configuration between taking these DUMPs?

[tomeichlersmith]

I did not change anything but the ECON and ROCs were in RUNMODE

[tomeichlersmith]

Ok, as I said to @tvami - speeding up the application/reading of parameters is lower priority so if there is a hint of breaking things, then I am not going to merge this. I'm going to drop this back to draft and we can test it after things cool down.

[cmantill]

Yes, some read only parameters will change but your dump shows read/write parameters changing, so something is off.

[tvami]

@cmantill thanks for checking this! Can you point me to which of the parameters you are looking at to check this?

[cmantill]

For example:

<   GLOBAL_MATCH_PATTERN_VAL: 10760600711006082389
<   GLOBAL_ORBSYN_CNT_LOAD_VAL: 3514
<   GLOBAL_ORBSYN_CNT_MAX_VAL: 3563
<   GLOBAL_ORBSYN_CNT_SNAPSHOT: 3540
<   GLOBAL_ORBSYN_HDR_MASK: 0
<   GLOBAL_ORBSYN_HDR_VAL: 9
---
>   GLOBAL_MATCH_PATTERN_VAL: 267220985184256
>   GLOBAL_ORBSYN_CNT_LOAD_VAL: 1368
>   GLOBAL_ORBSYN_CNT_MAX_VAL: 3612
>   GLOBAL_ORBSYN_CNT_SNAPSHOT: 0
>   GLOBAL_ORBSYN_HDR_MASK: 14
>   GLOBAL_ORBSYN_HDR_VAL: 1

Actually, one thing that would be super useful to have is a standalone "TASK" that can test this. Could you write it? In it, attempt to read the following parameters:

• ALIGNER GLOBAL_MATCH_PATTERN_VAL
• ALIGNER GLOBAL_IDLE_HDR_VAL
• ALIGNER GLOBAL_ORBSYN_CNT_LOAD_VAL

And print the addresses that is trying to read as well as the full output from "getValues".

The last two registers should be contiguous but not the first one. I am wondering if there is something that is being broken by a continuous read that does not respect the boundary of registers.