Does anybody know an open source vhdl-ams simulator?

[Svenn Are Bjerkem]

Hi,

I have just googled around for a vhdl-ams simulator, and I only find
very expencive ones. Is it really no F/OSS vhdl-ams simulator out
there?

I know Al is working on Verilog-AMS in gnucap, but is that the only
F/OSS Verilog-AMS initiative out there?

[Dan McMahill]

Post by Svenn Are Bjerkem
Hi,
I have just googled around for a vhdl-ams simulator, and I only find
very expencive ones. Is it really no F/OSS vhdl-ams simulator out
there?
I know Al is working on Verilog-AMS in gnucap, but is that the only
F/OSS Verilog-AMS initiative out there?

As far as I know. Can't happen soon enough if you ask me. It is
getting so at least verilog-a (although not ams yet) is becoming
supported by some of the more mid-level simulators.

It seems to me that companies should *really* start providing
Verilog-AMS models for their mixed signal chips to help at least verify
connectivity and basic functionality of complex boards.

-Dan

[al davis]

Post by Svenn Are Bjerkem
I have just googled around for a vhdl-ams simulator, and I
only find very expencive ones. Is it really no F/OSS vhdl-ams
simulator out there?
I know Al is working on Verilog-AMS in gnucap, but is that
the only F/OSS Verilog-AMS initiative out there?

The difference is in the parser. Both have essentially the same
underlying algorithms. Where you find one, eventually you will
find the other.

There was a start from University of Cincinnati a few years ago.
As far as I know, it was only a start, and has not been
developed past the initial proof of concept. According to its
creator, the performance was very slow, and it was a subset.

That is the only one I know of.

If you want to help with gnucap, you can make it happen.

What the simulator takes directly will be determined by a
plug-in.

I am doing Verilog first because I see a higher demand for it,
and because it is less verbose and so is a more reasonable
replacement for the Spice format with manually generated
netlists.

When the language plug-in mechanism is working, which will be
soon, it is reasonable to do plug-ins for other languages.
After doing the first one, I expect others such as VHDL to be
easy.

What the simulator takes directly will always be a subset. A
more complete version of any language will use the model
compiler. Here too, I am doing Verilog first (actually second)
because I see a higher demand, and it should be relatively
simple to change the front-end to accept other languages that
are similar in concept, such as VHDL.

The model compiler generates C++, which is then compiled into a
model plug-in, that can be attached when needed. Most of this
part is already working.

I see needs for the following other formats:
VHDL
Spectre
MAST
Touchstone
PCB (without crosstalk)
gschem
QUCS
HSPICE
PSPICE
...

There are some others that need more than simple translation:
IBIS (90% done)
more detail from PCB (with crosstalk)
...

The simulator core is not locked into any language. All will
use plug-ins. All that exist will be equal in the sense of
using a similar plug-in, that stores in the same data
structures.

Does anyone want to help??? What is needed is to make the
plug-ins and compiler front-ends for the other languages.
After the first one is solid, you can use it as a model to make
others.

I see big opportunities here, but I can't do it alone.

al.

[Svenn Are Bjerkem]

Post by al davis
Does anyone want to help??? What is needed is to make the
plug-ins and compiler front-ends for the other languages.
After the first one is solid, you can use it as a model to make
others.
I see big opportunities here, but I can't do it alone.

I had the dream that I could use Signs VHDL environment for Eclipse
and extend it with VHDL-AMS capabilities to use an open source
simulator to do real mixed signal. This way I would use the same
environment to write the code (Eclipse) as to manage the HDL (Signs)
and eventually extend Eclipse with schematic capture capabilities to
get the schematics.

I guess a lot of developers will frown upon this, but I think Java and
Eclipse is the best fit to develop integrated development environments
also for electronic circuits. Steven Rubin of Staticfreesoft
(Electric) also went from c to java (via qt3) and found it a whole lot
easier to get the things right in Java.

The reason for me to wish to use Eclipse is that it is both an editor
and an environment written in a language that has some "rationale". I
know xemacs is a cool IDE, but it is lisp, and not so easy to attract
programmers.

[John Griessen]

Post by Svenn Are Bjerkem
I had the dream that I could use Signs VHDL environment for Eclipse
and extend it with VHDL-AMS capabilities to use an open source
simulator to do real mixed signal.

The Signs tutorial screen shots and words seem like they have FPGA design in mind,
and it seems like a tidy way to go about it. I wonder if they have considered the complexity
of "real mixed signal" though? They have no schematic tool yet...

I think the real first steps toward that wish of a goal is to help get verilog-AMS netlisting to work
with available netlist and schematic tools, (voila gnetlist, gschem), then hooking that into an IDE should be easy for any IDE
worth it's salt.

John Griessen

[Svenn Are Bjerkem]

Post by John Griessen

Post by Svenn Are Bjerkem
I had the dream that I could use Signs VHDL environment for Eclipse
and extend it with VHDL-AMS capabilities to use an open source
simulator to do real mixed signal.

The Signs tutorial screen shots and words seem like they have FPGA design in mind,
and it seems like a tidy way to go about it. I wonder if they have considered the complexity
of "real mixed signal" though? They have no schematic tool yet...

