which commercial HDL-Simulator for FPGA?

[kkoorndyk]

On Jun 19, 5:42 pm, jhal...@TheWorld.com (Joseph H Allen) wrote:

In article <20080619124737.4526b...@wolfenstein.jpl.nasa.gov>,
Jason Zheng  <Xin.Zh...@jpl.nasa.gov> wrote:

Invoke vsim with -do "log -r *; run -all; quit -f" and -wlf
"mydump.wlf", and you'll get similar results (just in a different
format). In my experience ncsim is faster than Modelsim, and of course
it carries a higher price tag.

This didn't work, but I eventually figured it out:

Start with an empty directory except for some verilog files you want to
simulate:

# Create work directory
vlib work

# Compile verilog files (vcom for vhdl)
vlog tb.v
vlog dut.v

# Simulate
vsim -do "log -r *; run -all; quit -f" work.tb

   - this creates a vsim.wlf file with everything in it just
     as you say.

Now try to view the waveform.  If I try:

vsim -wlf vsim.wlf work.tb -do "view wave; add wave *"

This brings up modelsim GUI and opens the waveform viewer window.  All of
signals are in the viewer, and they're all empty.

But this does work:

vsim -view vsim.wlf -do "view wave; add wave *"

but it won't work after you have done the previous vsim -wlf command, vsim
-wlf does something to the .wlf file or sets something in an initialization
file somewhere.  I had to re-run the simulation before "vsim -view ..." for
it to work.

The "-wlf XXXX.wlf" option renames the output file to 'XXXX.wlf'. So
if you run your sim and then run the command with the -view option,
it'll work fine. If you run 'vsim -wlf vsim.wlf work.tb -do "view
wave; add wave *"', it erases your previous vsim.wlf and opens a new
one with that name. That's why the waveform opens with no data.

I'll typically add the signals I want to log to a .do file instead of
logging all of the signals in a design. The more signals you log, the
slower ModelSIM runs.

I notice that when the GUI is open, I can't also run a simulation on the
command line because there is only one license.

Yea, but if you have the GUI open already, why not just run the sim in
the GUI?

 

[General Schvantzkopf]

On Fri, 20 Jun 2008 07:51:58 -0700, Mike Treseler wrote:

General Schvantzkopf wrote:

The Altera ModelSim is dog slow which is to be expected, I'm sure that
Mentor has deliberately crippled it.

NC, Linux 0:06:34
Questa, Linux 0:07:15
Questa, XP 0:18:14
Altera ModelSim, Linux 1:00:13


Thanks for taking the time to run the test and for sharing the results.
Interesting that speed is roughly proportional to the cost of the
license.

While the oem version is "dog slow" in this lineup, it is still quite
useful for debugging rtl when all the licenses are checked out.

-- Mike Treseler

What should be of most interest to anyone who is looking to buy a serious
simulator is the difference between Linux and XP. I ran the same version
of Questa on both Linux and XP with the same license. Questa runs three
times as fast on Linux as it does on XP. I'm pretty sure that the time
difference can be attributed to the performance of the Linux file system
(EXT3) vs the XP file system (NTFS). The real purpose of my investigation
was to compare various Virtualization tools. I gathered the numbers that
I posted before on the native OSes to give me a baseline. I then ran the
NC and Questa tests on VMware Server, VMware Workstation and KVM. When
using a virtual disk all of the VMs were only 5-10% slower then native,
KVM being the fastest. However if I used a host machine directory that
was accessed via NFS the performance dropped dramatically, about 2.5X for
VMware and 5X for KVM. VMware's shared folders were just as fast as
VMware's virtual disk performance i.e. about 10% slower then the native
performance. The NFS mounted host directory performance on VMware was
about the same as native XP performance which leads me to believe that
XP's problem is it's file system.

 

[General Schvantzkopf]

On Fri, 20 Jun 2008 15:53:44 +0000, Joseph H Allen wrote:

In article <485BC40E.3020008@gmail.com>, Mike Treseler
mtreseler@gmail.com> wrote:
General Schvantzkopf wrote:

The Altera ModelSim is dog slow which is to be expected, I'm sure that
Mentor has deliberately crippled it.

NC, Linux 0:06:34
Questa, Linux 0:07:15
Questa, XP 0:18:14
Altera ModelSim, Linux 1:00:13


Thanks for taking the time to run the test and for sharing the results.
Interesting that speed is roughly proportional to the cost of the
license.

