Compute architecture
Select the class and combination of host CPUs, GPUs, FPGAs, embedded controllers, memory, storage, and hardware acceleration needed by the workload.
Tinverse Hardware Platform
Envision, specify and build your own compute infrastructure.
Choose the combination of CPUs, GPUs, FPGAs and embedded processors your application needs. Define its communication fabrics, actuator topology, control architecture, thermal envelope, board layout, and physical form factor. Tinverse Hardware Platform turns those decisions into versioned contracts that thal, FPGA builds, and Tinverse Linux can carry into the finished system.
Start with the system
Make the architecture answer the application.
Control and communication
Allocate control loops, define actuator and sensor topology, and choose the DDS, EtherCAT, CAN, PCIe, Ethernet, or board-local links between processors.
Physical implementation
Carry power, thermal, connector, board-layout, mechanical-envelope, serviceability, and physical form-factor constraints alongside the architecture.
One definition, multiple implementations
Turn hardware decisions into software boundaries.
The hardware platform is the source of truth for what the machine physically contains and how its processors, interfaces, and control nodes fit together. Each implementation consumes the part of that contract it owns instead of reconstructing hardware facts in another repository.
Hardware contract
Describe the complete compute and control platform.
Platform and board identities, processors, FPGA personalities, communication links, actuator allocation, power states, connectors, Linux requirements, thermals, and mechanical limits.
Implementation boundaries
thal
Turns embedded-board signals, peripherals, routes, memory, and safe defaults into typed C++ resources for firmware.
FPGA implementations
Consume device, package, pinout, host-link, register-ABI, and compatible-personality constraints.
Tinverse Linux Guix
Builds Linux-facing requirements into a declarative kernel, device tree, driver, firmware, service, and image definition.
Tinverse Linux Yocto
Builds the same platform boundary through machine metadata, layers, recipes, firmware packaging, and image features.
The hardware decision remains identifiable in the release.
Platform identity, board revision, selected personalities, configuration, and contract provenance can travel with firmware, FPGA, and Linux evidence.
Embedded control
Connect the board design to thal.
A hardware contract names the processor, connected devices, signals,
buses, pins, safe states, and resource policy. thal validates the
embedded description against processor capabilities and exposes typed
names such as gate_enable, phase_u_current, and
field_can to firmware.
Host compute
Connect the compute design to Tinverse Linux.
The Linux-facing contract identifies processors and accelerators, device-tree and kernel requirements, driver bindings, network roles, firmware, FPGA bitstreams, real-time policy, and attached controllers. Guix or Yocto turns those requirements into the product image.
Explore the Linux implementation paths →From questions to contracts
Make the answers executable.
The result is not only a block diagram. It is a controlled hardware definition that gives embedded firmware, FPGA logic, Linux images, and release evidence a common account of the machine they are built for.
Contact engineering@tinverse.com.