But they are making automatic schematics with geda symbols from vhdl
like you get when you use synopsys. Not without flaws, though, but the
logic is corrent.

The schematic editor must be made. And I think the connection with
schematic capture and HDL editing would be great. I have been looking
at some circuit and graph editing programs like circuitsmith, yEd and
argo-UML to see how it is possible to borrow ideas. I have also
studied electric a bit, but the editing interface is too old
fashioned. That's the nice thing about Eclipse, the infrastructure is
there, the user only need to write plug-ins to create the interface to
the user. And it is stupid not to learn from UML. There is an
initiative in direction SysUML to use existing UML techniques to do
Semiconductor system specifications.

Something like VisualHDL with a connection between analog and digital
through an HDL-AMS netlist as backend would be great. (Al has been
giving good arguments for using VHDL as a data storage format for
electronic circuits.)

Post by John Griessen
I think the real first steps toward that wish of a goal is to help get verilog-AMS netlisting to work
with available netlist and schematic tools, (voila gnetlist, gschem), then hooking that into an IDE should be easy for any IDE
worth it's salt.

I can help out with anything as long as I can access it via cvs or svn
and use Eclipse as an editor.

[al davis]

Post by Svenn Are Bjerkem
I guess a lot of developers will frown upon this, but I think
Java and Eclipse is the best fit to develop integrated
development environments also for electronic circuits. Steven
Rubin of Staticfreesoft (Electric) also went from c to java
(via qt3) and found it a whole lot easier to get the things
right in Java.

If you want to use Eclipse, that's ok. It a bad idea to require
it, or any other particular development environment.

If a plug-in interface to Eclipse is useful, that is fine with
me. Anything compiled in, even if it can be turned off, even
if it is off by default, isn't good.

I can understand Steve Rubin's comment that Java is more
productive that C. C++ offers most of the same advantages and
more. The biggest downside of C++ that I see is that beginners
can be overwhelmed by it if they try to see it all at once.
Java is a reasonable subset of C++, with some syntax changes.

I would not be surprised if the reason for choosing Java over
C++ is pressure from Sun.

After I moved gnucap (then ACS) to C++ from C, things got a
whole lot easier. Things got easier again when STL became
mature enough to use, when templates really worked .... Even
the old C++ without all that helped.

The move from Ratfor to C helped a lot too, but that is ancient
history.

On the other hand ... the ACS move to C++ was one factor in
spawning NG-spice.

[Dan McMahill]

Post by al davis

Post by Svenn Are Bjerkem
I guess a lot of developers will frown upon this, but I think
Java and Eclipse is the best fit to develop integrated
development environments also for electronic circuits. Steven
Rubin of Staticfreesoft (Electric) also went from c to java
(via qt3) and found it a whole lot easier to get the things
right in Java.

If you want to use Eclipse, that's ok. It a bad idea to require
it, or any other particular development environment.
If a plug-in interface to Eclipse is useful, that is fine with
me. Anything compiled in, even if it can be turned off, even
if it is off by default, isn't good.
I can understand Steve Rubin's comment that Java is more
productive that C. C++ offers most of the same advantages and
more. The biggest downside of C++ that I see is that beginners
can be overwhelmed by it if they try to see it all at once.
Java is a reasonable subset of C++, with some syntax changes.

one of those advantages is I'm not sure that java is as widely ported as
c++.

-Dan

[Svenn Are Bjerkem]

Post by Dan McMahill
one of those advantages is I'm not sure that java is as widely ported as
c++.

It is more widely ported than some of the applications written in C++.
In my very honest opinion, it doesn't help to have a programming
language that is ported to all kinds of ancient or exotic hardware
when installing and running on WinXP isn't possible or only with very
much extra hacking work.

Sun is taking efforts to really open their Java because they see that
they have a disadvantage on Linux systems. Once Java is going to be as
easy to install with any distribution packaging tool as gcc is, we can
start talking again about platforms supported. GPL does have its
advantages.

[al davis]

Post by Svenn Are Bjerkem

Post by Dan McMahill
one of those advantages is I'm not sure that java is as
widely ported as c++.

It is more widely ported than some of the applications
written in C++. In my very honest opinion, it doesn't help to
have a programming language that is ported to all kinds of
ancient or exotic hardware when installing and running on
WinXP isn't possible or only with very much extra hacking
work.

Java is widely ported enough. There is "gcj", which is a gcc
front end for java.

Claimed C++ porting problems are not problems with the language,
but the tendency to use libraries and the like that have
issues. Plain C++ ports fine. Now add some library, which
uses some other library ... You need to port all of them.

Post by Svenn Are Bjerkem
Sun is taking efforts to really open their Java because they
see that they have a disadvantage on Linux systems. Once Java
is going to be as easy to install with any distribution
packaging tool as gcc is, we can start talking again about
platforms supported. GPL does have its advantages.

I think the issue here is that many people see Java as a product
made by Sun, rather than as a general purpose programming
language. There needs to be competing implementations, like
there are for C and C++.

For us, who are putting out a suite of tools, licensed under
GPL, it doesn't make sense to depend on a single company
produced product. I suppose if it was licensed GPL ..... (it
might be, but it wasn't initially)

Like you say, GPL has its advantages.

As to porting, and giving an example ... Compiling a recent
version of Electric is not straightforward.