Home > Community > Blogs > Industry Insights > q amp a phil moorby hdl pioneer and cadence fellow from verilog to parallel programming
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Q&A: Phil Moorby, Verilog Inventor and Cadence Fellow, Sees a Parallel Future

Comments(0)Filed under: Industry Insights, SystemVerilog, Cadence, Synopsys, VHDL, Q&A, Verilog, 25th anniversary, Gateway, parallel programming, HILO-2, HILO, HDL, parallel simulation, Musgrave, Peter Flake, hardware description languages, Co-Design Automation, Simon Davidmann, Superlog, Moorby, Phil Moorby

Few people have influenced the EDA industry as much as Phil Moorby, inventor of the Verilog hardware description language (HDL) and the first Verilog simulator. As Cadence celebrates its 25th anniversary this year, Moorby was a key contributor to that success, both as the developer of Verilog at Gateway Design Automation in the 1980s and as a Cadence fellow in the early 1990s. In 2013, Moorby rejoined the company as a Cadence fellow.

In this interview, Moorby talks about his work with HILO-2, an early commercial HDL and simulator; his role in the development of Verilog at Gateway; his work with the Superlog language, which evolved into SystemVerilog, at CoDesign Automation; and finally, his interest today in parallel programming and simulation.

Q: In 1976, you joined Prof. Gerry Musgrave's group at Brunel University and began work on the HILO-2 language and simulator. What work did you do with HILO?

A: When I joined the group in 1976, HILO-1 had already been written, and it didn't include an HDL as we know it. Instead, it was a simulator of carefully chosen built-in low-level primitives. Peter Flake and I started to bounce ideas back and forth about what a better language would be like. We needed a language that users could write to describe all kinds of higher level blocks.

When we got going on HILO-2, four of us were doing the coding. Peter was more focused on the design of the language and test generation, and I was more focused on how the simulator would work. Gate-level simulation was the focal point. The HDL was more of an experimental add-on on top of it.

The HILO-2 project was almost completely focused on the test generation problem. The customer was not interested in simulation as we understand it today—they would say, "we do breadboarding for that, but what we really need is a fast fault simulator." The end goal was to produce an almost automatic test generator. We sold the simulator through GenRad.

I then worked on the HILO-3 project for about three years. That was essentially a re-implementation of HILO-2.

Q: In 1984, you joined Gateway Design Automation, where you invented Verilog. What was the original idea behind Verilog?

A: I had ideas about doing a very high-speed, gate-level simulator, and that eventually became the XL part of Verilog. Prabhu Goel [Gateway founder and CEO] had a strong vision about getting into synthesis. We designed Verilog HDL specifically for synthesis. But Prabhu went out and identified three companies who had already gotten started with synthesis—Synopsys, Trimeter, and Silc—and saw that we would not be able to catch up. So we tried to get these companies to take on the language while we would make money with the simulator. We only got traction with Synopsys, which licensed the language from Gateway.

Q: There were other HDLs and simulators around. What was different about Verilog?

A: The early customers we engaged with saw the HDL part [of Verilog] as experimental. What took off and started to make money was the gate-level simulator. We were head-to-head with our competition, which was hardware acceleration. Verilog included RTL simulation, but what was really fast was gate- and switch-level simulation. Here, the primitives were hard-coded inside the simulator.

By then I had implemented simulators so many times that I knew what worked and what didn't. I found a way to make it go even faster by giving up a little bit of accuracy on the gates. This made Verilog-XL go an order of magnitude faster than other gate-level simulators, but still provided sufficient accuracy to get the job done.

Q: Cadence bought Gateway in 1989, and you were a Cadence fellow for a few years. What were you working on?

A: I had a couple of projects. One was high-level modeling, which never got too much traction in practice, because users didn't know how it related to the low level. Another was to implement the Verilog-XL algorithm in hardware.

