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.

Voraussetzungen

As systems-on-chip continue to grow in complexity and chiplet-based architectures increasingly split functionality across multiple dies, the amount of data that must be transferred between system components continues to rise. While this can be addressed by increasing interconnect bandwidth and lane count, area, power consumption, and pin requirements also increase.

One way to reduce the load on such bandwidth-constrained links is to compress data on-the-fly before transmission. In this context, low latency and high throughput are more critical than high compression ratios, and lossless compression algorithms from the Lempel-Ziv family are especially interesting for their generally favorable trade-off between compression efficiency and implementation cost.

In this seminar work, the student should investigate hardware implementations of lossless data compression algorithms, with a focus on the Lempel-Ziv family, such as LZ4. The goal is to compare different architectural concepts and implementation choices with respect to throughput, latency, maximum frequency, and resource usage. In particular, the student should examine which algorithmic properties make an approach more or less suitable for hardware realization, such as the degree of inherent parallelism, the complexity of match search and reference generation, or the handling of variable-length coding and control flow. For dictionary-based methods, aspects such as efficient lookup mechanisms, for example, hash-based indexing or other compact search structures, are especially relevant. In addition, the student should assess how well these approaches fit a pin-constrained chiplet interconnect with strict latency requirements, and discuss which algorithmic or architectural decisions are most promising for such a target system.

Potential starting points for literature research could be the following papers:
https://arxiv.org/html/2409.12433v1
https://dl.acm.org/doi/abs/10.1145/3542637.3543701
https://dl.acm.org/doi/10.1145/3316551.3316564
https://ieeexplore.ieee.org/abstract/document/8306366
https://dl.acm.org/doi/abs/10.1145/2664666.2664670
https://ieeexplore.ieee.org/abstract/document/7160039

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 closes the gap between the underlying physical layer that handles data transmission across the interposer and the system bus that attaches the inter-chiplet interface to the other components of the demonstration chip. The design is based on the PULP platform's Serial Link.

As one of the key features of the Smart Chiplet Interconnect, we are developing an on-the-fly lossless data compression module to reduce the amount of data transmitted across the interposer and thus increase the effective bandwidth via a low-pin interface. A Python version of the LZ4-based algorithm is available and extends the baseline by features such as an inserted encoding stage and preloaded or fixed dictionary entries.

In this project, the student will be responsible for implementing the module in SystemVerilog. This includes realizing hardware-specific optimizations for performance and resource usage. Alongside the compression module, the student will also implement the simpler corresponding decompression module for optional decompression on the receiving chiplet.

After verifying matching functionality with the Python reference, the student will evaluate the performance of the implemented modules. For this, the modules should be integrated into a minimal version of the chiplet interconnect stack and fed with realistic data patterns as they would arrive from the system bus or the interconnect. The evaluation will focus on the achievable compression ratio and latency of the hardware implementation. 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 the two projects, a combination and joint evaluation of the two designs may be possible and is encouraged.

Voraussetzungen

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.

Voraussetzungen

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.

Voraussetzungen

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.

We use a Duckiebot's Time-of-Flight (ToF) sensor to measure the distance to objects in front of the robot. This allows it to stop before crashing into obstacles. The distance measurement is also used in our platooning mechanism. When another Duckiebot is detected via its rear dot pattern, the robot can adjust its speed to follow the other Duckiebot at a given distance.

Unfortunately, the measurement region of the integrated ToF sensor is very narrow. It only detects objects reliably in a cone of about 5 degrees in front of the robot. Objects outside this cone, either too far to the side or too high/low, cannot reflect the emitted laser beam to the sensor's collector, leading to crashes. The distance measurement is also fairly noisy, with measurement accuracy decreasing for further distances, angular offsets from the sensor, and uneven reflection surfaces. This means that the distance to the other Duckiebot is often not measured correctly in the platooning mode, causing the robot to react with unexpected maneuvers and to lose track of the leading robot.

In this student assistant project, the student will investigate how to resolve these issues. After analyzing the current setup, different sensors and their position on the robot's front should be considered. A suitable driver and some hardware adaptations will be required to add a new sensor to the Duckiebot system. Finally, they will integrate the improved distance measurement setup in our Python/ROS-based autonomous driving pipeline, evaluate it in terms of measurement region and accuracy, and compare the new setup to the baseline.

These modifications should allow us to avoid crashes more reliably and enhance our platooning mode, which will be helpful for further development, especially when moving to more difficult-to-navigate environments, e.g., tracks with intersections and sharp turns.

Voraussetzungen