While the oem version is "dog slow" in this lineup, it is still quite
useful for debugging rtl when all the licenses are checked out.

-- Mike Treseler

It would be interesting to see Icarus in this list. Also Verilator...

I haven't been able to get Icarus to work, it's not complete enough to
run any of our testbenches. We aren't doing anything fancy, in fact all
of our code is strict Verilog 95 it's not even 2001.

 

[Patrick Dubois]

On 19 juin, 22:45, rickman <gnu...@gmail.com> wrote:

I use a purely HDL hierarchy. I find that top level schematics or
even low level schematics of large functions tend to end up being more
like a net list than a drawing anyway. You have pins with names X,Y,Z
connected to net R,S,T on page 1. On page 2 you have nets R,S,T
connected to another part with pin names A,B,C. Making it a drawing
doesn't add much in my opinion. Once I gave up hope for schematics
and embraced the HDL world, I found joy in a life of text files and
the infinite advantages they have in the land of version control!

I agree that a top level schematic is exactly like a netlist, but the
difference to me anyway is that I can quickly grasp how each blocks
are connected together. I try to keep most blocks on one large 11x17
page. Here's an example of what I mean:
http://www.yousendit.com/transfer.php?action=download&ufid=B152F0A35F44CD17

With a netlist, I have to read the several lines of vhdl code to
understand how the blocks are connected and that takes a longer time.
Ideally, the vhdl netlist is also accompanied by a block diagram. With
the schematics flow, the block diagram comes free.

The drawbacks of course are the version control problems associated
with schematics files and the lack of a standard file format. To me
the version control issues are not a big deal because all the meat is
in the vhdl blocks anyway, not the top level.

Patrick

 

[Jason Zheng]

On Fri, 20 Jun 2008 10:52:13 -0500
General Schvantzkopf <schvantzkopf@yahoo.com> wrote:

The NFS mounted host directory performance on VMware was
about the same as native XP performance which leads me to believe
that XP's problem is it's file system.

That's hardly a convincing proof that all the performance increase is
due to file system. In my experience, NFS does slow down ncsim a lot
when I turn on the waveform dumping, but without waveform dumping,
there is no noticeable performance difference after the
design elaboration.

I'm not saying filesystem isn't part of it, but for a long simulation
with no data logging, 99% of the time the simulator is not doing file
I/O. Rather, I believe the following two play a more major role in the
speed difference:

1. Context switching. Linux is very very good at this. In a workstation
environment where I/O interrupts happen hundreds of times a second,
context switching happens everytime the CPU switch to run from one
process to the next one. What's good about the Linux kernel is that you
can tune a lot of things: the amount of interrupts, how frequently
the kernel service them, and how pre-emptible the kernel is. A
fine-tuned batch server can very fast. Not so much help from XP. I
believe Windows 2000 does have an option to choose between server and
desktop mode, but not sure what difference it makes.

2. Memory management. Linux is again very very good at this. Filesystem
caching and virtual memory management works hand-in-hand. My 1GB RAM
workstation ran 99.9% of time without going to swap partition, whereas
in Windows XP, the same workstation constantly sees harddrive
thrashing, especially after running a very memory intensive job.



--
Faster, faster, you fool, you fool!
-- Bill Cosby

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

General Schvantzkopf wrote:
| I haven't been able to get Icarus to work, it's not complete enough to
| run any of our testbenches. We aren't doing anything fancy, in fact all
| of our code is strict Verilog 95 it's not even 2001.

Current snapshots are much improved, and bug reports are welcomed.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIW+XmrPt1Sc2b3ikRAtL9AKCykWIDYFWQkNqwfjcAJUgXewEa0wCgxqwt
6U/NtBgPoBg4Y7aF5Ki6NsY=
=YODt
-----END PGP SIGNATURE-----

 

[Mike Treseler]

Patrick Dubois wrote:

I really like to create a schematic top level with blocks that are
either more schematics themselves or directly vhdl blocks.

I agree with rickman on the notion of a pure HDL hierarchy,
but, like you, I also like to see structural views at all levels,
including the top. However, I don't like to edit
or to maintain graphical sources.

I let the quartus rtl viewer draw my schematics
based on my synthesis code alone.
I can bring it up live to drill down
module by module or print out pdfs
at any level like this:
http://mysite.verizon.net/miketreseler/uart.pdf
http://mysite.verizon.net/miketreseler/stack.pdf

