Change Request: Dynamically added TTC nodes should NOT be excluded from the CMake metadata.

[zero4ever30]

Hello

The XilTimer lib has the limitation that it supports only the first counter of the three counters that are available in each TTC (Triple Timer Counter) instance.

The reason is here!

lopper/lopper/assists/bmcmake_metadata_xlnx.py

Line 257 in 34acdb7

# Dynamically added TTC nodes should be excluded from the CMake metadata.

What is the reasoning to do this? ... please change it to also use the dynamically added TTC nodes

[zeddii]

@onkarharsh @sathishkumar-amd . any comments ?

[zero4ever30]

Is there any update?

[lakshmaiahm]

The SDT flow was intentionally aligned with the Vitis Classic flow tcl based behavior, which selects a TTC hardware block and always maps to counter 0.

If there is a requirement to expose all individual TTC counter instances as selectable options in the dropdown, we can enable that by removing the dynamic node exclusion.

[zero4ever30]

Yes please .. as we need the TTCs with different frequencies on multiple cores .. and we don't want two different cores controlling the same TTC counter.

[zeddii]

Had a proper look at the mechanics here.

lop-ttc-split.dts splits each TTC block into per-counter nodes: the original keeps counter 0, and two more are synthesized for counters 1 and 2 with their own sliced reg and interrupts, each tagged lop-dynamic-ttc-node. Two places then filter on that tag:

• bmcmake_metadata_xlnx.py:259 — keeps them out of the CMake metadata (the one you found)
• baremetal_gentestapp_xlnx.py:63 — keeps them out of test app generation

So the nodes are already fully formed in the DTS; they are only hidden from those two consumers. Exposing them is a small change at both sites rather than new splitting work.

The part that needs a decision rather than a patch is the consequence. TTCPS_NUM_DRIVER_INSTANCES would go from N to 3N and the instance indices shift, so an existing BSP that refers to a TTC by index would move under it. That is a compatibility call on the BSP flow, and it is not something we can validate from this repository.

@lakshmaiahm you offered to enable this — given the above, is the index shift acceptable for the BSP flow, or does it want to be opt-in so existing projects keep the current numbering? Happy to make the change either way once that is settled.

[zero4ever30]

I know the question is for @lakshmaiahm, but if i am allowed to add my 2 cents to this:

This depends on who the majority of the users use the BSP flow. Personally we use it on 5 out of six cores ... the sixth core is linux and we do add devices manually in the DT.

So any change in the numbering may mean an overlap between Linux and the FreeRTOS cores.

But if all your users use only the BSP-flow then this would be fine, as the change will be the same for all cores.

I would personally tend to make it opt-in, but still i am happy any way, as we really need this change.

Thank you

[lakshmaiahm]

Thanks @zeddii for looking into this.
After reviewing the generated BSP artifacts, I believe the index-shift risk is smaller than it first appears:

• xparameters.h already exposes all 12 TTC counter instances (XPAR_XTTCPS_NUM_INSTANCES = 12), and baremetalconfig_xlnx.py does not filter dynamic nodes, so there is no C-level breaking change.
• The exclusion in bmcmake_metadata_xlnx.py only impacts the CMake dropdown (for example, xiltimer sleep/tick timer selection), where TTCPS_NUM_DRIVER_INSTANCES currently lists only 4 entries (psu_ttc_0;psu_ttc_3;psu_ttc_6;psu_ttc_9).
• CMake selection is name-based (psu_ttc_0, psu_ttc_3...), not index-based, so existing selections should still resolve correctly once the list expands to 12.

Based on that, I think making it the default by removing the filter is fine, I’d recommend default-on.