XCC

A Universal Communication Interface Composer for Heterogeneous Systems

Nikola Stojkov and Igor Dejanović
University of Novi Sad, Serbia

Zdravo svima, ja sam Nikola Stojkov dolazim iz Srbije, tacnije Novog Sada, PhD student sam na katedri za Racunarstvo i Automatiku univerziteta u Novom Sadu. Ko-autor na radu "Univerzalnog kompozera za komunikaciju u heterogenim sistemima" je bio i moj mentor Igor Dejanović koji je medju vama u publici. Pokazacemo vam razvijeni XCC alat koji omogućava dizajn komunikacije za heterogene sisteme.
Vreme: 30 sekundi

Hello everyone, I am Nikola Stojkov coming from Serbia, from city of Novi Sad. I'm a PhD student at the Department of Computing and Automation at the University of Novi Sad. My co-author on the "A Universal Communication Interface Composer for Heterogeneous Systems" paper is my advisor Igor Dejanović, who is among you in the audience. We'll show you the developed XCC tool which enables communication design for heterogeneous systems.
Time: 30 seconds

The Integration Challenge

Heterogeneous Systems with multiple CPU cores, accelerators, FPGA, and specialized processors

Fragmented Communication Design scattered across code, config files, and architectural diagrams

Multiple Teams & Platforms (Linux, RTOS, bare-metal) → inconsistent communication interfaces

Communication is critical but difficult to design systematically

Problem koji adresiramo jeste nekonzistentnost i otežana integracija softvera u heterogenim, asimetričnim multiprocesorskim sistemima, gde postoji komunikacija između particija. Ovakvi sistemi obuhvataju različite procesore, akceleratore i programabilnu logiku, a razvoj često sprovode različiti timovi koristeći različite platforme (Linux, RTOS, bare-metal). Kao posledica, komunikacioni interfejsi postaju nekonzistentni, a dizajn komunikacije fragmentiran - rasut po kodu, konfiguracijama i dijagramima. Time se javlja potreba za sistematskim, a ne ad-hoc pristupom dizajnu komunikacije, kako bi se obezbedila konzistentnost i stabilnost interfejsa čak i kada se arhitektura sistema menja ili evoluira na pojedinim platformama.
Vreme: 1 minut

The problem we address is inconsistency and difficult software integration in heterogeneous, asymmetric multiprocessor systems where communication exists between partitions. Such systems encompass different processors, accelerators, and programmable logic, and development is often conducted by different teams using different platforms (Linux, RTOS, bare-metal). As a result, communication interfaces become inconsistent, and communication design becomes fragmented—scattered across code, configurations, and diagrams. This creates a need for a systematic, rather than ad-hoc, approach to communication design, to ensure consistency and stability of interfaces even when the system architecture changes or evolves on individual platforms.
Time: 1 minute

Static vs. Dynamic Trade-off

Dynamic

Flexible for changes
Runtime overhead
Higher latency
Unpredictable

Static (Compile-time)

Optimizable
Low overhead
Predictable latency
Analyzable

✓ Desired: Static design with architectural flexibility

Ono sto se najcesce javlja jeste dilema između dinamičkog i statičkog dizajna komunikacije. Dinamička komunikacije je fleksibilna ali ima overhead i nepredvidivo ponašanje jer se u toku rada odlučuje o tome kako će se komunicirati pa sam tim dodaje kasnjenje i otežava analizu sistema. Statička komunikacija (kompajl-tajm) nema problem nepridvidivog ponašanja jer je sve poznato u vreme kompajliranja pa samim tim omogućava nizak overhead i predvidljivost ali je manje fleksibilna jer se sve mora znati unapred. XCC je dizajniran da premosti jaz između ove dve paradigme i omogući statički dizajn komunikacije ali da očuva arhitektonsku fleksibilnost.
Vreme: 1 minut

Dilemma between dynamic and static communication design is often discussed. Dynamic communication is flexible but has overhead and unpredictable behavior because decisions about how to communicate are made at runtime, which adds latency and complicates system analysis. Static communication (compile-time) doesn't have the problem of unpredictable behavior because everything is known at compile time, thus enabling low overhead and predictability, but it's less flexible because everything must be known in advance. XCC is designed to bridge the gap between these two paradigms and enable static communication design while preserving architectural flexibility.

XCC: The Solution

Domain-Specific Language (DSL) for systematic communication composition

OR UML Models via XMI import

Captures: Connectivity + Contracts + Profiles

Na slici mozemo videti block dijagram XCC alata. Korisnici mogu praviti dizajn komunikacije na dva načina: korišćenjem jezika specificnog za domen definisan za heterogene sisteme (DSL) ili importom UML modela putem XMI formata. DSL jezici koji se koriste su: ADL za opis arhitekture sistema, opis interfejsa za komunikaciju (IDL) i opis trasporta komunikacije (HML). XMI parser omogućava import UML modela iz alata poput Enterprise Architect, Modelio ili Papyrus dok ADL i Description parseri analiziraju specifikaciju izraženu kroz DSL jezike. Specifikacija modela se transformiše u jedinstveno apstraktno sintaksno stablo (XCC-AST), koje integriše sve informacije o sistemu i komunikaciji. Artifakti XCC alata ukljucuju mašinske i čitljive reprezentacije apstraktnog sintaksnog stabla (PKL i JSON fajlove) kao i dijagrame sistema arhitekture i povezanosti komponenti.
Vreme: 1 minut