The state-machine editor in Active-HDL is another story. To me simple
state machines don't need to be represented by a diagram to be
understood. On the other hand, large ones are hard to represent in a
diagram. So in the end I only write vhdl state machines.

Yes, a case statement is easy to write, read, and sim.
Drawing curvy arrows and attaching equations is fun once.

-- Mike Treseler

 

[Mike Treseler]

On Fri, 20 Jun 2008 07:51:58 -0700, Mike Treseler wrote:
While the oem version is "dog slow" in this lineup, it is still quite
useful for debugging rtl when all the licenses are checked out.

General Schvantzkopf wrote:

What should be of most interest to anyone who is looking to buy a serious
simulator is the difference between Linux and XP.

I thought maybe that went without saying.
It is the main reason I maintain an SE license.
Not only is it faster in linux (your numbers look about right to me),
but I can take advantage of the ease of scripting
make and vsim commands to do things like daily
builds and verification from an svn repository.

I ran the same version
VMware's shared folders were just as fast as
VMware's virtual disk performance i.e. about 10% slower then the native
performance.

Thanks for the VMware info.
I'm still old-school with
two optiplex boxes and a kvm switch.

-- Mike Treseler

 

[General Schvantzkopf]

On Fri, 20 Jun 2008 10:07:19 -0700, Jason Zheng wrote:

On Fri, 20 Jun 2008 10:52:13 -0500
General Schvantzkopf <schvantzkopf@yahoo.com> wrote:

The NFS mounted host directory performance on VMware was about the same
as native XP performance which leads me to believe that XP's problem is
it's file system.

That's hardly a convincing proof that all the performance increase is
due to file system. In my experience, NFS does slow down ncsim a lot
when I turn on the waveform dumping, but without waveform dumping, there
is no noticeable performance difference after the design elaboration.

It's not NFS that's the problem with the VMs it's the virtual IO
performance. I looked at the effect of NFS alone by using a directory
that was mounted on a second Linux machine that was connected to my test
machine via gigabit Ethernet. The degradation of native NC over a true
gigabit network was negligible, about the same as running it in a VM with
a virtual disk or a shared disk, i.e. about 10%. Using a virtual NIC
caused NC to go from about 8:14 to 18:37 and KVM to go from 7:42 to
38:36. Regardless of the source of the IO performance problems, the
effect was dramatic which is why I'm assuming that it's disk IO that's
XP's problem. However I'm willing to concede that this is just a guess,
it could be any number of other factors as many posters have pointed out.
My original point was that if you are going to shell out for an expensive
simulator like NC, VCS or Questa, you shouldn't cripple it by running on
Windows.

 

[General Schvantzkopf]

On Fri, 20 Jun 2008 10:16:22 -0700, Stephen Williams wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

General Schvantzkopf wrote:
| I haven't been able to get Icarus to work, it's not complete enough to
| run any of our testbenches. We aren't doing anything fancy, in fact
all | of our code is strict Verilog 95 it's not even 2001.

Current snapshots are much improved, and bug reports are welcomed.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE -
http://enigmail.mozdev.org

iD8DBQFIW+XmrPt1Sc2b3ikRAtL9AKCykWIDYFWQkNqwfjcAJUgXewEa0wCgxqwt
6U/NtBgPoBg4Y7aF5Ki6NsY=
=YODt
-----END PGP SIGNATURE-----

I used the version that was in the F9 repositories which is 0.9, are the
current snapshots significantly better than that one?

 

[ghelbig]

On Jun 20, 11:21 am, General Schvantzkopf <schvantzk...@yahoo.com>
wrote:

Regardless of the source of the IO performance problems, the
effect was dramatic which is why I'm assuming that it's disk IO that's
XP's problem. However I'm willing to concede that this is just a guess,
it could be any number of other factors as many posters have pointed out.
My original point was that if you are going to shell out for an expensive
simulator like NC, VCS or Questa, you shouldn't cripple it by running on
Windows.

My tests indicate that the virtual memory manager in windows causes
large simulations to run at 10% of the speed of a Linux/Unix/Solaris
box.

Which validates your original point.

G.

 

[Petter Gustad]

General Schvantzkopf <schvantzkopf@yahoo.com> writes:

times as fast on Linux as it does on XP. I'm pretty sure that the time
difference can be attributed to the performance of the Linux file system
(EXT3) vs the XP file system (NTFS). The real purpose of my investigation

