abs-tudelft / tydi

Tydi: an open specification for complex data structures over hardware streams
https://abs-tudelft.github.io/tydi
Apache License 2.0
13 stars 6 forks source link

Flattening when both streams have user and/or keep properties #221

Open matthijsr opened 2 years ago

matthijsr commented 2 years ago

Background

When a Stream contains another Stream as its data, the Split function assigns both the parent and child streams "∅" (empty name), and employs "flattening" to combine their throughput, synchronicity, dimensionality and direction.

When a Stream has no element-manipulating data (data is either Null or a Stream) and no user property, it is discarded from the result. In effect, this creates a new physical stream with the original child Stream's data, combined with of the parent Stream's properties.

Issue

When keep (x) is true and/or user (T_u) is non-Null, the parent Stream must be retained.

If a parent Stream has keep=true and/or a non-Null user property, both Streams are still assigned "∅", but the parent Stream will conflict with the child Stream. Implementing the result of the Split function as a map in code, this means that either the child Stream simply replaces the parent Stream altogether (thereby losing the parent Stream's user property), or the Split function fails.

However, this behavior is not described in the specification, it only specifies that the names resulting from the Split function "are case-insensitively unique, emptyable strings consisting of letters, numbers, and/or underscores, not starting or ending in an underscore, and not starting with a digit" (emphasis mine).

Assumed/Suggested Fix

Right now, on an implementation level: The Split function should fail when it encounters a situation where two physical Streams have identical names.

On a specification level: It should be illegal for nested Streams (Streams which only have another Stream type as their data) to have a keep and/or user property on more than one of these Streams, and "flattening" should incorporate the singular user property into the resulting physical stream.

Alternatively, Streams should have a non-empty name property, as this will avoid conflicts in the result of the Split function.

matthijsr commented 2 years ago

Worth noting this also doesn't account for situations where a directly nested child Stream's synchronicity says to flatten its last signal, which would not have the context of its parent Stream.

(Another potential solution is to automatically give directly nested child Streams a name (e.g., __data or __child), when the parent Stream is retained.)