Some of those engineers regrouped under the leadership of Luc Burgun, and Emulation Verification Engineering (EVE) was incorporated in Paris in April 2000. The initial mission of EVE was to offer emulation services and, in particular, to create custom transactors while laying the groundwork for an emulator product.
While it’s hard to grow a service business, the income from services helped fund product development. It – along with flexibility on the part of the team – let them bootstrap the company without seed investment.
EDA WEEKLY: Wait. Were you part of the new Company EVE at this point?
No, I was not. I already left Mentor in 1999 to join Synopsys in a marketing position in a small verification consulting group. Since 1996, at Mentor I had the role of technical marketing manager in their emulation division formed after the acquisition of Meta Systems. My 1999 departure from Mentor was motivated by the frustration of being prevented from performing my technical marketing tasks in the US. That was due to a litigation initiated by Mentor against Quickturn in 1996 that turned into an epic battle that lasted several years.
After a relatively short time at Synopsys, a startup by the name of Get2Chip really got my juices flowing. They offered me in Silicon Valley the opportunity to take on more and more marketing responsibilities, and they allowed me basically to “run my own show” for a year and a half as I wished.
It was not until the Spring of 2002 that Luc Burgun offered me a chance to join EVE and set up operations in the USA. EVE’s first emulation product was almost ready and they needed to launch the newborn system onto the market. My experience at Get2Chip turned out to be fundamental in getting me going.
EDA WEEKLY: EVE Paris already had a product by then? Had they even raised any outside funding yet?
No, they hadn’t. The first emulation product, called ZeBu-ZV – ZeBu stands for Zero-Bugs – had been funded entirely by the internal cash flow from services provided to customers by the EVE team.
Those were heroic days. In fact, for about a year after joining EVE I worked from home, converting my second bedroom into a temporary office. For the first 5 months I did not have a salary. My compensation was in the form of stock (this was also true for all the worldwide executives of EVE at the time).
By June of 2003, I was finally able to move the EVE-USA operations into a formal corporate office complex in downtown San Jose:
EDA WEEKLY: OK. Tell us the rest of the first product story.
The original team had made a number of key strategic and technical decisions during the product #1 development project.
The first critical decision was about how the emulator would be implemented. The standard approach of the day would have involved creating a custom ASIC with the necessary logic, routing, and observability/controllability resources for implementing, testing, and debugging complex logic.
But even then, and at the 180-nm node, the cost of doing an ASIC was daunting, and it was, practically speaking, out of the reach of such a small organization.
So the EVE team decided to adopt commercial programmable logic instead, taking advantage of the logic and routing resources already provided in large FPGAs.
The next big question we had to answer was which FPGA to use. Both Xilinx and Altera made (and make) large FPGAs that could handle the kinds of projects we were targeting. Altera had the edge in cost and size of device, but Xilinx had a key feature that ultimately gave Xilinx the edge, called “readback™.”
EDA WEEKLY: Please elaborate.
Both Altera and Xilinx have the capability of reading back the bitstream that configure the devices. This is critical for ascertaining that the devices have been programmed correctly. But Xilinx devices take this one step further: you can also get the state of each register in the device, providing complete observability on the state of the implemented system. Before the introduction of the Xilinx Virtex family in 1999, you had to read out the entire configuration bitstream to access the registers; since then, they have refined it such that you can read out selective chunks of the design state.
This capability provides any user of a Xilinx FPGA the ability to observe the internal state of his or her function at any point for verification or debug purposes. Such observation of a design is powerful, whether for a function destined to stay in the FPGA in production or for one that is developed in an FPGA for eventual implementation in a custom chip. This tipped the scales in Xilinx’s favor, and, since then, EVE has ridden the Virtex roadmap to develop successive families of emulators.
EDA WEEKLY: What else was different about EVE’s first system?
As we put our first system together, we made one other strategic technical decision that has proven to be of great value. An emulator needs two key functions that will vary according to the needs of the design being emulated. First is, of course, the design itself – the so-called “design under test” (DUT). But the DUT needs to communicate with a host computer, which may be simulating other portions of the design and/or the testbench. A specific interface standard, the SCE-MI interface, exists to facilitate this communication. And, to keep the system running quickly, the interface runs at the transaction level. This means that transactors must be provided in the emulator. Those transactors must run as quickly as possible, and will vary according to the DUT – or even the test – being implemented.
Traditional emulator design made available a lot of logic resource; that resource was used for both the DUT as well as for the interfacing logic and transactors. The clocking capability was determined by the combined effects of the design and the interface. Multiple clock domains are common today, but, in the early days, the needs of the DUT ended up compromising the speed at which the interface logic could run.
You can find the full EDACafe.com event calendar here.
To read more news, click here.
-- Russ Henke, EDACafe.com Contributing Editor.
