Conceptual render: an open automotive gateway unit with a finned die-cast enclosure, sealed harness connectors and twisted-pair CAN wiring, under copper rim light.

Example project · UC 09

Every vehicle network. One gateway.

An example project that turns a single FPGA into a central vehicle gateway. An automotive-grade RISC-V routes and filters traffic between CAN FD, CAN, LIN and automotive Ethernet, and answers diagnostic requests over UDS and DoIP.

Apply With This Use Case →

Conceptual illustration

The problem

Modern vehicles run many networks that all need to talk.

Powertrain, chassis and body ECUs sit on separate CAN FD, CAN and LIN buses, while ADAS and infotainment move to automotive Ethernet. A gateway has to route only the right messages between them, at deterministic latency, keep domains isolated, and give service tools one diagnostic entry point. Doing it in FPGA logic with a RISC-V for control gives hardware-speed routing that stays programmable.

OutcomeA RISC-V gateway on one FPGA that routes and filters CAN FD, CAN, LIN and Ethernet traffic and serves UDS diagnostics over DoIP.
TargetCommercial or custom AMD board with CAN FD and LIN transceivers, an automotive or standard Ethernet PHY, DDR and QSPI flash

The prompt

The simple prompt
Build an FPGA-based automotive gateway using an automotive-grade RISC-V processor that routes and filters messages between CAN FD, CAN and LIN buses and automotive Ethernet, and supports vehicle diagnostics over UDS and DoIP.

An example request. Compatibility and availability are confirmed for each selected configuration.

RequirementsRead from the prompt

What SIGPT reads into it.

The prompt names the networks and the diagnostics. SIGPT turns them into controllers, a routing engine and a diagnostic stack around an automotive-grade RISC-V.

01 · “Automotive-grade RISC-V”

Safety-minded control

The automotive-grade core runs routing tables, network management and diagnostics, with a watchdog and lockstep-friendly configuration.

02 · “CAN FD, CAN and LIN”

In-vehicle buses

CAN FD controllers for powertrain and chassis, classic CAN and LIN for body electronics. Bit timing is taken from your network specification.

03 · “Routes and filters”

Gateway router

Generated hardware that filters by message ID, translates between buses, and rate-limits each route so one domain can't flood another.

04 · “Automotive Ethernet”

Backbone link

An Ethernet MAC with TSN and IEEE 1588 PTP for time-aware traffic to ADAS and infotainment domains.

05 · “UDS and DoIP”

Vehicle diagnostics

UDS services over CAN and over Ethernet using DoIP, so a service tester reaches every ECU through the gateway.

06 · Implied

Boot, memory and timing

QSPI boot flash, DDR for buffers and logs, plus timers for scheduling and message timeouts.

ArchitectureConceptual

A simple conceptual architecture.

RISC-V Automotive GatewayConceptual block diagram · not a delivered netlist
ExternalReusable IPGenerated logic
Good to know. Routing latency and throughput depend on bus load, message mix and the routing table, and are measured on your setup. This is a functional prototype. ISO 26262 safety certification and vehicle homologation are separate programmes and are not provided by SIGPT. See Firmware below.
FirmwareImplicit with RISC-V

A RISC-V in the prompt. Gateway firmware included.

Firmware is implicit. The prompt names an automotive-grade RISC-V, so SIGPT generates the standard stack automatically. The prompt also describes behaviour, routing, filtering and diagnostics, so those are added on top.

Always generated

Standard firmware stack

  • Boot and startup codeReset vector, clock and memory setup, QSPI boot, linker script
  • Board support packageRegister headers and interrupt map, from the same spec as the RTL
  • A driver for every selected IPCAN FD, CAN, LIN, Ethernet, timer, watchdog, DMA
  • Bring-up self-testChecks each controller, memory and PHY link at power-on
  • UART console and JTAG debugStatus, register peek and poke, and logs
  • Build filesMakefile and standard RISC-V GCC toolchain
Added from this prompt

Gateway and diagnostics

  • routes and filters messagesRouting-table manager and filter configuration for the hardware router
  • between CAN FD, CAN and LIN … and automotive EthernetSignal and frame mapping between buses, plus a LIN schedule table
  • vehicle diagnostics over UDSUDS server: read and clear DTCs, read data by ID, ECU reset, sessions
  • and DoIPDoIP entity: vehicle announcement, routing activation, diagnostic message relay
  • Automotive-grade defaultsWatchdog servicing, bus-off recovery and network-management timeouts
Want more specific firmware? Add it to the prompt, for example: forward wheel-speed frames to Ethernet every 10 ms, and support secure flashing over DoIP. Anything you don't describe stays standard.

IP needed

What SIGPT would assemble.

Selected from 140+ 3rd-party FPGA-proven IPs, starting with the automotive-grade RISC-V and the automotive bus controllers.

RISC-V processorsRISC-V Automotive-Grade Processor IP
Peripheral interfacesCAN FD Controller IP, CAN Controller IP, LIN Controller IPCAN XL available for next-generation backbones
Ethernet & networking1G Ethernet MAC IP, Time-Sensitive Networking IP, IEEE 1588 PTP IP
On-chip interconnectAXI crossbar & interconnect IP, DMA controller IP
Memory & bootDDR4 controller IP, QSPI controller IP
Peripheral interfacesTimer IP, Watchdog IP
Generated firmwareStandard stack plus routing-table manager, bus mapping, UDS server and DoIP entityImplicit with RISC-V · details
Generated logicHardware gateway router: ID filters, bus translation, per-route rate limits

Validation steps

How it would be proven on hardware.

Board validation is its own milestone, separate from bitfile generation. Any results are measured on your setup, and none are shown here.

No board? Use the Remote FPGA Lab. Ask for a custom lab setup with CAN FD and LIN transceivers, an Ethernet link partner and a bus analyser, then run these steps remotely. Remote Lab →
  1. Program the bitfile, load the generated firmware and check the self-test on the UART console.
  2. Inject traffic on each CAN FD, CAN and LIN bus and confirm only the configured messages are routed, with the expected translation.
  3. Flood one bus and confirm rate limits protect the other domains.
  4. Connect a diagnostic tester over DoIP and read and clear DTCs on ECUs behind the gateway.
  5. Measure routing latency and bus-off recovery against the agreed acceptance criteria.
NextAfter the lab

From lab bench toward the vehicle.

Once the gateway passes in the lab, choose how to take it further. Vehicle programmes add safety analysis and qualification, which are planned with you.

FPGA productionLicense the bitfile or buy the full project sourceFor deployment on your registered devicesLicensing →
Your own IPAdd your own proven security, SecOC or intrusion-detection logic next to the routerUploaded encrypted to a private vaultDetails →
ASIC pathTake the gateway toward an automotive SoC for production volumesASIC Readiness →

Start from this prompt. Make it yours.

We’ll prefill your request with this use case. Edit it to match your requirements.

Apply With This Use Case →All use cases