Tydi is an open specification for streaming dataflow designs in digital circuits, allowing designers to express how composite and variable-length data structures are transferred over streams using clear, data-centric types. These data types are extensively used in a many application domains, such as big data and SQL applications. This way, Tydi provides a higher-level method for defining interfaces between components as opposed to existing bit- and byte-based interface specifications. In this paper, we introduce an open-source intermediate representation (IR) which allows for the declaration of Tydi's types. The IR enables creating and connecting components with Tydi Streams as interfaces, called Streamlets. It also lets backends for synthesis and simulation retain high-level information, such as documentation. Types and Streamlets can be easily reused between multiple projects, and Tydi's streams and type hierarchy can be used to define interface contracts, which aid collaboration when designing a larger system. The IR codifies the rules and properties established in the Tydi specification and serves to complement computation-oriented hardware design tools with a data-centric view on interfaces. To support diferent backends and targets, the IR is focused on expressing interfaces, and complements behavior described by hardware description languages and other IRs. Additionally, a testing syntax for the verification of inputs and outputs against abstract streams of data, and for substituting interdependent components, is presented which allows for the specification of behavior. To demonstrate this IR, we have created a grammar, parser, and query system, and paired these with a backend targeting VHDL.
within digital circuits, designers have a choice to either
design their own interfaces, or use general interface
specifications such as Intel’s Avalon-ST [
data structures are represented, however, and as a result
designers must still design, document and share these
representations. Additionally, the IP integration tools are
proprietary, reducing the simplicity of integrating such
IPs outside of these specific tools. Addressing the first
issue, Peltenburg et al. proposed Tydi (Typed dataflow
interface) [
The goal of the IR is not to serve as a complete hardware description language, but to provide a simple and robust way to declare Tydi’s types, define interfaces and connect components which adhere to the Tydi specification, serving as part of a toolchain in order to integrate and reuse components within and across projects. To this end, the IR is not capable of directly implementing behavior, but should instead be combined with transactionlevel verification to specify intended behavior.
data streams [26], while synthesizing compilers such as
Optimus [
Stream processing There exist many projects to in- fers. As such, we propose a free, open-source IR for
defintroduce languages and frameworks for streaming data ing high-level streaming dataflow interfaces mapped onto
processing [
Design tools At the same time, there are multiple formation to the resulting interfaces. ongoing eforts to improve the tools used for designing such hardware accelerators, in the form of new hardware description languages [14, 15], intermediate representa- 4. Type Declarations and Interface tions [16] and compilers [17], high-level synthesis based Design on software programming languages [18], and more general program representations for heterogeneous systems 4.1. Type Hierarchy and Complex Data [19, 20]. Structures
Interfaces While improved languages and
frameworks can speed up design and improve reusability [15], The Tydi specification [
Tydi Working towards a full toolchain, there is a sep- a namespace.
arate project for a front-end and language for expressing In short, the Null type is for transfers of one-valued
behavior, called Tydi-lang. data (its only valid value is null), Bits(N) represents a
data signal of N bits, while the Group and Union types
contain fields consisting of a unique name and a logical
3. Motivation type. Groups and Unions are distinct in that Groups are
While much research is focused on developing and accel- composites of multiple types, where each field is set at
erating algorithms for streaming data in both hardware the same time, while Unions are exclusive disjunctions
[25, 19] and software [13], many designs for low-level of types, where only one field can be active at a time, to
hardware still have to transfer streams over interfaces be selected with a tag signal. Finally, the Stream type
which are either custom or based on generic, bit- and/or represents a new physical stream carrying these types.
byte-oriented specifications such as AXI4-Stream [
Some of this design efort can be alleviated through the types, Groups, Unions and Streams themselves can carry use of high-level synthesis: tools such as Vivado HLS can further nested logical Streams, each with their own data be employed to leverage C, C++ or SystemC combined and properties. with IP-blocks using ap_fifo or AXI4-Stream to handle The Stream type adds a further layer of flexibility to these types. It does not only represent the physical stream and signals carrying the element-manipulating types, but also features properties for further describing data structures. Notably, Streams have a dimensionality property, which indicates whether the data being transferred is part of a sequence. In hardware, this is translated to a “last” signal; when this signal is driven high, it indicates that the data being transferred is the last element in a sequence, and a Stream with a higher dimensionality will have multiple last signals, to indicate nested sequences.
In addition to dimensionality, Streams have properties for describing how transfers should be organized in space and time, as follows: asserted per transfer, and all data must be transferred over consecutive cycles and lanes. At complexity = 8, there are no requirements for how elements are aligned, transfers may be postponed (asserting valid low), and last data is asserted per lane, and may be postponed (using an inactive lane to assert last for a previous lane or transfer).
Valid Lanes H e l Time l o 0 Active Data
W o r Complexity = 1 Complexity = 8 l d 0..1 Inactive Data
- e H - - l l o 0 W
- l o - d r - 0..1 Last In Dimension…
No Transfer • Throughput is a positive, rational number indi- Figure 1: Streams determine which signals are used and cating how many elements are expected to be valid to organize elements in transfers, and how transfers are transferred per individual handshake, or relative organized over time. to its parent Stream. The number of element lanes is throughput rounded up to a natural number. Finally, in the event these properties are insuficient for • Direction indicates whether a Stream flows in the a use-case, Streams can also have a user signal carrying same direction as its parent, or in reverse. As an element-manipulating type. This user signal can be an example, a Group can have both a “Forward” used to provide additional information independent from and “Reverse” Stream, for indicating that interde- transfers or clock cycles. pendent data is transferred between the sink and source, such as a memory address and the data retrieved from that address. 4.2. Interfaces as Contracts • Synchronicity refers to how strong the relation 4.2.1. Communicating Intent between a child Stream and its parents are with regards to dimensional information. “Sync” indicates that for each element transferred on the parent, the child has a matching transfer, while “Desync” indicates that the child may have transfers of arbitrary size. Both options also have a “Flat” variant, which results in redundant last signals on the child being omitted. • Complexity is a number which encodes guarantees on how elements of a sequence are transferred. Overall, a lower complexity imposes more restrictions on a source, which conversely results in a higher complexity making it more dificult to implement a sink. As an example, a complexity of ≤ 2 requires that elements of an inner sequence are transferred over consecutive cycles by a source, while higher complexities allow it to stall independently from the sink. The speciifcation currently defines 8 levels of complexity [27]. • A keep property can be used to ensure a logical
Stream is synthesized into physical signals, as nested Streams may otherwise be combined into a single physical stream.
As the previous section would suggest, Tydi’s types can convey a significant amount of information; not just what data is transferred, but also how it is transferred, and how sequences of elements relate to one another. In efect, a suficiently detailed Stream definition can be treated as a contract between components (and in a sense, designers) on how a stream of data will be implemented.
The intermediate representation builds on this when declaring Interfaces. In its simplest form, an Interface represents a collection of ports on a component (Streamlet), each of which carries a logical Stream either into or out of the component.
However, each Interface and its ports may also feature documentation. Distinct from comments on a grammar, documentation is an actual property of a port or interface, and is expected to be implemented by a backend, typically by generating matching comments on the related output. Documentation being propagated from higher-level descriptions to the actual computation-oriented design tools that the IR complements is primarily useful when either implementing a component based on an interface template, or when trying to identify how physical signals relate to their abstract definition.
While Tydi’s Streams assume a single clock and reset signal, which together make up their clock and reset domain, regardless of how many physical streams they are composed of, the ports of an Interface do not need to rely on the same clock and reset signals. Instead, an
Figure 1 illustrates how a higher complexity allows for transfers to be organized diferently. When transferring [[H, e, l, l, o], [W, o, r, l, d]], at complexity = 1 all elements must be aligned to the first lane, last data is Interface may have one or more uniquely named domains later in Section 5.3, designers should generally strive for which represent a clock and reset signal, each of which a shared, normalized complexity between Streams. is associated with one or more of the Interface’s ports.
Subsequently, while the intermediate representation does not feature the ability to define a specific clock or 5. Component Composition and how a reset signal should be handled, designers can use Implementation these domains to ensure multiple clock and reset signals are available on a component, and that ports which be- In addition to Interfaces, the IR introduces the ability long to diferent domains are not directly connected. In to declare components, referred to as Streamlets. These the event no domain is specified on the Interface, a de- Streamlets consist of an Interface and optionally an Imfault domain is instead created and assigned to all ports, plementation. In efect, there are two diferent kinds as Tydi currently only defines Streams in the context of of Implementation for a Streamlet: a structural implea clock. mentation, which can be used to combine instances of streamlets into a larger design, and a link to an imple4.2.2. Notes on Interface Compatibility mentation of behavior in the target language or format. Streamlets are the intended output of a project; Types, The ports of Interfaces are compatible with one another Interfaces and Implementations are not expected to be when they have the same logical type, appropriate di- included in a backend’s emissions unless they are part of rections (for each physical stream, there is a source and a Streamlet, but can be shared between IR projects. matching sink), and the same clock domain. As Streamlets always have an Interface, they can be
Note that while types in the IR may be defined with subsetted to Interfaces, which can be used to express identifiers, these identifiers are not a property of the logi- alternate implementations of the same component, e.g. cal type in question, and only exist within the namespace. when versioning a component or when substituting one This choice was made to restrict the IR to properties de- for the purposes of testing as described in Section 6.2. ifned in the Tydi specification.
As a result, types with diferent names but otherwise identical properties are fully compatible; on an abstract 5.1. Structural Composition level, this can be interpreted as a kind of implicit casting As the goal of both Tydi and the IR is to improve compatbetween types. Although in our evaluation with respect ibility and reuse of primitive components, the IR features to readability of backend output, discussed in Section the ability to connect Streamlets to one another. The IR 8.2, and in light of the potential added value of a stricter refers to this as a Structural implementation. type system, we may reconsider this approach in the Structural implementations can contain instances of future. For instance, we may make identifiers an intrinsic Streamlets and connections between ports of Streamlets. property of types, and separately support type aliases for Instances consist of a local name and a reference to a functionality similar to the current behavior. Streamlet declaration, the ports of their interfaces are
However, while type identifiers are not currently rele- assigned separately through connections. vant to compatibility, field identifiers are an actual prop- Connections can be created between the ports of both erty of the Group and Union types. Hence, a Group(a: Streamlet instances and the containing Streamlet which Null) is not compatible with a Group(b: Null), re- is being implemented, and require both ports to have gardless of whether they are physically identical. identical types and clock domains (for the reasons de
Finally, while complexity is a property of the Stream scribed in Section 4.2.2). Connections are explicitly not type, the Tydi specification does conditionally allow “assignments”, as the direction of a port is already known, Streams with diferent complexities but otherwise iden- and there is not necessarily one overall direction for a tical properties to be connected. Specifically, a physical Stream type due to the possibility to define Streams which source stream may be connected to a sink if its complexity are Reversed (such as when representing request and reis equal to or lower than that of the sink. Note however sponse streams). Hence, the source and sink between two that this applies to physical streams: logical Streams do ports of a connection is determined during lowering for not have a notion of sinks and sources, and may contain each resulting Physical Stream. child Streams which flow in reverse directions, result- By default, the IR requires that each port of each ing in them containing both sink and source physical Streamlet is connected to exactly one other port. Leavstreams. ing ports unconnected is against the Tydi specification,
As such, the IR considers the Streams of ports incom- which requires that a default signal is driven for omitpatible when their complexity is not identical. While the ted signals [27]. While HDLs such as VHDL and Verilog process of connecting compatible physical streams can be support one-to-many and many-to-one connections at a optimistically automated to improve reuse, as discussed signal-level, these are not allowed by the IR due to the fact that ports represent Streams with handshake signals, 5.3. Intrinsics which would need to be combined.
While combining the ready signals of multiple sinks could be achieved with simple logical and expressions for a one-to-many connection, combining multiple transfers in a many-to-one connection has no clear, universally applicable solution. Even the aforementioned one-tomany implementation is not universal, as some designs may call for only one of the many to accept a transfer.
Finally, as a connection does not necessarily have a single direction, a one-to-many connection between ports may well contain physical many-to-one transfers.
expressing arbitrary functionality, we do recognize a subset of functionality useful for implementing Tydi-based components and streaming dataflow designs in general.
For general design, slices, bufers, and general-purpose stream manipulating components such as synchronizers are obvious candidates, while methods for optimistically connecting Streams with diferent complexities, or driving default or constant values to otherwise unconnected ports could help when reusing existing Streamlet designs.
Hence, we propose establishing a minimal, portable set of intrinsic functions, or intrinsics, to be implemented 5.2. Linked Implementations by any backend. Specifically, intrinsics should only cover The intermediate representation intentionally omits ex- commonly used, simple functionality which cannot be pressions for implementing or simulating arbitrary be- implemented by a library of fixed component designs; havior of components. Designing a language or set of ex- as an example, slices are commonly used and simple in pressions for functional hardware design and simulation both their functionality and implementation, but a fixed is a dificult problem which is already being addressed library cannot address each possible interface design. by many researchers and organizations, elaborated in Another useful kind of intrinsic or backend feature section 2. Instead, “behavioral implementations" in the would be one to improve readability and communicate IR exist only as links to directories, which contain the intent in the target language. For example, Tydi’s docrelevant code in languages more suited for expressing umentation mentions permitted alternative representabehavior. tions of interfaces [27], which can leverage data types
How these links are used is left up to the backend, and arrays to improve readability. These alternative repthough a simple use-case would be to create or copy a resentations could be automatically generated for empty ifle in the target output language based on the Stream- or template linked implementations by the backend, and let’s name. As these are directories, multiple such files wrapped in components using the conventional signals, can exist side-by-side for diferent targets, and implemen- clarifying the relation between signals and their logitations do not need to be constrained to a single file; a cal type definitions for designers working in the target linked directory could even be used to refer to a project or language. library consisting of multiple files, provided this exposes A broader kind of “intrinsic” would be features such as the Interface of the Streamlet being implemented. generic properties of types, and generating loops. Both
Figure 2 illustrates how linked implementations fit can be implemented as language features (either on the within a partial toolchain and workflow, consisting of intermediate language, or a front-end) and evaluated Streamlets, structural implementations and tests defined without the backend’s knowledge. However, by including in the IR, combined with behavior defined in a target these in the IR, backends for languages which adequately language (VHDL, in this example) by a suitable backend. support these features could propagate them directly. Not pictured are tools for simulating the testbenches produced by the backend, further passes on the output, 6. Specification nor any potential frontend language.
Declare Streamlets Documentation Backend Target (VHDL) Templates + documentation Implement Streamlets Connect Structural Streamlets Implementation
Linked Implementation
Implement behavior Behavioral description Specify behavior Tests Generate Testbench No Tests pass?
Yes Compile Output
6.1. High-level Assertions As the IR is used to represent ports consisting of Streams carrying logical types, it is best suited for transactionlevel verification. Inputs and outputs should be verified against abstract streams of data, upon which the IR combined with a backend will generate the necessary signalling behaviour and assertions. This enables designers to verify the behaviour of components and correctness of their interfaces without needing to concern themselves grammar also includes sequences of explicit stages; the with the target language. assertions within each stage still happen in parallel, but
There are two key properties to consider when design- each stage must successfully pass before the assertions ing and generating tests for Interfaces: in the next stage are performed: 1. Ports of an Interface are not required to be inter- sequence "sequence name" {
dependent or synchronized with one another. "icnoiutnitaelrs.ctoautne"t:={"0000"; 2. A port’s Stream does not necessarily have a single },co"iunnctreer.miennct"re:m{ent = "1"; direction, as child Streams can be Reversed. }, "result state": {
counter.count = "0001"; }, }; 6.2. Substitutions
the following properties: First, transaction verification on ports should be assumed to happen in parallel by default, rather than in the sequence assertions are declared. For example, implementing a Streamlet which adds two inputs could be represented as follows, assuming the output does not assert valid until it has received and added two inputs: adder.add = { in1: ("01", "01", "10"), in2: ("01", "00", "01"), out: ("10", "01", "11"),
many kinds of behavior, it cannot account for instances in which inputs and outputs are to be determined at runadder.out = ("10", "01", "11"); time, when a Stream features a user signal, or when the adder.in1 = ("01", "01", "10"); behavior of another dependency cannot be simulated for adder.in2 = ("01", "00", "01"); the purposes of an assertion. These cases can instead
Where ("10", "01", "11") represents a series of Bits(2) make use of the IR’s ability to quickly compose top-level to be transferred over a Stream without dimensionality. designs, provide multiple implementations for the same This is to be transferred depending on throughput; e.g., Interface, and subset Streamlets into Interfaces, as deone port could support two elements per transfer and scribed in Section 5. require only two transfers, while another might only When a dependency cannot be simulated, because it support one element per transfer and require three. In depends on specific hardware, for example, or when it this proposed syntax, square brackets would be used to has not been implemented yet, it can be substituted with indicate dimensionality: [["1", "0"], ["0"]] a stub or mock Streamlet. This way, the Streamlet under
Second, rather than explicit assign and compare meth- test can be verified independently. Such substitutes can ods, the IR should automatically determine whether phys- also be useful to support more complex test cases, by creical streams are sinks or sources. The latter property ating components which generate inputs and/or verify means that something closer to mathematical equality outputs. As a simple example, a random number genis implemented; “the transaction on port a is equal to erator component could be paired with a known-good, x”, whereupon it is automatically determined whether software-based adder to verify the results of an adder x should be driven, or observed and compared. Using hardware design. the same adder concept described before, but combin- Initially, these substitute components and designs ing them into a single Stream and port with a Reversed should be separated from the backend’s “proper” output child Stream to indicate a response, can be represented through namespaces, though we are actively considering as follows: making substitutions of Streamlet instances in structural implementations a part of the IR itself. This way, the IR and backend can ensure such explicit substitutions are only used for testing. };
Finally, while transactions on ports are not necessarily interdependent, it is reasonable to expect that they will be in many cases. While stateless behavior can be tested in parallel, as each transfer still requires a valid handshake, components which do observe state require that transactions on ports can be asserted in a specific sequence: A counter which accumulates based on input transfers and always drives its output with its current value, or an instruction for a state machine, require that the transfer on the input succeeds before the value on the output is tested. To this end, our design for the testing
In order to demonstrate the intermediate representation’s capabilities and evaluate various approaches, we implemented a prototype toolchain1. This toolchain consists of a query system for storing and retrieving the IR’s declarations and expressions on-demand, a preliminary grammar and parser which stores its results in the query system, and a backend which uses the query system and emits VHDL.
7.1. Query System emitted to VHDL using the backend described in the next subsection.
The first component of the prototype toolchain is the Namespaces are simple containers for other declaraquery system for storing and computing information of tions, their only innate property is their name, which the IR. The decision to use a query system rather than can be expressed as a path. Note that paths in this conmore traditional passes of compilation was inspired by text are purely abstract, and do not reflect any hierarchy work on the Rust compiler [28] and implemented using in the grammar or IR itself, they can simply be used to the Salsa framework [29]. The advantage of such a system communicate hierarchy to a backend, and/or propagate is that information can be retrieved or computed on- it from a front-end. demand, and the results of previously executed queries namespace example::name::space { tahreeiraudteopmenadtiecnaclliyessctohraendg,ea.nd only re-computed when } ... Path separator
The query system’s database stores type, Interface, The types described in Section 4.1 can be declared Streamlet, Implementation and Namespace declarations. using the type keyword, an identifier, and an expression. The primary output of the system as a whole is a simple Type expressions either reference these identifiers, or “all streamlets” query, which returns all Streamlet declara- directly describe the type’s properties. tions from a given input Project. Afterwards, a backend type identifier = Type Expression ; can use other queries, such as a query for splitting a identifier Null Bits(8) Stream into physical streams, for computing further de- Group(field_name: Type Expr., field2: ...) tails as needed. Union(field_name: Type Expr., ...)
Another use-case for the query system is the high- Stream(data: Type Expr., throughput: ...) level assertions described in Section 6.1; converting ab- Interfaces, as described in Section 4.2 are collections stract streams of data on a logical Stream into appropri- of ports and (clock and reset) domains. They can be ate, generic calls to the signals that make up its physical separately declared with an identifier, to enable reuse. streams. Through these functions, a backend would only interface identifier = Interface Expr. ; need to implement the methods for addressing physical identifier streams in order to support these complex, abstract as- (port_name: in Stream Type Expr., port2: out ...) sertions. These are still a work in progress, however, as <'domain, ...>(port_name: in Stream Type Expr. 'domain, ...) only methods for transfers on physical streams have been implemented thus far, and the means for declaring and converting transfers on logical Streams to these physical stream transfers have yet to be fully realized.
behavior, and structural implementations which connect Streamlets declared in the IR. This is elaborated on in Section 5. Links simply use double-quotes to enclose a path to a directory, while structural implementations features two expressions: One to create a Streamlet instance and connect the Interface’s domains, and another to connect ports between instances and/or the enclosing Streamlet. impl identifier = Implementation Expr. ; identifier "./path/to/directory" { 7.2. Grammar and Parser
of the IR in its own right, text-based representations are more portable and can allow for more flexible expressions. Furthermore, a purpose-built language reduces the amount of scafolding required when testing complete spyrostjeemctsminantuhaellIyR. , as compared to setting up the query } ipinansrstetanantnc_cepe_onr=atmie-d-<='ipnSastrtreaennatcm_eld_eontmaamIiedne.,innt'siitfnaisnetcrae;n_cpeo_rdto;m2 = 'parent_dom2>;
To this end, our prototype toolchain also features a simple grammar (referred to as Tydi Intermediate Lan- Streamlets are a combination of the expressions guage, or TIL) and parser, implemented using Chumsky above, and consist of an Interface and optionally an im[30]. Using the parser, a project expressed in TIL can be plementation. These are intended to be the output of a stored in the query system. TIL also served as a more backend. stable target for a front-end, computation-oriented lan- streamlet identifier = Interface Expr. Properties ; guage (called Tydi-lang) which was being developed in { impl: Implementation Expression, Optional parallel with the IR, as mentioned in Section 2. }
TIL features expressions for declaring namespaces, Finally, Documentation is expressed by enclosing types, Interfaces, Streamlets and Streamlet implementa- text with # signs, and must precede their subject, as tions, as well as some syntax sugar for subsetting Stream- shown in Listing 1. As explained in Section 4.2, documenlets into interfaces. This grammar has been fully imple- tation is distinct from comments in that it is an actual mented in the prototype toolchain, in that it can also be property of Streamlets, ports, and implementations.
Listing 1: Documentation Example #documentation (optional)# streamlet comp1 = ( // This is a comment a: in stream, b: out stream, #this is port documentation# c: in stream2, d: out stream2, );
7.3. VHDL Backend
to a hardware description, we include a VHDL backend as part of the prototype. As all concepts expressed in the IR would need to be emitted to VHDL, this allowed us to explore which properties were necessary or helpful for targeting hardware.
VHDL was chosen as the target because it is wellsupported by multiple toolchains for both synthesis and simulation, and simply because its syntax was most familiar to us. Similar methods as those for emitting VHDL can be employed when emitting other hardware description languages, such as Verilog, FIRRTL and LLHD.
The “passes” used when emitting to VHDL in this example backend are intentionally very simple (for instance, while namespaces could correspond to their own VHDL packages, all namespaces are instead combined into a single package), though they do leverage the the query system’s ability to incrementally compute and retrieve information:
is used to retrieve all the Streamlet declarations in the project. 2. For each Streamlet, the Streams that make up its Interface are split into physical streams, of which the signals are converted into ports. These ports make up a component with a unique name based on the Streamlet declaration and the namespace in which it was declared. These components are added to a single VHDL package. 3. For each Streamlet, an architecture declaration is either imported or generated: a) Streamlets without an implementation simply result in an empty architecture. b) Streamlets with a linked implementation are imported by looking for an appropriately named .vhd file at the given location, an empty architecture is generated at the location if no such file exists. c) Streamlets with a structural implementations result in a generated architecture in which port mappings represent Streamlet instances, and signals are used to connect the appropriate ports between instances and the enclosing Streamlet.
converted into comments, as shown in Listing 2.
-- documentation (optional) component my__example__space__comp1_com port ( clk : in std_logic; rst : in std_logic; a_valid : in std_logic; a_ready : out std_logic; a_data : in std_logic_vector(53 downto 0); b_valid : out std_logic; b_ready : in std_logic; b_data : out std_logic_vector(53 downto 0); -- this is port -- documentation c_valid : in std_logic; c_ready : out std_logic; c_data : in std_logic_vector(53 downto 0); d_valid : out std_logic; d_ready : in std_logic; d_data : out std_logic_vector(53 downto 0) ); end component;
8.1. Tydi Specification
tion to code, a few oversights and contradictions in the specification came to light. These issues have since been communicated to people working on the Tydi specification, and are being resolved. To accelerate work on the prototype, a few proposed changes have been employed. What follows is a selection of these issues (a), and their proposed solutions (b): 1. Directly nested Streams which must both be retained: a) If a Stream has a direct child Stream (as its data), and both have a user signal and/or keep enabled, it is impossible to create uniquely named physical streams for both. b) The prototype toolchain simply returns an error when such an event occurs. 2. Strobe assertions and start/end indices may conlfict: a) Physical streams at higher complexities will have strobe, and start/end index signals, to ensure compatibility with lower complexities. It is not specified which signals are significant: indices may indicate a diferent range of lanes is active than the strobe signal does. b) For our work on transfer-level verification, we assume that the start and end indices are only significant when all strobe bits are asserted active. 3. Element lanes cannot be marked inactive at lower complexities when dimensionality is 0: a) Tydi’s documentation on “signal omission” [27] suggests that the end index signal is contingent on complexity ≥ 5 or dimensionality > 0 and throughput > 1. This would result in Streams with multiple element lanes but no dimensionality and complexity < 5 being incapable of disabling element lanes. b) The toolchain assumes the end index signal is solely contingent on throughput > 1. 8.2. Readability To better enable such alternative representations, we are considering making changes to the IR to require type identifiers, rather than storing only the oficial properties of logical types as in Section 4.2.2. Doing so would allow a backend to generate alternative representations with meaningful type names, which could then be directly reused by multiple interfaces, albeit at the expense of being able to directly connect physically compatible types. 8.3. Hardware Description Efort
data structures more efectively than conventional HDLs.
As such, while “lines of code” is not an especially relevant
metric for an IR overall, it can be applied to the amount of
efort required to express interfaces and connections. To
evaluate the IR’s efectiveness in this regard, we declared
Tydi equivalents of the AXI4-Stream [
As the IR relies on other languages to express functional- type axi4stream = Stream ( ity, it will generally be necessary for the descriptions a datad:aUtna:ioBni(ts(8), backend does generate to be readable by designers, bar- null: Null, // Equivalent to TSTRB ring a frontend emitting both the IR and the behavioral t)h,roughput: 128.0, // Data bus width descriptions. To this end, our IR exposes “documenta- dimensionality: 1, // Equivalent to TLAST tion” to backends, enabling designers to propagate some scyonmcphlreoxniitcy:it7y,: /S/ynTc,ydi’s strobe is equivalent to TKEEP intent to component templates and interfaces. Our pro- user: Group ( totype VHDL backend propagates this documentation as TTDIED:STB:iBtis(t8s(),4), comments, and generates indented VHDL with port and TUSER: Bits(1), signal names derived from the TIL port and field names. ); ),
There is one area in which much information and readability is lost, however: The physical streams emitted by streaaxmil4esttreexaamm:pilne a=xi(4stream, the VHDL backend feature standard data and user signals as bit vectors, meaning that the names of element fields Listing 4: Result of Listing 3 in VHDL. of Groups and Unions are lost. As described in Section 5.3, the Tydi documentation describes alternative ways to aaxxii44ssttrreeaamm__vraelaiddy :: oiuntssttdd__llooggiic;c; represent physical streams to retain this information. For axi4stream_data : in std_logic_vector(1151 downto 0); instance, Groups and Unions could be expressed as record aaxxii44ssttrreeaamm__sltaasit :: iinn ssttdd__llooggiicc;_vector(6 downto 0); types in VHDL, multiple element lanes as arrays of the axi4stream_endi : in std_logic_vector(6 downto 0); base type, and even physical streams themselves could be aaxxii44ssttrreeaamm__sutsrebr :: iinn ssttdd__llooggiicc__vveeccttoorr((11227ddoowwnnttoo00);); collected into records (split into separate records for up and downstream signals). These are not only useful for Once a Stream type has been declared, it can be easily implementation, but can also provide more information reused for any number of ports, and ports only require when simulating a design. one expression (port_a −− port_b ; ) to connect, which is
In fact, the Implementations section of the original Tydi far fewer than the signals which make up a stream (or
paper [
Type Declaration 48* 59* 15*
Group with Reverse Streams for the Read Data and Response channels, depending on the use case. Both result in identical physical streams, but using multiple ports allows for them to be connected to diferent Streamlets if necessary. The table shows that the number of lines of code for a VHDL AXI4 equivalent representation is 28 compared to only a single line of code for TIL. In the same way, for AXI4 streams, 8 lines of code are required in VHDL compared to only 1 in TIL.
integrating components using the Tydi specification.
The Tydi-IR can be used to express how composite and variable-length data structures are transferred over streams using clear, data-centric types. These data types are extensively used in a many application domains, such as big data and SQL applications. The IR prototype toolchain used in this paper features the ability to eficiently express Tydi interfaces and connect components using a simple grammar, and emit these as VHDL components and architectures. We emphasize the ability to propagate high-level, abstract properties down from the IR (and any potential front-end) to the target language, to improve readability and more easily verify its outputs. As a result, we determined that emitting alternative representations for Tydi’s interfaces to retain type information could improve readability further, and identified potential changes to the IR to better enable this. The prototype toolchain also features initial work on high-level transaction-level verification to specify intended behavior, and a proposed syntax for such tests.
Examples show that while our IR requires only a single line of code to represent stream interfaces, an equivalent VHDL representation would require anywhere from 8 to 28 lines of code to describe the same interface. 10.1007/978-3-319-63962-8_196-1. doi:10.1007/ ples and Practice of Parallel Programming, PPoPP 978-3-319-63962-8_196-1. ’18, Association for Computing Machinery, New [11] J. Thomas, P. Hanrahan, M. Zaharia, Fleet: A Frame- York, NY, USA, 2018, pp. 68–80. URL: http://doi.org/ work for Massively Parallel Streaming on FPGAs, in: 10.1145/3178487.3178493. doi:10.1145/3178487. Proceedings of the Twenty-Fifth International Con- 3178493. ference on Architectural Support for Programming [21] Arm Limited, An introduction to AMBA AXI, 2021. Languages and Operating Systems, Association for URL: https://developer.arm.com/documentation/ Computing Machinery, New York, NY, USA, 2020, 102202/0200/. pp. 639–651. URL: http://doi.org/10.1145/3373376. [22] J. Pontes, R. Soares, E. Carvalho, F. Moraes, 3378495. N. Calazans, SCAFFI: An intrachip FPGA asyn[12] M. Fragkoulis, P. Carbone, V. Kalavri, A. Katsifodi- chronous interface based on hard macros, in: 2007 mos, A Survey on the Evolution of Stream Pro- 25th International Conference on Computer Decessing Systems, 2020. URL: http://arxiv.org/abs/ sign, IEEE, Lake Tahoe, CA, USA, 2007, pp. 541–546. 2008.00842. doi:10.48550/arXiv.2008.00842. URL: http://ieeexplore.ieee.org/document/4601950/. arXiv:2008.00842. doi:10.1109/ICCD.2007.4601950. [13] H. Isah, T. Abughofa, S. Mahfuz, D. Ajerla, F. Zulk- [23] Advanced Micro Devices, Inc., Intellectual Propernine, S. Khan, A Survey of Distributed Data erty, 2022. URL: https://www.xilinx.com/products/ Stream Processing Frameworks, IEEE Access intellectual-property.html. 7 (2019) 154300–154316. doi:10.1109/ACCESS. [24] Intel Corporation, 1. Introduction to Intel® FPGA 2019.2946884. IP Cores, 2021. URL: https://www.intel.com/ [14] J. Bachrach, H. Vo, B. Richards, Y. Lee, A. Waterman, content/www/us/en/docs/programmable/683102/ R. Avižienis, J. Wawrzynek, K. Asanović, Chisel: 21-3/introduction-to-cores.html.
Constructing hardware in a scala embedded lan- [25] T. Nowatzki, V. Gangadhar, N. Ardalani, K. Sankarguage, in: DAC Design Automation Conference alingam, Stream-dataflow acceleration, in: 2017 2012, 2012, pp. 1212–1221. doi:10.1145/2228360. ACM/IEEE 44th Annual International Symposium 2228584. on Computer Architecture (ISCA), 2017, pp. 416– [15] A. Izraelevitz, J. Koenig, P. Li, R. Lin, A. Wang, 429. doi:10.1145/3079856.3080255.
A. Magyar, D. Kim, C. Schmidt, C. Markley, J. Law- [26] Advanced Micro Devices, Inc., Interfaces for Vison, J. Bachrach, Reusability is FIRRTL ground: vado IP Flow • Vitis High-Level Synthesis User Hardware construction languages, compiler frame- Guide (UG1399) • Reader • Documentation Porworks, and transformations, in: 2017 IEEE/ACM In- tal, 2022. URL: https://docs.xilinx.com/r/en-US/ ternational Conference on Computer-Aided Design ug1399-vitis-hls/Interfaces-for-Vivado-IP-Flow. (ICCAD), 2017, pp. 209–216. doi:10.1109/ICCAD. [27] J. Van Straten, J. Peltenburg, M. Brobbel, Physical 2017.8203780. streams - Tydi, 2021. URL: https://abs-tudelft.github. [16] F. Schuiki, A. Kurth, T. Grosser, L. Benini, LLHD: A io/tydi/specification/physical.html.
Multi-level Intermediate Representation for Hard- [28] Rust Compiler Team, Queries: Demand-driven comware Description Languages, arXiv:2004.03494 pilation - Guide to Rustc Development, 2021. URL: [cs] (2020). URL: http://arxiv.org/abs/2004.03494. https://rustc-dev-guide.rust-lang.org/query.html. arXiv:2004.03494. [29] salsa-rs, Salsa, salsa, 2022. URL: https://github.com/ [17] LLVM Community, "CIRCT" / Circuit IR Compilers salsa-rs/salsa.
and Tools, LLVM, 2022. URL: https://github.com/ [30] J. Barretto, Chumsky, 2022. URL: https://github. llvm/circt. com/zesterer/chumsky. [18] R. Nane, V.-M. Sima, C. Pilato, J. Choi, B. Fort,
A. Canis, Y. T. Chen, H. Hsiao, S. Brown, F. Ferrandi, J. Anderson, K. Bertels, A Survey and Evaluation of FPGA High-Level Synthesis Tools, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 35 (2016) 1591–1604.
doi:10.1109/TCAD.2015.2513673. [19] F. Plavec, Stream Computing on Fpgas, Ph.D. thesis,
University of Toronto, CAN, 2010. [20] M. Kotsifakou, P. Srivastava, M. D. Sinclair, R. Komuravelli, V. Adve, S. Adve, HPVM: Heterogeneous parallel virtual machine, in: Proceedings of the 23rd ACM SIGPLAN Symposium on Princi