But simulations are not file system IO bound unless your dumping trace
files to the disk. You typically load the simulation image into memory
and run (unless you're dumping waveform data to the disk).

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[General Schvantzkopf]

On Sat, 21 Jun 2008 21:42:08 +0200, Petter Gustad wrote:

General Schvantzkopf <schvantzkopf@yahoo.com> writes:

times as fast on Linux as it does on XP. I'm pretty sure that the time
difference can be attributed to the performance of the Linux file
system (EXT3) vs the XP file system (NTFS). The real purpose of my
investigation

But simulations are not file system IO bound unless your dumping trace
files to the disk. You typically load the simulation image into memory
and run (unless you're dumping waveform data to the disk).

Petter

We have display statements in this testbench, it's not nearly as much IO
as when you dump a .trn file but it's enough so that slow disk IO has
between a 3X and 5X slowdown depending on how bad the IO is.

 

[Mike Treseler]

rickman wrote:

But my preference would be to use software which would *produce* a
drawing from the source code.

Quartus rtl viewer does that.

As long as we are talking about our "wish list", I would also like an
editor that was smart enough to complete words and sentences in my
HDL.

Emacs vhdl-mode completes words.

-- Mike Treseler

 

[rickman]

On Jun 20, 10:46 am, Patrick Dubois <prdub...@gmail.com> wrote:

On 19 juin, 22:45, rickman <gnu...@gmail.com> wrote:

I use a purely HDL hierarchy. I find that top level schematics or
even low level schematics of large functions tend to end up being more
like a net list than a drawing anyway. You have pins with names X,Y,Z
connected to net R,S,T on page 1. On page 2 you have nets R,S,T
connected to another part with pin names A,B,C. Making it a drawing
doesn't add much in my opinion. Once I gave up hope for schematics
and embraced the HDL world, I found joy in a life of text files and
the infinite advantages they have in the land of version control!

I agree that a top level schematic is exactly like a netlist, but the
difference to me anyway is that I can quickly grasp how each blocks
are connected together. I try to keep most blocks on one large 11x17
page. Here's an example of what I mean:http://www.yousendit.com/transfer.php?action=download&ufid=B152F0A35F...

With a netlist, I have to read the several lines of vhdl code to
understand how the blocks are connected and that takes a longer time.
Ideally, the vhdl netlist is also accompanied by a block diagram. With
the schematics flow, the block diagram comes free.

The drawbacks of course are the version control problems associated
with schematics files and the lack of a standard file format. To me
the version control issues are not a big deal because all the meat is
in the vhdl blocks anyway, not the top level.

I agree completely with the enhanced readability of a drawing at a
high level. The details are not improved at all, but it is easy to
see the large scale connections in a drawing. I guess I just don't
bother to use a schematic for that, I just make a block diagram to go
with the HDL.

It is a shame that there is no standard way of representing drawings.
This would help a lot with the other issues of version control, etc.
But my preference would be to use software which would *produce* a
drawing from the source code. Even if it required the user to draw
the connection lines, it would be helpful to have a program that would
create the symbols and keep them in sync with the HDL code for each
module. I would find this useful even at lower levels. After all, a
picture is worth a thousand words, right?

As long as we are talking about our "wish list", I would also like an
editor that was smart enough to complete words and sentences in my
HDL. There are any number of ways that a program can track what you
are doing and try to anticipate your actions as you type. For
example, if I am creating a clocked process and typing an assignment
for a signal or variable , it would be nice to have the software know
that it needs a definition and an initialization in the reset portion
of the process. So as soon as I enter the assignment, it would take
me to the appropriate spot for the definition and start it for me to
complete followed by the same for the initialization in the reset
section of the process.

If I am typing a "with" statement, I want the software to see the word
"with" and put the rest of the structure on the screen for me to fill
in the blanks. I find all the typing to be tedious and error prone,
not to mention that after all these years, I still don't have the
syntax memorized and keep a small stack of books by my elbow.

Just think how nice it would be to have the editor add the appropriate
conversion function when you type an assignment between incompatible
signals. No error message telling you that you need to convert that
integer to an unsigned, it just adds the conversion!

I hate to use a microsoft product as an example of the "right" way to
do anything, but the version of Word that I use does a pretty good job
of completing words for me sometimes. Even though it is not always
accurate, I have to admit that it does a pretty impressive job of
spell checking and syntax checking, and that is with *English*, not a
well defined language like VHDL or Verilog. I can only imagine that
it would be a much easier job to implement something similar for an
HDL. (spell checkers don't catch when you type and instead of an
though...)

Rick

 

[Kim Enkovaara]

Joseph H Allen wrote:

So in either of these, you typically simulate and have all signals dumped to
a huge output file (using $dumpvars(0); $dumpon; for vcs or $shm_open(...);
$shm_probe(..); for ncsim). Then you can explore the design hierarchy and
choose which signals to view in vcs -RPP or simvision. The same is true for
even icarus verilog with gtkwave.

In my mind this might work for small designs, but the huge amount of
signal logging slows down the simulation. I usually like to log just
part of the signals needed, which is the normal way Modelsim works.
I never understood the way vcs liked to work, it felt so unintegrated
(in the past, the new GUI is and quite good copy of modelsim gui )

However with modelsim it looks like there is no way to do this. Instead,
when you add a signal to the viewer in the GUI, it re-runs the entire
simulation to get the new signal. Am I missing something or is this really
how it works? I can't believe that it would really work this way.

In the beginning of simulation just add
"log -r /dut/interesting_module/*" and after that you can add signals
from that block also after the simulation to the viewer.

And you can also open the wave from the GUI after the simulation, or
open many different waves logged from different places and merge or
compare them in the GUI (open dataset functionality etc)

(Also the crippled free modelsim is slower than icarus).

And I have seen Modelsim SE to be much faster than VCS in some designs.
Each design is different beast in terms of simulation speed and what
simulator is the fastest. Unfortunately none of the free simulators
support mixed language simulations, and almost all of the designs
I see commercially are mixed language, so it's quite hard to
test the speed differences.


--Kim

 

[Petter Gustad]

Kim Enkovaara <kim.enkovaara@iki.fi> writes:

Joseph H Allen wrote:

So in either of these, you typically simulate and have all signals dumped to
a huge output file (using $dumpvars(0); $dumpon; for vcs or $shm_open(...);
$shm_probe(..); for ncsim). Then you can explore the design hierarchy and
choose which signals to view in vcs -RPP or simvision. The same is true for
even icarus verilog with gtkwave.

In my mind this might work for small designs, but the huge amount of
signal logging slows down the simulation. I usually like to log just

I've used this methods for many years for large ASIC designs. It slows
down the simulation, but I find this much more effective than running
the simulation again. Also it's more cost effective to release the
expensive simulation license and use the cheaper waveform viewer for
debugging. You can even run the simulations during the night and have
the VPD (TRN, SST or whatever you prefer) files waiting for you the
next morning.

part of the signals needed, which is the normal way Modelsim works.
I never understood the way vcs liked to work, it felt so unintegrated
(in the past, the new GUI is and quite good copy of modelsim gui )

I never understood the way Modelsim liked to work I prefer DVE
over Modelsim any day. I guess it's a matter of taste.


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Petter Gustad]

"SynopsysFPGAexpress" <fpgas@sss.com> writes:

I'm not sure how that compares to Mentor Questasim or Synopsys VCS.

VCS/DVE (VPD dump files) supports SV datatypes.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

General Schvantzkopf wrote:
| On Fri, 20 Jun 2008 10:16:22 -0700, Stephen Williams wrote:
|
| General Schvantzkopf wrote:
| | I haven't been able to get Icarus to work, it's not complete enough to
| | run any of our testbenches. We aren't doing anything fancy, in fact
| all | of our code is strict Verilog 95 it's not even 2001.
|
| Current snapshots are much improved, and bug reports are welcomed.
|

| I used the version that was in the F9 repositories which is 0.9, are the
| current snapshots significantly better than that one?

There is no 0.9 release, but 0.9.0.xxxx is the numbering scheme
for the snapshots that are leading up to 0.9. Even at that, it
depends on the actual version, as recently Icarus Verilog has been
improving rapidly.

Bug reports will help us pin down what your actual problems are
and get them fixed up. There shouldn't be much left of the 1995
LRM that isn't supported by now.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIYVm4rPt1Sc2b3ikRAlLcAKDcFVE0+WNh4v5a7r+aKkEatIEQ2ACeJ99c
BK91SsjnmrS0bChcMJpXfhc=
=pdGZ
-----END PGP SIGNATURE-----