We all know that person. Everyone in the office is wondering why the heat is turned up. They’re not sweating outright, but they have that just-a-tad-too-warm glow going. And then there’s that one person wearing the jacket. The one that can never seem to get warm enough. Everyone else is trying to shed heat; this person needs more. If only there were a way to get heat from the too-hot people to the too-cold person. Alas…
Low power. Cooler dice. They’re pretty much a thing these days. We spend countless hours designing low-power circuits, better packages, more inventive heat-extraction technologies, all for the purposes of keeping our chips from going nuclear.
Well, it turns out, there’s an exception. There’s that one chip that simply can’t manage to stay warm enough – so much so that it needs a heater.
OK, so, fessing up, it’s not a digital logic die. In fact, its principle function isn’t even analog. No, we’re not talking about MEMSIC’s heated-air accelerometer either. It’s a photonics die.
Which brings us back to a topic we’ve touched a few times before, from a basic primer to a discussion of photonics EDA. But that EDA discussion was about pure photonics. There’s been precious little integration of photonics design with circuit design (other than the merging of DRC into the photonics flow).
Here’s the deal: a large-scale photonics system is… well, still off in the future. But the practical fact of that design is that it will likely involve four difference pieces of silic… – er – semiconductor.
- Digital logic, on a reasonably modern process node, with features measured in nanometers
- Analog circuitry, probably on a different die a couple of nodes older than that used for digital logic, with features still measured in nanometers, but probably more of them
- Photonics, on a 130-nm (or maybe a 65-nm) node, with features measured in microns
- The laser, which typically uses materials other than silicon.
Each of those dice has tools to make them work, so, if you can manage the interface between the dice, then you can do each design more or less separately – the tools are there for that.
It’s Gettin’ Hot in Here
But it turns out that there’s not quite such a clean break between dice. Yeah, we know we can mix digital and analog if we want to – tools are in place for that. But what about mixing circuits with photonics?
Well, it turns out that mixing just any circuits with photonics is still a ways away. But one pesky aspect of a photonics chip is that the waveguides and such like to stay at a constant temperature. So, while everyone else works on getting heat out of their systems, photonics guys are literally adding heaters to their chips.
And there have been no tools for doing this.
They call it electro-optical design. Yeah, when I heard that phrase, I assumed that this referred to any integration of the electrical with the photonic. After all, it certainly seems plausible that converting from electrical to photonic on a single chip before sending the photons across the network might be faster than transitioning from one die to another first. I’m honestly not sure how those numbers pencil out, but it’s simply not what’s being attempted now. Right now, electro-optical mostly refers to the electric bits that feed the heater.
Electro, Meet Optical
Honestly, at this point, we’re talking low-level design. Much of this still involves manual layout, but managing a layout that combines photonics circuits (OK, they’re not circuits in the strict sense, but… work with me here…) with electrical circuits has been difficult.
So Mentor has announced their LightSute tools to help with this. It’s a script-based approach that works with a photonic compiler to help automate placement and routing. It hooks into Mentor’s Calibre DRC tool, meaning that resulting layouts will be DRC-clean by design. The design acceleration that this provides would appear to be non-trivial: one of their early customers on this, HP, says that a particular 400-element design that would have taken around two weeks to lay out manually was done in 9 minutes, DRC clean.
That whole DRC thing isn’t necessarily obvious, as we’ve seen before. Most DRC is set up to work with straight lines and well-defined corners. (Or, at least, lots of people are working super hard to keep those corners sharp in leading-edge nodes.) But photonics involves curves, which can stay curves with direct-write technologies (great for research). When you go to a normal high-volume mask system, well, GDS2 doesn’t really understand curves well. You need to supply it with a linear approximation, hopefully using lines and corners so short that they can’t resolve, and sort of fuzz into a curve.
But this affects DRC, since, when you’re running DRC, you haven’t fractured the curves yet. And normal DRC rules don’t understand curves. Which is why they use equation-based DRC. Rather than “simply” articulating spacings between features that are assumed to be lines and mostly right angles, features are described and verified mathematically using equations. And equations can describe curves.
Maybe Getting Closer to Analog?
So where’s this all going longer-term? At least as Mentor tells it, it’s pretty unlikely that photonics and digital will cohabitate. The real estate on which the digital logic resides is expensive, and photonics circuits use lots of real estate. It’s like trying to plant a field of hay in the middle of San Francisco; that hay is going to be wayyyy too expensive.
Photonics and the laser? Well, as long as “photonics” means “silicon photonics,” that’s not likely. Silicon is an indirect-bandgap semiconductor, which means that it tends to put out phonons rather than photons. Direct-bandgap semiconductors – which tend to be compound semiconductors like GaAs and InP – can generate and stimulate the photons necessary for lasing. But, because it’s a different material, it gets its own die. That’s not likely to change either.
That leaves analog and photonics. And there is some work ongoing to help merge these design flows. In its early stages, it’s likely to fall short of a fully integrated flow, remaining two flows that exchange files back and forth to get the job done. But… well, you know, baby steps, right? Put some work into automation, and, if demand materializes, put in more work to automate further.