Paper: λλ: A Programming Language for Silicon Photonics
Authors: Vaibhav Mehta, Arjun Devraj, Bill Owens, Justin Hsu, Rachee Singh
Presenter: Weihao Jiang, Shanghai Jiao Tong University
Guest of Honor: Vaibhav Mehta, Cornell University; Rachee Singh, Cornell University
Q：Does Lambda support incremental compilation and partial reconfiguration? If only one input-output connection changes, can the compiler preserve the existing embedding and recompute only the affected PUCs and waveguides instead of solving the entire ILP again?
**A：**At the moment, no. The current implementation does not support incremental compilation, but it should certainly be possible and is a very good direction to explore. For circuit switching, where only input-output connections change, it is relatively clear which parts should be preserved and which parts should be changed. However, for a general Lambda program with computation, even a small change early in the program may affect many downstream operations. Therefore, the benefit of incremental compilation may not always be very large.
Q：Do you think optical switches could support runtime reconfiguration in the future?
**A：**Yes. Physically, the switches can already be reconfigured at runtime. The main challenge is the reconfiguration delay. At the moment, that latency is higher than we would like, which makes frequent reconfiguration difficult in large-scale networks or data centers. However, reconfiguration time has been decreasing over the years as hardware improves, so there is no fundamental reason why it could not eventually become low enough. There has also been a lot of networking research on either designing faster reconfigurable optical switches or developing algorithms that work efficiently despite a fixed reconfiguration delay.
Q：Under resource constraints, what causes performance degradation in silicon photonic circuits?
**A：**The latency itself is generally very low because light propagates quickly. The main problem is optical loss. As light travels through a large circuit, it loses power, so in a very large circuit the output power may become too low even if the compiler tries to minimize the loss. One possible solution is to include amplifiers in the circuit. Another source of degradation is heating. As silicon components heat up, their behavior can change. For example, a split operation intended to produce a 0.5/0.5 split might instead behave more like 0.6/0.4. This can be mitigated by encoding values with some error margin and by using hardware calibration information in the compiler so that it can compensate for or route around hardware imperfections.
Q：What is the difference between MEMS-based OCS and silicon-photonics-based OCS? Why is the configuration of MEMS-based OCS relatively simple?
**A：**MEMS-based OCS essentially uses mirrors to route light from one place to another. One advantage is that its configuration is relatively simple, but the disadvantage is that it is not programmable in the same sense. It mainly performs routing. Silicon photonic circuits can do more than routing: they can manipulate phase and amplitude and perform computation. Therefore, silicon photonics requires some form of controller to determine what program should run on the switch. The controller does not necessarily need to be as complicated as a full distributed data-plane controller, but some control mechanism is still required.
Q：If silicon photonics were restricted to one-to-one perfect matching, like MEMS-based OCS, could the reconfiguration time be shorter?
**A：**Possibly. If the silicon photonic circuit were restricted to always implementing only one perfect matching, the reconfiguration time could potentially be shorter. However, the major advantage of silicon photonics is that it supports much more than simple one-to-one routing, including computation. Restricting it to perfect matching would give up much of that additional capability.
Q：For very large implementations with thousands or tens of thousands of PUCs, will insertion loss become a serious problem?
**A：**Yes. For very large photonic circuits, the accumulated insertion loss can become too high. This is one of the important limitations of scaling these systems. Path length, device loss, and the balance of losses across different paths all become important as the circuit grows.
Q：Could this work eventually be extended from a compiler into something more like an EDA tool for photonic ASIC design, where it also designs waveguides and the physical mapping on the chip?
**A：**Yes. This is an interesting direction and something the author is considering. The current language intentionally hides waveguides from the user. If the system were extended toward ASIC design, it might expose waveguides and their physical properties. Once waveguides are exposed, timing can also become part of the design. For example, a waveguide of length L introduces some propagation delay, and two beams of light traveling along paths of different lengths may arrive with different phases. These timing and physical-layout considerations could become part of a future photonic ASIC design system.
Q：There are many different architectures and technologies for OCS. Does Lambda support all of them?
**A：**No. Lambda is designed specifically for silicon-photonics-based optical circuits. Other OCS technologies, such as MEMS-based OCS, generally focus on routing and do not provide the same computational capabilities. Within silicon photonics, however, there are different chip architectures such as hexagonal, triangular, and feed-forward meshes, and the compiler is designed to work across these different silicon photonic topologies.
Q：Could P4 simply be extended to program silicon photonic switches instead of designing a new language such as Lambda?
**A：**The main problem is that the hardware capabilities and abstractions are very different. P4 is designed around match-action-table-based packet-processing hardware, while silicon photonic circuits do not naturally support match-action tables. Therefore, the technical abstractions of P4 do not directly fit silicon photonics. However, Lambda is inspired by P4 in two broader ways: portability across different hardware targets and making programmable hardware easier to use so that higher-level applications and abstractions can be built on top of it.
Q：Is Lambda’s graph-based hardware abstraction sufficiently general? Real photonic chips also have port directionality, propagation loss, and device-specific capabilities.
**A：**The abstraction is more than a simple unlabeled graph. Nodes can contain labels describing properties such as directionality. For example, the compiler can represent constraints on which side of a PUC light can enter and leave. Propagation loss can be represented using edge weights, and the ILP can optimize for loss. Device-specific capabilities can also be represented by introducing new labels or node types. For example, if future hardware includes amplifiers, the graph could include amplifier nodes and the language could introduce a corresponding primitive. If future hardware introduces fundamentally new physical behavior, some compiler constraints may need to change, but for the foreseeable future the graph-based abstraction appears to provide a reasonable balance.
Q：What was the most challenging part of this research?
**A：**There were several challenges. One was deciding what primitives the language should expose to users. The natural first idea is to design something similar to C or C++, but the team had to understand why those abstractions were not appropriate for this kind of hardware and identify simpler primitives that better match silicon photonics. Another challenge was implementing all the ILP constraints correctly, because it is easy to miss a physical constraint. Hardware experiments were also difficult because when something fails, it may not be obvious whether the problem comes from the program, the laser, or another hardware component. Finally, some of the formal semantics and proofs, especially those relating general programs to general photonic graphs, were technically subtle.
Q：Why did Lambda use a type system to guarantee program validity instead of using a verifier similar to eBPF?
**A：**A verifier-based approach would also be possible, but the authors felt that a type system was a simpler and more natural way to express these constraints. Type checking is usually lightweight and fast. It is also compositional, which means that parts of a program can be type-checked independently, even when the entire program is not yet complete. Linear type systems are also a well-established area of theory. A verifier may become more useful if the goal is to verify properties beyond basic physical validity, such as more general semantic properties of the program.
Q：Are silicon photonic switches already widely used in modern data centers?
**A：**Not yet. There are still hardware challenges that make it difficult to deploy silicon photonics as part of an end-to-end, large-scale production network. However, optical circuit switching also took many years to move from early research ideas into production environments. As hardware manufacturers continue improving the technology and making it easier to use, silicon photonics may eventually become practical for data-center deployment.
Q：What are the main challenges that must be solved before photonic switches can be deployed at large scale?
**A：**One major challenge is insertion loss. In a large photonic circuit, optical loss can become so high that the system is unreliable. Another challenge is synchronization and buffering. Photonic circuits do not naturally provide buffering in the same way as electronic packet switches. If many inputs enter the photonic circuit in a distributed setting, buffering may need to happen in the electrical components before the optical circuit, or the inputs may need to share a clock or use some synchronization mechanism. These synchronization requirements can introduce additional overhead.
Q：Is connecting GPU servers using photonic circuits a worthwhile research direction?
**A：**Yes, it is worth considering. However, the problem is not limited specifically to GPUs. A more general and important question is how to coordinate multiple different inputs into a photonic circuit. GPU interconnection is one useful application, but the broader synchronization and coordination problem is also important.
Q：For new graduate students, what is the best way to get started in silicon photonics or programmable photonics?
**A：**A good starting point is the book “Programmable Integrated Photonics.” It is a very comprehensive and very large book, so it is not necessary to read the entire book. For a networking researcher, reading the first few chapters should be enough to understand how photonic circuits work and what capabilities the hardware provides. After understanding the basic hardware capabilities, one can start thinking about how networking systems and applications can be built on top of them.
Q：Is it necessary for a new graduate student to get an internship at a company working in this area in order to conduct silicon photonics research?
**A：**No. It is certainly possible to work on this area without such an internship. The author himself has not done an internship in this area. The main practical challenge is hardware: buying and operating real silicon photonic hardware can be expensive and complicated. However, simulators are also available, so some research can still be conducted without direct access to physical hardware.