SerDes For Chiplets

The XSR 56G and 112G Interoperability Agreements (IAs) announced by the OIF are intended to cover a channel consisting of a pair of up to 50mm. The primary defined application of the XSR SerDes is connecting a chip to a “nearby” optical engine. Because the requirements on these channels are much less stringent than they are on long reach channels, XSR SerDes are expected to have lower power than long-reach SerDes.

There are two aspects that are often confused when talking about an XSR SerDes. On one hand, XSR SerDes connect two chips on a channel defined by the IAs (in terms of loss and other electrical properties). On the other hand, the XSR SerDes is seen purely in terms of the application it is intended for, i.e., connecting a chip to a nearby optical engine. As the industry looks at more general approaches in which applications are implemented on chiplets connected inside a shared package, it is important to separate these two aspects of an XSR SerDes.

Because the primary application of XSR is connecting a chip to an optical engine, the traffic transported by an XSR SerDes is assumed to be protected by the end-to-end system FEC. That FEC is designed to protect against a raw bit-error ratio (BER) of 1E-5, and possibly as high as 1E-4. Therefore, the XSR SerDes used in such an application are only assumed to have a BER that is several orders of magnitude better than 1E-5. This has been quite fortuitous in the OIF standardization of PAM-4 signaling for CEI-56G-XSR since PAM-4 signaling struggles to deliver a BER of 1E-9 without the use of heavy Forward Error-Correction (FEC) techniques, which in turn leads to higher power consumption, and latency. The situation is even worse when going to 112G since PAM-4 is inherently vulnerable to reflections that will dominate at that higher rate. The BER requirement may have to be further relaxed to 1E-6 or even 1E-5.

So an XSR SerDes, as mandated by the OIF, is capable of addressing only one problem— tunneling traffic with an end-to-end FEC that is capable of recovering from a raw BER of 1E-5 to 1E-4. Does this solve the problem of connecting to a nearby photonics engine? Yes, but only if other important implementation aspects such as power, latency, etc., are ignored. Does it solve the more general problem of connecting any two chips separated by a channel specified for an XSR SerDes? No. Most such applications don’t assume an end-to-end FEC, and they don’t require the bits to be delivered with a BER well below 1E-15, say 1E-20 or less. A PAM-4 XSR SerDes will not be able to deliver such performance.

Let’s look at a Glasswing link, instead. Current versions of Glasswing are built for USR links, that is, links inside a shared package like a multi-chip-module. However, by changing the IP slightly, it can be designed to work on the very same channels that XSR is intended for and will have much the same properties as the USR version does, namely very low power, very high bandwidth and excellent signal integrity. An XSR version of Glasswing would solve any interconnect problem between two chips, since Glasswing delivers bits with a BER of at most 1E-15 in this generation, and down to 1E-20 in future generations.

In contrast to an XSR SerDes, Glasswing delivers a ton of bandwidth from one IP—the current version provides 500 Gbps bi-directional traffic and the next generation which is already in development will double this bandwidth. A 56G XSR SerDes would deliver 56 Gbps, and a 112G XSR SerDes would deliver 112 Gbps. So the XSR bandwidth is about 12.5% that of Glasswing. This is both good and bad. It is good, because for connections to optical engines, every XSR lane may have to be clocked differently. The “thin pipe” structure of XSR, i.e., the delivery of only one lane at a time, allows heterogeneous clocking across the lanes. The current versions of Glasswing, however, clock all the bits the same way in order to reduce the power consumption. As such, Glasswing is a “fat pipe,” delivering a huge bandwidth of bits that are clocked alike.

This is no coincidence. Glasswing is designed to transport a large number of bits with impressively low power. So, how would it be used in the setting of an XSR SerDes? The solution is a thin multi-channel Physical Medium Attachment (PMA) layer that frames the incoming bits and delivers them to and from the optical engine with the right clocking through the use chiplet-based clock generation on the egress and digital PLLs on the ingress. Such a layer would be implemented inside the optical engine, in the same position as the VSR (C2M) module SerDes.

An important aspect is the power of the proposed solution. Glasswing’s power consumption is about 30% to 40% that of a commercial-grade XSR solution. There are multiple reasons for this power advantage. Some have to do with the design. However, for the most part, it is due to better signal integrity.

So, which is better? The answer depends on the application and on the associated power constraints. The poor BER performance of XSR SerDes makes them a bad fit for the many diverse applications of heterogeneous integration of die inside a shared package, or even between packages of short distance. When connecting to a nearby optical engine an XSR SerDes can do the job fine, but Glasswing would do the job at one-third the power or less. The optical engines that have come to market for on-package or near-package use are almost all multi-channel, so having a single larger device that includes the Glasswing is a good fit to this application.