which commercial HDL-Simulator for FPGA?

"Mike Treseler" <mtreseler@gmail.com> wrote in message 
news:4859F704.2040001@gmail.com...
> SynopsysFPGAexpress wrote:
>> As commodity PC hardware and prouctivity applications deline in price, 
>> EDA tools are as (relatively) expensive as ever, necessitating yet 
>> another discussion of "Which simulator is right for me?"
>
> This reads like a thinly veiled marketing survey.

It is, I apologize if I mislead anyone. I wanted to hear other people's 
choices and
compare them to my situation.

>> Kidding aside, my real requirements:
> Which part were you kidding about?

For gHDL and Icarus Verilog, I said "emacs/gvim not included."  It was a 
poor attempt at humor.

>> 1) I foresee mixed-HDL as a *requirement* for any serious consulting job. 
>> (Xilinx and Altera are pretty good about providing  'HDL-neutral IP', but 
>> third-parties aren't.)
>
> The device vendors are only HDL-neutral because
> they are selling device netlists, not source code.
> Not a plus in my book.

That's something I didn't think about, and I checked Xilinx's website.
It turns out, some of their IP-blocks (Microblaze, PCIe, PPC440, etc.) use
a new 'SecureIP' format, and so far, only Modelsim is supported.  That
doesn't bode well, either...

 http://www.xilinx.com/support/answers/30481.htm 

On Jun 19, 2:35 pm, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:
> SynopsysFPGAexpress wrote:
> > As commodity PC hardware and prouctivity applications deline in price, EDA
> > tools are as (relatively) expensive as ever, necessitating yet another
> > discussion of "Which simulator is right for me?"
>
> > The contendors are ...
> ...
>
> If you have Xilinx ISE 10.1, check out ISIM, which comes "free" with it.
>   It's much improved and may meet your needs and in future releases
> should have better a better user interface.  I don't think it currently
> supports SystemVerilog, (and you are correct in propagating your
> religion) but might soon.  Modelsim is still the best, but you pay for a
> lot of things you don't really need, and the waveform viewer could be
> improved.  That's where you spend 90% of your time during debugging so
> it should be a little easier to use.
> -Kevin

Apologies if you are a Xilinx person, but I tried their Web Pack
edition with the in house tools and the simulator really sucks... or
blows or something not so good.  Although I didn't see any issues with
the simulation speed, the compile speed is pretty slow.  I was using
it for a while when my design was pretty small and the compiles were
taking half a minute.  Using Aldec Active HDL the compiles take a
second for a much larger design and the simulation speed is not bad
considering that it is "crippled"ware.

Xilinx seems committed to improving their in house sim.  I posted
about in a news group and got a reply from one of the developers which
was almost apologetic and sincerely interested in what I found
lacking.

In the meantime I expect to stick with commercial packages.  When I do
make the switch, it will likely be to an open source simulator.

Rick

On Jun 19, 6:10 pm, Patrick Dubois <prdub...@gmail.com> wrote:
> On 18 juin, 21:01, "SynopsysFPGAexpress" <fp...@sss.com> wrote:
>
>
>
> > As commodity PC hardware and prouctivity applications deline in price, EDA
> > tools are as (relatively) expensive as ever, necessitating yet another
> > discussion of "Which simulator is right for me?"
>
> > The contendors are ...
>
> > 1) Aldec Active-HDL
> >    + great design-flow assistants (state-diagram, block-diagram,
> >       waveform-diagram editing, export to PDF)
> >    + possibly faster than Modelsim/PE?
> >    - no direct support in FPGA design-suites (Webpack/Quartus)
> >    - Windoze only (can WINE 1.0 run it?)
> >    - Systemverilog is almost but not quite usable ('package' not
> > supported?!?)
> >    "less than $6000 for mixed-lang. VHDL+Verilog simulation"
> >      (Note, that configuration is the most basic, doesn't have
> > SWIFT/Smartmodel)
> >     [first year pepetual-license, yearly maint. is additional 20%/year]
>
> One vote for Active-HDL. I briefly used Modelsim before we bought
> Active-HDL and for me anyway, the Active-HDL interface is much better.
> It's true that it's not officially supported by Xilinx but in practice
> that really never caused too much of a problem.
>
> I really like to create a schematic top level with blocks that are
> either more schematics themselves or directly vhdl blocks. That way
> it's much easier to see how everything connects together, it helps
> comprehension. I don't quite understand why some people insist on
> writing direct VHDL connections between blocks. It's a little bit like
> insisting on writing pspice netlists for simulations instead of using
> the schematic editor. Active-HDL converts schematics to vhdl code
> anyway, so it's never too late to go back to vhdl-only code. The
> resulting code will be very clean if you keep your top level free of
> logic.

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!


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

