which commercial HDL-Simulator for FPGA?

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.

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

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

Software C/C++ (and other programming languages, too) have been
doing this for YEARS.  Microsoft calls its solution "intelliSense".
It's in Developer Studio (VC++/VC##, VB.net/etc.).

The first time you (sucessfully) compile the project's source-code,
the class/variable browser registers every user-defined identifier
(typedef, class, function, struct, union, built-in type int/float/char) with
the editor.

Then, as you type source-code, the browser pops up a 'helper'
box.  For function-calls (including the C/C++/Windows standard
library), it shows the argument-names and their data-type.  I guess
you could call it dynamic annotation.  You can jump to the definition
of the object under the cursor, at any time.  (For standard library calls,
this is less useful -- most of the compiler header-files are unreadable
jibberish.)

> 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.

Yeah, intelliSense does this for many contexts.
Though it sounds like you additionally want some form of AutoCompletion,
combined with context-sensitive editing. 

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

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" <newsmailcomp6@gustad.com> wrote in message 
news:87bq1snxfw.fsf@pangea.home.gustad.com...
> 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.

For e/Specman and Systemverilog-TB debugging, the Cadence/NCsim
doesn't log dynamic-objects to the TRN/SST file.  So you pretty much
have to do most debugging interactively (if you want to see Systemverilog
objects/queues/dynamic-arrays, etc.), with the full license checkout of
the simulator.

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

"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?

-----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-----