posted by Bryon Moyer
The EUV barrier has been broken.
And I found out right on the heels of yesterday’s EUV update – but too late to get it into that piece. Remember the issue with the misalignment of the laser? That happened when bringing the system back up from a power upgrade. Well, there’s more to it than most of us realized.
While the power upgrade was officially for 30 W publicly, they had had a breakthrough and were privately hoping for a lot more. They just didn’t want to say anything about it until they knew it would work; there have already been far too many expectations set and then missed with this technology. And the timing with SPIE Litho would have been perfect – what an amazing opportunity for a surprise announcement. But the glitch during bring-up messed all that up. The PR folks must have been going nuts.
But here’s the bottom line: the 30 W was a lowball goal. Once they got the system up and running again, they were able to push things to see how far they could get. And they got as high as 108 W!! This gets us past that magical 100-W barrier.
As I mentioned in yesterday’s piece, we don’t usually rush to press with breathless news, but this seems pretty big, given that it’s what so many folks have been waiting for. There’s been no formal announcement yet, but my source (who wishes to remain anonymous) said that the team’s excitement is beyond measure.
More details as they unfoold…
posted by Bryon Moyer
It’s one thing if different tools from different divisions of the same company don’t talk seamlessly together. Generally considered poor form. While that used to be common, EDA folks have cleaned that up a lot over the years.
It’s generally better accepted when tools from one company don’t necessarily integrate well with tools from another company. If there are good strategic reasons, it will happen. If not, then, as a designer or EDA manager, you’re on your own for patching the tools together.
But what about when, as a company, you go on a multi-year shopping spree? Now tools that used to be made by different companies have magically transformed into tools from different – or even combined – divisions within the company. So what might have looked tolerable amongst multiple companies starts to look messy within a single company.
Of course, we know who our intrepid EDA shopper is: They of the Endlessly Open Purse, Synopsys. They recently announced that they are bringing their various verification technologies together under the unified moniker “Verification Compiler.” This unites, to a degree,
- Static and formal analysis
- Coverage management/analysis
- Verification IP
The nature of how this comes together seems to have a couple forms, and more is yet to come. To a certain extent, this is a packaging/licensing thing, where what used to be separate products can now be purchased and managed together as a bundle.
From an outside user’s view, however, you will still run the tools as you always did – this isn’t an integration into a seamless, consistent, unified GUI – although that’s the part that’s likely to come in the future. For now, use models will remain similar.
But it’s not only a marketing thing. Underneath, these tools have had engines upgraded, and, in particular, they have been made to talk much more efficiently to each other using native integration rather than slower, less efficient (but more portable) approaches like PLI. The entire suite of tools can be scripted into a unified flow, rather than the current situation where each tool has a distinct flow.
The big win here thanks to these nuts-and-bolts improvements is performance. They post some pretty impressive gains – summarizing them as being 5 times faster (yielding 3 times the productivity). One formal project run by an unnamed customer ran 21 times faster. Capacity has also improved – in some cases by as much as 4 times.
One important message in the face of this inter-tool bonding: Verdi is remaining open. You may recall that one of the items in Synopsys’s shopping cart was SpringSoft, and the Verdi debug tool has a popular open interface and ecosystem. Even though they’re tightening their internal integration with Verdi, they’re not closing off access to outsiders.
In case you’re bringing out your checkbook right now, heads-up: unless you are amongst the anointed, you probably can’t get it yet. This is targeted for end-of-year broad availability; for now, it’s being wrung out by “limited customers.” I’ll leave it to you and Synopsys to decide whether you’re one of them.
And you can find out more about this in their release.
posted by Bryon Moyer
“How much power does it consume?”
This has been a key question ever since I started work as a product engineer many years ago. Heck, back then we even published power consumption numbers, although we used ICC as a proxy – we didn’t actually publish power, but you could easily do the multiplication with VCC to get it. (Yes, this was bipolar.)
These days, the concept is even more important, what with all the focus on battery-powered whats-itses. But in deconstructing a lot of what’s going on now, there’s an interesting nuance coming to the fore: energy vs. power.
- Energy is a “thing.” It’s something physical that has a measurable quantity.
- Power, by contrast, is not a thing; it represents the rate of flow of a thing, namely energy.
This is more than just an academic difference. Batteries and fuel cells can store more energy than a supercapacitor can, but they release that energy at a slower rate than the supercap. So one is capable of higher energy capacity; the other of higher power. The distinction actually matters.
So I find myself tripping more and more over the familiar phrase, “power consumption.” Power isn’t a “thing,” so it can’t be consumed. Energy is a “thing,” and it can be consumed.
So “power consumption” makes no conceptual sense; “energy consumption” makes a ton of sense.
An electronic device consumes energy, but, from a practical standpoint, you can’t know the energy consumed until you know how long you’ve run the device. And you have to be able to serve up the energy to the device from your energy store at the rate the device expects, or else you’ll starve it. So “power” is ultimately involved as a critical device requirement; energy consumption not so much.
So if “power consumption” is off the table, “power requirement” seems a suitable replacement.
I will therefore labor to use either “energy consumption” or “power requirement” henceforth.