aboutsummaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorMartin Braun <martin.braun@ettus.com>2022-04-06 22:03:27 +0200
committerAaron Rossetto <aaron.rossetto@ni.com>2022-04-07 10:51:26 -0700
commit3930a6154730dd24e5bee9201ec301a49944b912 (patch)
treef2ff30fe029716a8e3a3c49fcfccfce4e08b4fa4 /tools
parent204c37faee0b55ec2f0e21899ebabbcdeb1f4440 (diff)
downloaduhd-3930a6154730dd24e5bee9201ec301a49944b912.tar.gz
uhd-3930a6154730dd24e5bee9201ec301a49944b912.tar.bz2
uhd-3930a6154730dd24e5bee9201ec301a49944b912.zip
rfnoc: Modify prop. propagation algorithm (back-edge resolution)
Previously, the property propagation algorithm would first forward and resolve properties only along forward edges. Then, we would check that properties also align across back-edges. The assumption is that graphs are always structured in a way such that back-edges would align when the resolution is done. However, for the following graph, this would fail: Radio ---> Replay ^ | +---------+ The reason is that the radio block and the replay block both have an "atomic_item_size" property, which needs to be resolved both ways. If the default atomic_item_size is 4 for the radio, and 8 for the replay block, then the input atomic_item_size on the radio will never be aligned with the output atomic_item_size of the replay block, and there is no other mechanism to align those. The solution is to run the edge property propagation and resolution twice, first for the forward edges, then for the back-edges. For graphs that would previously work, this makes no difference: The additional step of propagation properties across the back-edges will not dirty any properties. However, for graphs like the one above, it will provide an additional resolution path for properties that are otherwise not connected.
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions