which commercial HDL-Simulator for FPGA?
SynopsysFPGAexpress
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]
2) Mentor Modelsim PE
+ currently more solid Systemverilog support than Active-HDL,
(but limited to design-constructs, no assertions/coverage)
+ de-facto industry standard,
direct integration into FPGA design-suites (Webpack/Quartus)
+ SWIFT/Smartmodel support (no extra cost if using mixed-HDL license)
- I really don't like the integrated waveform viewer
- Windoze only (can WINE 1.0 run it?)
"less than $10,000 for mixed-lang. VHDL+Verilog simulation"
[first year perpetual-license, yearly maint. is additional 20%/year]
3) FPGA-vendor OEM solution (usually a crippled Modelsim/PE)
+ cheapest
+ Altera Modelsim officially supports Linux (Xilinx does not)
+ Xilinx Modelsim has same level of (design construct) Systemverilog
support as Modelsim/PE, quite good actually
- limited capacity, deliberately slower runtime performance
- term-based only (no perpetual license for Xilinx/Altera?)
- no mixed-HDL (VHDL+Verilog) -- deal-killer for me...
"less than $1500 for 1-language, 1-year license"
If I only had to do 'abstract' RTL-design (algorithm proof, no
device-dependent instantiations...)
*4) gHDL, Icarus Verilog
+ free, open-source VHDL, Verilog
- emacs/gvim not included
- no mixed-HDL (VHDL+Verilog) sim
.............
Kidding aside, my real requirements:
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.)
2) ASIC sign-off is obviously not a concern -- who's going to compete with a
professional turn-key bureau?
3) Design-size (capacity) is an unknown. For front-end (RTL) simulation, I
think even the OEM Modelsims are adequate. But for gate-level, that might
push them over the limit. It's interesting that even a 'budget' <$500
FPGA-board already has sufficient gate-capacity to overwhelm a
single-designer...progress!
3) validation/qualification with fpga vendor. I like Active-HDL's
user-interface more than Modelsim, but I can't escape the fact that
Modelsim/PE has wider industry endorsement. It's hard to argue with the
management types who're more interested in checkboxes than the less
tangibles (oh ... like ... employee productivity?)
Finally, I note the irony of Modelsim/Altera and Modelsim/Xilinx editions.
Altera Quartus-II supports Systemverilog synthesis, quite well, actually.
But Altera's Modelsim is based on the aging 6.1g version, which is
regrettably limited. Xilinx Webpack doesn't support Systemverilog, but
their Modelsim/XE is based on the more recent 6.3c codebase. I find it
useful for testbenching, though too many colleagues heckle me for my
systemverilog "religion." (I believe in it, and so should they.)
Mike Treseler
> 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.
If you actually are a designer,
get a proto design ready,
order evals of each simulator
then try them and see for yourself.
> Kidding aside, my real requirements:
Which part were you kidding about?
> 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.
-- Mike Treseler
Muzaffer Kal
<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 ...
Don't forget http://fintronic.com/home.html and
http://simucad.com/products/verilogSimulation/silos-x.html
I personally like Finsim (from Fintronic) a lot. It's a compiled
simulator and it's quite fast.
Brian Drummond
Both appear to fail the OP's requirements (and mine);
they look to be Verilog only.
- Brian
jprov...@yahoo.com
> On Wed, 18 Jun 2008 18:01:59 -0700, "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 ...
>
>
> I personally like Finsim (from Fintronic) a lot. It's a compiled
> simulator and it's quite fast.
I've been using Veritak, a low cost Veritak simulator. It has had
some bugs, but the author
is VERY quick to fix problems. A surprise - he is also VERY
responsive to requests for
new features or enhancements. I'm very pleased with his product.
John Providenza
Kevin Neilson
> 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
Joseph H Allen
Kevin Neilson <kevin_...@removethiscomcast.net> wrote:
>... Modelsim is still the best, but you pay for a
>improved. That's where you spend 90% of your time during debugging so
>it should be a little easier to use.
I've used vcs and currently have access to ncsim, so I've not bothered with
modelsim. However, recently I tried the free one which comes with Altera
web edition.
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.
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.
(Also the crippled free modelsim is slower than icarus).
Has anyone tried to simulate Altera's IP with icarus? I'm thinking about
the .vo simulation model of the altmemphy DDR controller.
--
/* jha...@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]]);}
Jason Zheng
jha...@TheWorld.com (Joseph H Allen) wrote:
> 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.
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.
Older versions of Modelsim also seems to stall after long simulations,
wehreas ncsim never gave me any problems.
--
Faster, faster, you fool, you fool!
-- Bill Cosby
Joseph H Allen
Jason Zheng <Xin....@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.
BTW, I notice that if I do add
initial
begin
$dumpvars(0);
$dumpon;
...
end
vsim will generate a dump.vcd file, and I can use gtkwave to view it just
fine. I had thought this didn't work, I guess I was wrong or something
changed recently. Maybe I should just forget about using modelsim's
built-in viewer.
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.
This is modelsim 6.1g which comes with Quartus 8.0 web edition running under
windows.
Patrick Dubois
> 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.
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.
Patrick
SynopsysFPGAexpress
news:4859F704...@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
rickman
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
rickman
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
General Schvantzkopf
> 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
HT-Lab
"General Schvantzkopf" <schvan...@yahoo.com> wrote in message
news:iIqdncpPC63KCsbV...@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
kkoorndyk
> In article <20080619124737.4526b...@wolfenstein.jpl.nasa.gov>,
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?
Patrick Dubois
> 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
Mike Treseler
> 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
General Schvantzkopf
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.
Joseph H Allen
It would be interesting to see Icarus in this list. Also Verilator...
Joseph H Allen
I wonder if it's core XP or if it's the filesystem itself. There's a
Windows-XP port of EXT2 available. It would be amusing if it was faster than
NTFS.
So was your virus scanner on during the simulation :-)
The answer is to just use Linux.
General Schvantzkopf
> In article <485BC40E...@gmail.com>, Mike Treseler
> <mtre...@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.
Stephen Williams
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
> 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
Jason Zheng
General Schvantzkopf <schvan...@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.
Mike Treseler
>> 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:52:13 -0500
> General Schvantzkopf <schvan...@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
I used the version that was in the F9 repositories which is 0.9, are the
current snapshots significantly better than that one?
ghelbig
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
> 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
> General Schvantzkopf <schvan...@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.
rickman
> 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
>
> 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
Mike Treseler
> 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
SynopsysFPGAexpress
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.
Kim Enkovaara
> 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
> 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.
SynopsysFPGAexpress
news:87bq1sn...@pangea.home.gustad.com...
> Kim Enkovaara <kim.en...@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.
Petter Gustad
> I'm not sure how that compares to Mentor Questasim or Synopsys VCS.
VCS/DVE (VPD dump files) supports SV datatypes.
Stephen Williams
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-----