Video Interview with the developer of the Spectre Circuit Simulator

[Daniel Payne]

Ken Kundert wrote the Spectre Circuit Simulator while at Cadence, he's now President at Designer's Guide Consulting. Here's a video interview with Ken Kundert, Henry Chang (ex Cadence) and John Pierce (Cadence).


<iframe width="560" height="315" src="http://www.youtube.com/embed/o9MYZ1gxvLY" frameborder="0" allowfullscreen=""></iframe>

 

[simguru]

Somewhat disingenuous. Ken did the Verilog-AMS standard work at OVI/Accellera because Spectre needed to be morphed into something "standard" to compete with Analogy/Mentor's products which were aligning with VHDL. After we defined the Verilog-A "subset", he did various things to stall the progress of the AMS part - and because of that it has still not been incorporated into the mainstream Verilog standard (now SystemVerilog).

There are also various things in Verilog-AMS that don't work properly because "doing it right" didn't fit with Ken/Cadence's product and business plans. I was marginally amused after Ken left Cadence and started consulting when he came back to the AMS committee to try and fix the things he was responsible for breaking in the first place.

Note: Verilog-AMS is still a work in progress. If you are a chip designer who would like it to work properly, you really need to get your employers to invest in sending (competent) people to the Accellera and IEEE committees to complete the job that Ken started in ~ 1994 and failed to follow through on.

 

[Ken Kundert]

Ouch!
<br><br>
As one of the originators of the idea of Verilog-AMS and the developer of the
Spectre-HDL language, it fell to me to create the original proposal that would
be the starting point for the analog portion of the language, which represented
the first phase. Other members of the committee critiqued that proposal and
suggested changes and additions. We all did not agree on every detail of the
language, but in the end decisions needed to be made, and they were not made by
any one individual, but by the committee as a whole. Some people did not agree
with some aspects of the language, and they took the rejection by the committee
of their ideas very personally. I am surprised and somewhat saddened to see
that after all these years that the hard feelings still linger.
<br><br>
At the time and ever since I have been attacked personally for what happened. As
such, I have tried to take a much less active role with the Verilog-AMS
committee in the hope that feelings would soften. Apparently that has not
worked.
<br><br>
For the record:
<OL TYPE="1">
<LI>We did not initiate Verilog-AMS because 'Spectre needed to be morphed into
something "standard" to compete with Analogy/Mentor's products'. At the time
we were focused on trying to take the analog IC simulation market from
HSPICE. Both Spectre and Mentor's Eldo were bit players in the IC circuit
simulation market, and Analogy was not in the market at all (while it did
have circuit simulation capabilities, it was considered a system simulator
and largely unused in the IC market). We developed SpectreHDL to
distinguish ourselves from HSPICE, but quickly realized adoption of a new
language would be slow and we would be better served if it was a standard.
At the time VHDL-AMS development had been in progress for almost 5 years and
appeared to be stuck in endless academic debates. We decided the best path
forward would be to extend Verilog. That way it could be done outside the
auspices of the IEEE and so move forward much more quickly. In addition, it
would put pressure on VHDL-AMS by giving it some competition. We were
successful in both aspects. Unfortunately, the drive to quickly develop the
standard seems to be a contributing factor in the hurt feelings.

<LI>At no time did I attempt to stall the progress of the committee. Indeed the
opposite is true. I worked very hard and put in long hours to push the
standard forward and get it out has quickly as possible. As I mentioned
above, after Verilog-A was complete I did take a much less active role in
the committee because of the personal attacks, but I continued to work in
the background to move the standard along.

<LI>I did come back to the committee to try to fix a few things, but it was not
to 'fix the things I was responsible for breaking in the first place'. There
were two things. First was to restore a feature that had accidentally been
dropped (signal flow currents). The second was to clarify the reset behavior
of the integrator.

<LI>It is hard to make a case that '"doing it right" didn't fit with
Ken/Cadence's product and business plans', given the tremendous success and
impact that Verilog-A has had. Developing an analog hardware description
language is not easy, and after 15 years I can look back and see lots of
things we should have done differently (none of which were raised at the
time). But I also have to say that it works pretty well and I am proud of
what we all accomplished.
</OL>
<br>
One last thing. If Kevin (simguru) really wants more competent people to
contribute to the Accellera and IEEE committees, he should probably not be
publicly attacking those that contributed in the past.
<br><br>
-Ken

 

[simguru]

As one of the original committee members developing Verilog-AMS, I don't remember much other than the analog portions coming out of Cadence (I was at Chronologic at the time). We agreed to delivering an "analog-only" subset that became "Verilog-A" as an interim goal. I worked on the mixed signal parts at the same time - which everybody was more or less happy with until after the Verilog-A delivery at which point the Cadence team announced they had no interest on following through with my proposal and wanted to do something entirely different - that alone stalled the process by at least a year. Bringing up patent issues later on probably helped keep Verilog-AMS from being integrated into Verilog prior to its departure to the IEEE. Tactics like promising a counter proposal for AMS back-annotation, then completely failing to deliver also did not help.

Attempts to make the standard work in the same manner as Cadence tools by default and to support other semantics were also rejected out of hand.

My issues are purely technical, not having a fully working and integrated Verilog-AMS gets in the way of plans I have for developing EDA tools to improve the overall efficiency and throughput of the IC design process. The hard feelings will persist until the technical issues are resolved.

While I'll agree that your contribution to the development of Verilog-A was huge, it is heavily counterbalanced by the petty self-serving politics you brought to the process.

-----------
Notes:

Analogy's products were competition for the behavioral analog modeling space.

 

[Ken Kundert]