I was also convinced I could help Cadence deal with VHDL simulation. We were behind on VHDL and the EDA politics of the time were saying we've got to do more with VHDL. I located a couple of guys who had a startup, and they had done such a good job implementing a VHDL simulator I said Cadence should buy them. After I left Cadence, their VHDL solution became the basis for the Leapfrog native code VHDL simulator [1993].

At the end of 1992, I went out and explored some other industries. Since then I've been in and out of EDA.

Q: While you were at Cadence, Verilog became an open industry standard, and a "language war" divided VHDL advocates and Verilog advocates. As we all know, Verilog is much more widely used today. Why is that?

A: I think the practical guys down in the trenches found the [Verilog] language to be much friendlier. I think the way we defined the language semantics was not quite so restrictive as VHDL. I always thought that VHDL, as a language, was much better constructed. But the people behind it did not realize that the language cannot drive the market. The core ability of the simulator, especially at the gate level, is what drives the business, and the language is really subservient to that.

People behind VHDL thought if we define the language really well, then implementers will do a good job. In the beginning, they did a terrible job. VHDL simulators struggled to get the sort of performance Verilog simulators were getting.

Q: In 1999, you were at CoDesign Automation with Peter Flake and Simon Davidmann, working on Superlog, which set the stage for SystemVerilog. What was the intent behind Superlog?

A: I was out in another industry and I talked to Peter and Simon from time to time. Peter thought we could develop a better language, and we talked about various ideas. Peter talked about doing something similar to Verilog, but not quite the same.

Peter was the primary designer of Superlog. I helped implement the language on a compiled code simulator. I helped guide the language as it was designed, and did some fine tuning of some of the simulation algorithms.

Superlog started to get traction with a few companies, and they said that if this is not a strict subset of the Verilog language standard, we can't go with it. So CoDesign revamped Superlog and made it compatible with the Verilog standard.

Q: Synopsys bought CoDesign in 1992, and you went to work for Synopsys for six years. What was your role there?

A: Synopsys took a large part of Superlog and extended it with the test language and the assertion language, and pushed it out to the standards committees. I worked on the new [SystemVerilog] language but not all of it. I worked on the assertions and the problem of debugging assertions, and I worked on simulation time wheel models.

Q: You were then out of EDA for a while. What brought you back to EDA, and in particular back to Cadence, in 2013?

A: One of my strong interests today is the general problem of parallel programming. Specifically, I want to figure out how to make parallel simulation work. There have been many attempts to make parallel simulation successful in EDA, and most have failed.

I had some very good interviews [at Cadence] and found we were very much in tune. I'm also very impressed with the turnaround that Lip-Bu Tan has managed to do with the company over the past four years. That was a big attraction.

Q: What's the problem with parallel simulation?

A: The amount of parallelism in a typical event-driven simulator is not enough to make parallelism successful. If you're thinking of speeding up simulation by one or two orders of magnitude, you've got to have 50 or more things you can do in parallel all the time without there being a significant communication overhead. The problem is that with traditional simulation techniques there aren't 50 things you can do in parallel all the time. Very often, events become sequentially dependent on other events and you can't execute them in parallel.

There are other ways to look at the problem, and I think we can make more things happen in parallel. What drives me is knowing that parallel computing has to be a thing of the future. The pressure is mounting. To do parallel programming, especially for simulation, is quite a challenge and hence my interest.

Richard Goering

Other 25th anniversary blog posts:

Video: Alberto Sangiovanni-Vincentelli on Founding Cadence, and the Next 25 Years of EDA

25th Anniversary: Hogan on EDA History and Three Little Words

EDA in the 1980s—the "Dazzling Decade" of Electronic Design Automation

25 Years of Innovation at Cadence—25 Key Milestones

25 Years of Innovation: Then, Now, and the Road Ahead

Video: Cadence Founder Jim Solomon on Company History, and What EDA Needs Today

25th Anniversary: Innovation Evolution Through One Customer's Eyes

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.