This was no mystery match-up. People have been asking the question for a long time and only recently got their answer: When is Synopsys going to buy EVE?

For those of you not in the thick of the emulation world, EVE makes emulators – well, actually, that depends on whom you talk to – more on that shortly – but most agree on this basic point. And Synopsys was the only one of the big three EDA guys without an emulator position. And there are only three major emulation platforms in existence: Cadence’s Palladium, Mentor’s Veloce, and EVE’s ZeBu. That left EVE as the obvious electron and Synopsys with the obvious hole.

So the electron has now filled the hole.

It’s been a rough couple of years for a lot of companies, and Synopsys in particular has managed to scoop up more than its fair share of little guys, many of which appeared to be on their last breaths. But some of the acquisitions – notably of EVE and SpringSoft – were not of that nature. These were more strategic.

Relative to EVE specifically, according to Synopsys’s George Zafiropoulos, the basic reason for the acquisition was that EVE had won over a number of major customers that were very happy with the technology. That presumably put EVE in a position of relative strength in merger talks. It’s also the reason why, in the short term, no changes are planned. George speaks in terms of the value of the product and business, but also of the team with a decade of experience under their belts. So that’s good news for the people involved.

Long-term changes reflect the fact that the EVE environment can now be integrated more closely with the Synopsys flow – and particularly with the SpringSoft debugging stuff. Whereas EVE was a “point tool” provider that needed to work in any flow, tighter integration now makes sense – without sacrificing the ability to use the emulator as a point tool in any flow.

The reason things aren’t so cut-and-dried with all this can be summarized in four letters: FPGA. This has opened up lots of opportunity for textbook marketing: define your own category and own it. There are three different technologies in use for the three different platforms:

• Cadence uses a custom processor.
• Mentor* uses a custom FPGA.
• EVE uses off-the-shelf FPGAs from Xilinx**.

So you can group and regroup any way you want.

• You could group them all together and call them all emulators. But nooooooo… that would be too easy.
• Cadence, naturally, cites groupings dividing the world into “emulators” and “FPGA-based emulators/prototypes.” Convenient, since that would leave only Cadence in the “pure” emulator business.
• EVE was able to position itself based on having the only non-custom platform. Although they didn’t really create separate marketing buckets as a result; they merely used that to identify what they felt their advantages were.

Grouping aside, Cadence’s Frank Schirrmeister points to attributes that emulation customers care about. By one study (admittedly from an organization that isn’t known for its transparency), those are:

• Execution speed
• Speed of design changes
• Debug visibility
• Real-world connectivity (for connecting to non-emulated data sources)
• Multi-user access (these are expensive boxes and need to be sharable)

Two of these characteristics depend on the underlying platform more than the other three: design turn time and debug visibility.

Both Cadence and Mentor can argue that, by using a custom architecture, they have designed with all of this in mind. By contrast, the Xilinx architecture was not targeted specifically for emulation. Obviously, this point has been leveraged against EVE in marketing materials.

The flip side of that is that Xilinx, having targeted a much broader space, has led – along with their archrival Altera – the process curve. So, in many cases, it may be that a theoretical deficiency in the architecture might be compensated by the fact that the underlying technology is two or more nodes ahead. Certainly that plays out in execution speed.

The bigger Achilles heel for the FPGA-based system comes in design turn time. At least in theory. Frank refers to a venerable relationship known back in the 70s or 80s as Rent’s rule. It relates the number of I/Os required to the amount of logic. You might think of it as showing how the perimeter of a shape (the I/Os) changes vs. the area of the shape (the logic contained). You can bulk up on logic, but at some point the I/Os become the bottleneck.

In an emulator, this is a consideration because of the need to partition a large design between multiple FPGAs. Breaking up the logic isn’t so hard, but doing so in a way that optimizes the number of interconnects between the FPGAs is more of a challenge. On top of that, you can toss on the well-known challenges of FPGAs when it comes to compile speed (as compared to compiling C code), particularly as the devices start to fill up.

With respect to debug visibility, Xilinx’s FPGAs, not having been designed specifically for an application where observability is a key attribute, wouldn’t be expected to have as many debug hooks as you might design into a custom architecture – whether a processor (Cadence) or an FPGA (Mentor). You can always create debug logic explicitly out of the logic fabric, which EVE does for some of its triggers and probes, but a competitor might bewail the fact that you have to sacrifice logic for that.

Complicating matters further, EVE capitalized on the backdoor that FPGAs have for downloading their contents for even greater visibility. Which, in fact, sent Mentor running to the courtroom; that case is still active (and no, no one is willing to comment on it).

So with all of that arguing against the viability of FPGAs, it’s no wonder that “FPGA-based emulation” might be relegated to classification with prototyping tools. I used to have a hard time myself understanding the difference between emulators and prototype vehicles. Especially when some were being marketed as “prototypes with emulator features/use models.”

The way I sort them myself is that emulators are for use earlier in the design cycle, before the RTL has settled down. This means that the design is likely to change often, so you don’t want to have to commit a ton of time to optimizing each revision; you just want to compile and go. You won’t get the fastest execution speed, but that’s part of the trade-off.

Once the design is solid, you move to prototyping, which almost always involves Xilinx or Altera FPGAs, and you spend a lot more time hand-polishing the logic to achieve as much as 10x the performance of the emulated version. RTL changes at this phase wouldn’t be popular.

So the question then is, does a box like EVE’s belong with prototyping boxes – because of the FPGA – or with emulators? To me, over-analysis can distract from the real basic questions. Forget what’s inside; how well does the machine perform for the desired usage?

For instance, you would expect the Xilinx tools to create a huge bottleneck when implementing a design in ZeBu. But EVE did their own compiler, zCUI, that traded implementation efficiency for compile time. The thinking was that packing the FPGAs as tightly as possible was a lower priority for users than compiling quickly. As long as the design fits in the emulator, who cares how many FPGAs it uses or how efficiently they’re used? (Or whether the probes were built out of the logic fabric or a dedicated resource?)

So that’s why it makes sense to back out and say, if the designs fit and the performance is there, then all three boxes can compete on those five (or any other) characteristics. And one box might do better on one axis and another might do better on a different axis. But from a use standpoint, it makes much more sense to me to classify the emulators – FPGA or otherwise – together. Prototype tools also have their place, but it’s a different place – and just happens to use FPGAs.

As to who the winners and losers are with respect to those five or any other criteria, I’m not going to opine since I don’t have independent, verifiable data. I’ll let the other studies defend themselves. But from a common-sense standpoint, if Synopsys is telling the truth about large customers liking the EVE platform, then there’s a proof point that suggests that niggling about the internals misses the crux of the matter: there’s a problem that needs solving, and there are three – not one or two – ways of attacking it successfully.

All three EDA vendors now have an emulator weapon, and no amount of category-creating is likely to change that. 

*Mentor was offered and declined the opportunity to comment for the purposes of this article.

**Synopsys has no plans to challenge the choice of Xilinx in the platform. At this point, that’s not really a vote against Altera; it merely reflects (a) the huge legacy in place and (b) the fact that there aren’t any problems that would warrant considering a change.