Kevin,
<br><br>
You have always accused me of orchestrating some kind of a Machiavellian plot
against you and your proposal. It is simply not true. Not only was I in no
position to do that, it is also just not the way I work.
<br><br>
At the time I did not have much in the way of mixed-signal experience and so
I was taking a back seat to others from Cadence with more knowledge and
experience in that area. As such, I was really not that involved in the AMS
work.
<br><br>
I liked some of your ideas, and was hoping to see them adopted. For example, the
light-weight D/A converters seemed like they would be very helpful in
testbenches, and the back-annotation of parasitics seemed like another nice
contribution. Unfortunately, you never convinced the rest of the committee on
those points. But you were more effective on some of your other ideas, and in
the end proposal that was accepted seemed like a blend of your's and Cadence's
ideas.
<br><br>
The patents stemmed from work done on SpectreHDL that predated the inception of
Verilog-A. Immediately after they issued Cadence donated rights to OVI.
Currently those patents protect all vendors of Verilog-AMS equally.
<br><br>
I did not promise a counter proposal for AMS back annotation. Perhaps someone at
Cadence did, I do not recall. However, I am not Cadence. And, as I said before,
I was not that engaged with the committee at the time.
<br><br>
-Ken

 

[simguru]

It wasn't very Machiavellian, it was just plain strong-arm tactics using Cadence's clout with committee hierarchy.

I don't think anyone involved would claim you took a back seat in the process, and I remember one of the Cadence team doing an about face between meetings where he was obviously told to follow the party line. However I'm happy to agree your expertise lies in analog/RF simulation rather than mixed-signal methodology.

Richard Trihy promised the back-annotation proposal, but he was working for you - and by 2nd hand accounts didn't enjoy it.

And you are correct your presence was not necessary for Cadence to screw up the process for everyone else, Jon Sanders did a bang-up job of making sure nothing got changed/fixed after you stopped participating.

[Don't get me started on wreal.]

 

[Ken Kundert]

Kevin,
<br><br>
Strong-arm tactics? I really have no idea what you are talking about. There was
nothing going on behind the scenes that I was aware of. I believe the problems
you had getting your ideas accepted by the committee stemmed from your inability
to compromise and your polarizing nature. Surely you must accept that holding
a grudge like this for over 15 years lends credence to that view.
<br><br>
Richard did not work for me. In fact, nobody worked for me. I was a Fellow at
Cadence during that time, meaning that I had authority over no one other than
myself. My only ability to get people to do things for me was through convincing
arguments. And that is the way I worked, both at Cadence and in the Verilog-AMS
committee.
<br><br>
I am with you on wreal. The existing capability is really weak. Do you have
a proposal on how to fix it? Perhaps we can put this behind us by working
together to get wreals fixed.
<br><br>
-Ken

 

[simguru]

Me polarizing? I remember another committee member storming out after discovering you had done completely the opposite of what you had agreed to do in LRM write up. I also went to great lengths to support Cadence's existing semantics into my proposals and you were entirely intransigent.

My proposal for deprecating wreal is about as old wreal itself and is on-line in Mantiss - 0002378: Deprecate wreal - EDA.org Mantis

I distinctly remember wreal being something that you were responsible for, but like everything else, maybe you remember differently.

Personally I won't be participating in the Verilog-AMS, standards effort seriously until someone is prepared to pay for me to be there so that I have full voting rights. Likewise SystemVerilog. Currently the whole HDL lanscape is an unholy mess, and thanks to the lack of support for my efforts over the years I can happily claim that it is not my fault.

 

[Ken Kundert]

Kevin,
<br><br>
Clearly you and I remember things quite differently. However, I do remember
opposing you on wreals. Seeing your proposal again reminded me why. You were
trying to use continuous-time syntax on a discrete-time net. There was no need
to do so. Verilog is innately a discrete time language and it was easy to build
wreal into the native schemes already available for discrete-time nets. By
adding wreal to the existing set of wire types (wire, wor, wand, ...) we added
the capability with a very modest change to the language, making it possible for
Verilog to pick up wreal without having to pull in anything else from
Verilog-AMS. Your proposal required that Verilog inherit the concept of
disciplines, access functions, and the contribution operator. In addition it
muddled the meaning for the contribution operator. Finally, it does not add
anything beyond what was originally accepted, which I reiterate was weak.
<br><br>
At the time I told you I did not like your proposal and I told you why. If you
wanted my support, you have every opportunity to say so and I would have worked
with you to come up with something that was mutually acceptable. However, you
did not. When it came time to pick one, I agreed with everyone else at Cadence
that we should cast our one vote for the proposal that was selected. I still
believe it was the right choice.
<br><br>
-Ken

 

[simguru]

The goal (as far as myself and OVI were concerned) was a single language so the "having to inherit..." was immaterial. Your proposal introduced an unnecessary "wire type" and behavior that we already had syntax for - polymorphic syntax is a well accepted concept in software circles, and the differentiation between discrete and continuous domains is fairly easy in Verilog-AMS because the blocks are clearly named (unlike {} in C). Since wreal is not part of the regular discipline/contribution/driver/receiver scheme it is impossible to type/discipline check its connections and the designer's intention is entirely unknown.

Your second paragraph is complete fiction with respect to being cooperative.

However you are not alone in adding dumb and unnecessary constructs to HDLs, wreal is actually fairly benign compared to Gord's "interconnect" proposal for handling user-defined types in SystemVerilog, but I suspect that will be DOA with the customers.

Fortunately most of this stuff is fixable with some simple rewrite rules and minor semantic changes, but it looks like it will be a while before that happens.