I agree.  Again a diagram can only offer a bit more here than can the
HDL text file, but I don't like using special tools that make the code
more difficult to port.  Keeping it in HDL can work well and has all
of those text and portability advantages.

Rick

On Wed, 18 Jun 2008 18:01:59 -0700, SynopsysFPGAexpress wrote:

> As commodity PC hardware and prouctivity applications deline in price,
> EDA tools are as (relatively) expensive as ever, necessitating yet
> another discussion of "Which simulator is right for me?"

I've done some benchmarking on Verilog simulators. Here are the times for 
running our regression suite on one of our cores. I ran the test suite on 
Cadence NCSim on CentOS5, Mentor's Questa on both CentOS5 and XP, and 
Altera's Modelsim on CentOS5. The system is a 3GHz Core2 with 8G of DDR. 
NC is the fastest but Questa on CentOS5 is close. Questa on XP is much 
slower then it is on Linux. 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

"General Schvantzkopf" <schvantzkopf@yahoo.com> wrote in message 
news:iIqdncpPC63KCsbVnZ2dnUVZ_jKdnZ2d@comcast.com...
> On Wed, 18 Jun 2008 18:01:59 -0700, SynopsysFPGAexpress wrote:
>
>> As commodity PC hardware and prouctivity applications deline in price,
>> EDA tools are as (relatively) expensive as ever, necessitating yet
>> another discussion of "Which simulator is right for me?"
>
> I've done some benchmarking on Verilog simulators.

Lies, damn lies and benchmarks :-)

> Here are the times for
> running our regression suite on one of our cores.
> I ran the test suite on
> Cadence NCSim on CentOS5, Mentor's Questa on both CentOS5 and XP, and
> Altera's Modelsim on CentOS5.

Benchmarking is very difficult and not only requires multiple designs and 
knowing the environment inside out you also need to know what the simulator 
is doing to your code. Verilog has the advantage(?) that you can tweak the 
simulator to improve performance however, this might break some simulations. 
(Un)fortunately this is not possible with VHDL which is far more stricter in 
what you can do with the compiler.  Using one core without mentioning how 
you measured it, simulator/compiler settings, versions etc is not much use 
IMHO.

> The system is a 3GHz Core2 with 8G of DDR.
> NC is the fastest but Questa on CentOS5 is close. Questa on XP is much
> slower then it is on Linux.

I found the same.

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

This is fully documented. I believe the OEM versions are about 40% of PE, 
however, the problem is that after a certain number of lines it grinds to a 
halt and becomes completely useless.

Hans
www.ht-lab.com


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

On Jun 19, 5:42=A0pm, jhal...@TheWorld.com (Joseph H Allen) wrote:
> In article <20080619124737.4526b...@wolfenstein.jpl.nasa.gov>,
> Jason Zheng =A0<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
>
> =A0 =A0- this creates a vsim.wlf file with everything in it just
> =A0 =A0 =A0as you say.
>
> Now try to view the waveform. =A0If I try:
>
> vsim -wlf vsim.wlf work.tb -do "view wave; add wave *"
>
> This brings up modelsim GUI and opens the waveform viewer window. =A0All =
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, vsi=
m
> -wlf does something to the .wlf file or sets something in an initializati=
on
> file somewhere. =A0I 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?

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

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

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.

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

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}