Michael Meidinger, M.Sc.

In the BCDC project, a working group at TUM collaborates on designing a RISC-V-based chiplet demonstration chip, with two of them connected via an interposer to represent a system of interconnected chiplets. At LIS, we work on an efficient, low-latency chiplet interconnect with additional application-specific features managed by a Smart Chiplet Interconnect layer stack. It bridges the underlying physical layer, which handles data transmission across the interposer, and the system bus, which connects the inter-chiplet interface to other components of the demonstration chip. The design is based on the PULP platform's Serial Link.

The additional features of the Smart Chiplet Interconnect should be applied data-selectively. Therefore, data flows need to be classified and forwarded to the intended modules, such as those responsible for data compression or encryption. A classification mechanism in our interconnect stack will handle this for both outgoing and incoming data. In this project, the student will implement the required classifiers and integrate them into the Smart Chiplet Interconnect's additional feature layer as sub-layers.

The classification mechanism should combine explicit feature flags with heuristics based on transmission metadata and detectable data characteristics. This includes information such as destination address, payload size, and, for example, recognized compressible patterns. Classified data flows are then forwarded to the appropriate feature modules. If multiple features are to be applied, proper ordering must be ensured, and incoming and outgoing traffic must be differentiated. Classification and forwarding should introduce minimal latency overhead to avoid negatively impacting the interconnect's performance. For future extensibility, the design should be modular and allow for easy addition of new classification strategies and additional features.

After implementing the classifier sub-layers in SystemVerilog, the student will evaluate their impact on the interconnect stack. The test environment should provide the extended interconnect stack with realistic input data as it arrives from the AXI system bus or the connected chiplet. The main evaluation metrics will be classification accuracy, classification/end-to-end latency, and hardware cost. As smart classification should reduce wasted latency and power consumption when feature application is not beneficial, the mechanism will be compared to a naive strategy. To estimate resource usage and the maximum achievable clock frequency, the student will synthesize the design for the VCU118 FPGA evaluation board.

The project will be accompanied by another Bachelor's thesis surrounding the Smart Chiplet Interconnect. Depending on the progress of both projects, a combination and joint evaluation of the two designs may be possible and is encouraged.

Prerequisites

At LIS, we use the Duckietown hardware and software ecosystem to investigate autonomous driving algorithms and reinforcement learning agents on Duckiebots, which are powered by NVIDIA Jetson Nano boards and drive autonomously on a miniature road network in our lab. More information on Duckietown can be found here.

The current perception pipeline consists of classical image-processing-based lane detection for steering and speed control and a CNN-based object detector (YOLOv8) for obstacles and traffic signs, already pushing the on-board hardware to its limits.

In this project, the goal is to redesign lane detection as a split-computing convolutional neural network that runs partially on the Duckiebot and partially on an external server, in order to improve utilization of the Jetson’s CPU and GPU while maintaining a framerate of about 30 Hz end-to-end. A lightweight lane or line detection network head should operate on raw camera images on the robot and output a compact intermediate representation that is sent over the network to a server for more computationally intensive processing, whose results are then used for vehicle control.

The student will first perform a literature review on efficient lane and line detection architectures (e.g., pixel-based, grid-based, anchor/curve-based, and keypoint-based networks, as well as Mobile LSD and related approaches) and select one or a small set of promising candidates. These models will be implemented in a split computing manner across Duckiebot and server, including the design of an appropriate split point, communication protocol, and integration into the existing control pipeline.?

A key part of the work is to systematically evaluate the trade-offs between model complexity, communication bandwidth, CPU/GPU utilization, and control performance, ensuring that the new system does not (significantly) increase latency or CPU load compared to the current classical lane detector. With an alleviated CPU utilization, we will enable the development of more complex Duckiebot behavior, such as safe navigation on tracks that include intersections, pedestrian crossings, and traffic lights, which has so far been infeasible due to the limited computational resources of the Jetson Nano. Furthermore, after developing the lane detection CNN, potential points of intersection with the object detection CNN can be analyzed for future partial combination.

Prerequisites

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebot control system. More information on Duckietown can be found here.

In previous work, we developed a tool called DuckieVisualizer to monitor our Duckiebots, evaluate their driving performance, and visualize and interact with the actively learning RL agents.

This student assistant position will involve extending the tool and its respective interfaces on the robot side by further features, e.g., more complex learning algorithms or driving statistics. The underlying camera processing program should also be ported from Matlab to a faster programming language to enable real-time robot tracking. Furthermore, more robust Duckiebot identification mechanisms should be considered.

Besides these extensions to the DuckieVisualizer, the student will also do some general system maintenance tasks. This may include the hardware of the Duckiebots and their software stack, for example, merging different sub-projects and looking into quality-of-life improvements to the building process using Docker. Another task will be to help newly starting students set up their development environment and to assist them in their first steps. Finally, the student can get involved in expanding our track and adding new components, e.g., intersections or duckie pedestrian crossings.

Prerequisites