| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An RFNoC block (like the radio) might require a minimal number of
items in each clock cycle, e.g. the radio has to process
SPC (samples per cycle). Because data in RFNoC is transmitted and
processed in packets, we have to make sure the items inside these
packets are a multiple of the items processed in each cycle.
This commit adds an atomic item size properties which is set by
the radio and adapted by the streamers. The streamers adapt the
SPP property of the radio block controller depending on the MTU
value. This might lead to an SPP value which does not align with
the SPC value of the radio block, hence we add a property resolver
for the atomic item size.
|