In the picture we can see a block diagram of the XCC tool. Users can create communication design in two ways: by using a domain-specific language designed for heterogeneous systems (DSL) or by importing UML models via XMI format. The DSL languages used are: ADL for describing system architecture, IDL for describing communication interfaces, and HML for describing communication transport. The XMI parser enables importing UML models from tools like Enterprise Architect, Modelio, or Papyrus, while ADL and Description parsers analyze specifications expressed through DSL languages. The model specification is transformed into a unified abstract syntax tree (XCC-AST), which integrates all information about the system and communication. XCC tool artifacts include machine and human-readable representations of the abstract syntax tree (PKL and JSON files) as well as diagrams of system architecture and component connectivity.
Time: 1 minute

XCC: DSL Core Aspects

① Architecture Description (ADL)

Define system topology and component connectivity

② Interface Description (IDL)

Specify message formats, access control, and integrity

③ Hardware Mapping (HML)

Capture communication profiles and performance constraints

Da rezimiramo: 1. Kroz ADL jezik opisujemo arhitekturu tj topologiju sistema i povezanosti komponenti 2. Kroz IDL jezik opisujemo strukturu poruke koju razmenjuju komponente ukljucujuci sam pristup porukama i integritet 3. Kroz HML jezik opisujemo komunikacioni profil, resurse na raspolaganju, sinhronizaciju i performansna ograničenja i slicno. Sada ćemo detaljnije pogledati svaki od ovih jezika.
Vreme: 1 minut

To summarize: 1. Through the ADL language we describe the architecture, i.e., the topology of the system and component connectivity. 2. Through the IDL language we describe the structure of messages that components exchange, including message access and integrity. 3. Through the HML language we describe the communication profile, available resources, synchronization, and performance constraints, and so on. Now we'll look in more detail at each of these languages.
Time: 1 minute

Architecture Description (ADL)

Define system components and their communication topology

ADL (Architecture Description Language) omogućava definisanje topologije sistema kroz definisanje komponenti i njihovih povezanosti. Primer na slici pokazuje komponente Core 1 i Core 2 koje su povezane preko interfejsa ShmemInterface i profila SharedMemoryProfile. Ovo su samo nazivi koje korisnik kasnije dodefiniše kroz IDL i HML jezik. Povezanost komponenti je uvek u jednom smeru, što omogućava jasnu analizu toka komunikacije. Dvosmerna komunikacija se modeluje kroz dve veze u suprotnim smerovima. Korisnik sam može da definiše različite topologije sistema, da dodaje nove platforme, interfejse i profile a XCC će generisati AST pri transformaciji specifikacije.
Vreme: 1 minut

ADL (Architecture Description Language) enables the definition of system topology by specifying components and their connections. The example in the figure shows components Core1 and Core2 connected through the ShmemInterface and the SharedMemoryProfile. These are user-defined identifiers that are later refined through the IDL and HML languages. Component connections are always unidirectional, which allows clear analysis of communication flow. Bidirectional communication is modeled using two opposite-direction connections. Users can define arbitrary system topologies, add new platforms, interfaces, and profiles, and XCC generates the corresponding AST during specification transformation.
Time: 1 minute

Interface Definition (IDL)

Specify communication contracts and message structures

IDL (Interface Description Language) definiše sta komponente razmenjuju, koji je pristup porukama i integritet. Na primeru mozemo videti ShmemInterface koji koristi strukturu poruke SharedData, ima definisan pristup (read/write) i integritet crc32. Ovo osigurava konzistentnost interfejsa između različitih delova heterogenog sistema. Korisnik moze da definiše svoju biblioteku strukture podataka kroz IDDL fajlove koje se mogu ukljuciti u sam IDL opis i koristiti u opisu. Time korisnik moze da ima biblioteku poruka koje se mogu koristiti u razlicitim IDL opisima.
Vreme: 45 sekundi

IDL (Interface Description Language) defines what components exchange, how messages are accessed, and their integrity. In the example, ShmemInterface uses the SharedData message structure, specifies access mode (read/write), and defines integrity protection via CRC32. This ensures interface consistency across different parts of a heterogeneous system. Users can define their own data structure libraries through IDDL files, which can be included in the IDL specification and reused. This allows the creation of reusable message libraries shared across multiple IDL descriptions.
Time: 45 seconds

Hardware Modeling (HML)

Capture communication profiles and platform-specific performance constraints

HML (Hardware Mapping Language) opisuje hardverske karakteristike platforme, resurse na raspolaganju, sinhronizaciju i performansna ograničenja. Korisnik može da definiše različite platforme sa specifičnim resursima i karakteristikama komunikacije. Na primeru možemo videti SharedMemoryProfile koji ima definisane memorijske resurse i njihov pristup kao i nacin sinhronizacije. Isto tako korisnik moze da definise razne profile u brojnim HMML fajlovima koje se mogu ukljuciti u sam HML opis i koristiti u opisu, i time da gradi svoju biblioteku profila.
Vreme: 45 sekundi

HML (Hardware Mapping Language) describes platform-specific hardware characteristics, available resources, synchronization mechanisms, and performance constraints. Users can define multiple platforms with specific communication resources and properties. In the example, SharedMemoryProfile specifies memory regions, access attributes, and synchronization behavior. Users may also define multiple profiles in separate HMML files, include them in HML specifications, and build reusable profile libraries.
Time: 45 seconds

From Specification to XCC-AST

TextX syntax for DSL grammar • UML Tags mark XCC components

Na slici mozemo videti dva prikaza specifikacije - jedan je kroz DSL jezike koje smo spominjali, ono sto nisam naglasio jeste da se gramatika ovih jezika validara kroz TextX alat. Drugi prikaz je kroz UML model gde korisnici mogu da koriste standardne UML alate za modelovanje sistema uz koriscenje UML tagova kako bi oznacili komponentu, interfejs tj konekciju, strukturu podataka i profiil komunikacije. Obe specifikacije se transformišu u XCC-AST.
Vreme: 45 sekundi

In the picture we can see two representations of specification - one is through the DSL languages we mentioned, what I didn't emphasize is that the grammar of these languages is validated through the TextX tool. The other representation is through a UML model where users can use standard UML tools for system modeling using UML tags to mark a component, interface, connection, data structure, and communication profile. Both specifications are transformed into XCC-AST.
Time: 45 seconds

DSL Grammar Examples

ADL Grammar


							ComponentDef:
								name=ID ':' 'Component' '{'
									'Type' ':' type=ID ','
									'Platform' ':' platform=ID ','
									'Function' ':' function=ID
								'}'
							ConnectionDef: 
								'connection' name=ID '{'
									'from' src=[ComponentDef] 
									'to' dst=[ComponentDef]
									'interface' ':' interface=ID
									'profile' ':' profile=ID '}'

IDL Grammar


							Interface: 'interface' name=ID '{'
								data=DataStructures?
								access=Access
								integrity=Integrity? '}'
							StructDef: 
								name=ID '{' fields+=Field* '}'
							Field: 
								type=Type name=ID array=ArraySpec?
							Access: 'access' '{'
								(readLines+=ReadAccess | 
								writeLines+=WriteAccess)+ '}'

HML Grammar


								SharedMemory:
									'SharedMemory' name=ID? '{'
										items+=Attribute* '}'
								Attribute: 
									key=ID ':' val=Value
								Value: 
									Size | Hex | STRING | 
									Boolean | INT | ID
								Size: value=INT unit=Unit
								Unit: 'B'|'kB'|'MB'|'GB'

From XCC-AST to Code Generation

XCC-AST: Abstract syntax tree with communication semantics in PKL and JSON formats for downstream code generation.

✓ Traceability from spec to generated code

✓ Optimized code: Static resource allocation, predictable patterns, platform-specific

XCC-AST predstavlja jedinstveni opis sistema i komunikacije u PKL i JSON formatu i služi kao osnova za generisanje platform-specifičnog koda. Generatori ga koriste kao jedini izvor specifikacije, kako bi obezbedili statičku alokaciju resursa i predvidljivu komunikaciju. Time implementacija ostaje usklađena sa arhitekturom, a promene na jednoj platformi ne narušavaju komunikacione interfejse na drugoj.
Vreme: 1 minut

XCC-AST serves as a unified representation of the system and communication in PKL and JSON format and is used as the basis for generating platform-specific code. Generators use it as the single source of specification to ensure static resource allocation and predictable communication. This keeps the implementation aligned with the architecture, and changes on one platform do not disrupt communication interfaces on another.
Time: 1 minute

Key Benefits

✓ Traceability: Full mapping from spec to generated code

✓ Minimizing integration overhead: No manual code changes for communication in heterogeneous systems

✓ Systematic Design: Single source of truth for communication

✓ Late Changes Safe: Architectural evolution without breaking system

XCC: Making it Practical

XCC bridges the gap between architectural specification and implementation reality trough code generation

Result: Teams can design communication interfaces systematically, validate them early, and evolve them safely

Questions?
nikola.stojkov@outlook.com

Iz prilozenog mozemo zaključiti da XCC smanjuje vreme integracije i održavanja komunikacije u heterogenim sistemima. Generatori koda mogu da koriste apstraktno sintaksno stablo kao jedini izvor specifikacije, kako bi obezbedili statičku alokaciju resursa i predvidljivu komunikaciju. Timovi mogu sistematski da dizajniraju komunikacione interfejse i da ih validiraju rano u procesu razvoja i da ih bezbedno menjaju kako se arhitektura sistema menja tokom vremena.
Time: 30 seconds + questions

From the above, we can conclude that XCC reduces integration and maintenance time for communication in heterogeneous systems. Code generators can use the abstract syntax tree as the single source of specification to ensure static resource allocation and predictable communication. Teams can systematically design communication interfaces and validate them early in the development process and evolve them safely as the system architecture changes over time.
Time: 30 seconds + questions