Re: Modelsim PE vs. Aldec Active-HDL (PE)

[d_s_klein]

I've finally decided to buy a better simulator
(I've been making do with Modelsim XE so far).

Any thoughts as to the relative merits of Modelsim PE and
Active-HDL (PE) for FPGA simulation?

Thanks

Pete

One complaint I have about Active-HDL is that it insists on making a
copy of the sources and hiding them in a not so easy to find
location. It will then simulate these, and only these copies. If you
change a file while simulating, you have to remember to copy it out.
If you change something between simulations, you have to re-import it.

This "feature" makes the simulator mostly useful only *after* all the
bugs are fixed. (argh)


The ModelSim windows GUI is definitely getting worse with time. The
Linux GUI seems to be getting better though.

RK

 

[rickman]

One complaint I have about Active-HDL is that it insists on making a
copy of the sources and hiding them in a not so easy to find
location.  It will then simulate these, and only these copies.  If you
change a file while simulating, you have to remember to copy it out.
If you change something between simulations, you have to re-import it.

This "feature" makes the simulator mostly useful only *after* all the
bugs are fixed.  (argh)

The ModelSim windows GUI is definitely getting worse with time.  The
Linux GUI seems to be getting better though.

RK

The copying of source files to a folder within the simulation
directory is the default, but you can override it. The "Add Files"
dialog box has a "Make Local Copy" checkbox which once you uncheck it,
seems to stay unchecked.

My most recent issue with ActiveHDL is how to copy a project. But I
finally figured out that "Save Design As" in the File menu does what I
want. Just "Save As" only seems to save the waveform file. I kept
looking under things titled "Workspace" which was not the ticket.

Rick

 

[HT-Lab]

I've finally decided to buy a better simulator
(I've been making do with Modelsim XE so far).

One complaint I have about Active-HDL is that it insists on making a
copy of the sources and hiding them in a not so easy to find
location. It will then simulate these, and only these copies. If you
change a file while simulating, you have to remember to copy it out.
If you change something between simulations, you have to re-import it.

This "feature" makes the simulator mostly useful only *after* all the
bugs are fixed. (argh)


The ModelSim windows GUI is definitely getting worse with time.

Yes, I found the same, however, when you install a new version of Modelsim the
registry keys are not overwritten so to preserve your GUI settings. I found that
deleting (or renaming) this entry fixes a lot of GUI instabilities. When you
restart Modelsim it automatically rebuilds them.

See: HKEY_CURRENT_USER\Software\Model Technology Incorporated\ModelSim

Hans
www.ht-lab.com

 

[Andy Peters]

One complaint I have about Active-HDL is that it insists on making a
copy of the sources and hiding them in a not so easy to find
location.  It will then simulate these, and only these copies.  If you
change a file while simulating, you have to remember to copy it out.
If you change something between simulations, you have to re-import it.

This "feature" makes the simulator mostly useful only *after* all the
bugs are fixed.  (argh)

As Rick says, when you choose "Add New File," there is a check-box for
"Make Local Copy," which if de-selected seems to get grayed out so you
can never select it again. However when this is deselect the project
does not copy the file and instead references it from wherever it
lives.

I find Aldec's forced directory structure to be rather stupid, and
it's really difficult to put it reasonably into a source-code control
system. It wants to put all of the scripts and configuration files
into its src directory, which of course breaks the cardinal rule
"don't put synthesizable sources and configuration files in the same
directory!" and it's got too many configuration files. ModelSim has
one project file (the .mpf) which is plain text and easily edited by
hand.

I think it's whole notion of workspaces is pretty useless, too. It has
a potential to be useful, in that you can put multiple designs in it.
Consider, for instance, a design which has a top-level source and
three lower-level sources. Of course you want some kind of test bench
for each lower-level source, and it would seem that creating a
"Design" for each in the workspace would work. But it doesn't. One
reason is that each design has a library associated with it (and the
default name is NOT work, but rather the design name). You cannot have
a library that is shared among all of the designs in a workspace.
Also, you can't call the work library for each design "work" -- they
have to have different names. This all matters if you are lazy like me
and you use direct instantiation of lower-level entities:

u_lower : entity work.lower port map (foo => foo, bar => bar);

I suppose the "right" thing to do in that case is to create a library
for each entity, analyze each into this library and instantiate from
it. This all assumes that your synthesis tool can support this.

Finally, I really like ModelSim's concept of "simulation
configurations." They're very easy -- you create a configuration, tell
it the top-level entity, set all of the generics and various other
things, and it's done. Click on the simulation configuration and off
you go. Sure, these things are nothing more than wrappers around the
vsim command but they're very handy. Active-HDL doesn't have this
feature, so the workaround is to create tcl scripts which call asim
with the proper command line.

So, yeah, Active-HDL is fine but if you are used to ModelSim's
features it can be confusing. I've spoken to Aldec's support folks
about the really fscking stupid forced directory structure, the
overabundance of configuration files and the lack of simulation
configurations. I don't know whether they will, or even can, change
some of this stuff without breaking existing projects, but as a paying
customer I guess I'm allowed to make suggestions.

-a

 

[Martin Thompson]

ModelSim has one project file (the .mpf) which is plain text and
easily edited by hand.

Various others have also mentioned project files and workspaces and
the like...

Am I the only one that makes *no* use of the various "project things"
(either in Modelsim or Aldec)? I just have a makefile and use the GUI
to run the sim (from "their" command-line) and show me the waveforms.
I guess I don't like to be tied to a tool (as much as I can manage)
much as I don't like to be tied to a particular silicon vendor (as
much as I can manage

Am I missing something valuable, or is it just different?

Cheers,
Martin

 

[Dave]

Am I the only one that makes *no* use of the various "project things"

(either in Modelsim or Aldec)?  I just have a makefile and use the GUI
to run the sim (from "their" command-line) and show me the waveforms.

I do the same so that makes at least two of us! Scripts are best for
source control, staying sane and having weekends free...

 

[Petter Gustad]

Am I the only one that makes *no* use of the various "project things"
(either in Modelsim or Aldec)? I just have a makefile and use the GUI

I almost always use my own set of command line tools to run the
simulation and eventually I use the waveform viewer for debugging.
I've been very happy with VCS in this regard.

I never use the bundled project or revision control stuff (I use
mostly git and/or svn).

Petter

 

[rickman]

Various others have also mentioned project files and workspaces and
the like...

Am I the only one that makes *no* use of the various "project things"
(either in Modelsim or Aldec)?  I just have a makefile and use the GUI
to run the sim (from "their" command-line) and show me the waveforms.
I guess I don't like to be tied to a tool (as much as I can manage)
much as I don't like to be tied to a particular silicon vendor (as
much as I can manage

Am I missing something valuable, or is it just different?

I doubt you are missing much of any real use. I find the GUI will
save me a lot of typing when instantiating modules. I use the
"generate test bench" feature to build a file with the meat and
potatoes in it and I copy that to the higher level module.

Otherwise if I was practiced in using make files with FPGA tools, I
would be likely be doing that too.

Rick

 

[Andy Peters]

I doubt you are missing much of any real use.  I find the GUI will
save me a lot of typing when instantiating modules.  I use the
"generate test bench" feature to build a file with the meat and
potatoes in it and I copy that to the higher level module.

Otherwise if I was practiced in using make files with FPGA tools, I
would be likely be doing that too.

I don't use any of the Aldec tools that automatically generate test
benches or creating instances and all of that. Yes, I'm an emacs vhdl-
mode user and emacs does a fantabulous job of all of that.

Right now I'm working through the "best" way to set up projects within
the GUI, with an eye towards taking this and generating a Makefile or
a script or something.

It turns out that it is reasonable to create one workspace for an FPGA
project and within this workspace create a "design" for the
subentities and the top level. If you let it use the design name as
the working library for the design, then as long as you "use" the
library in a higher-level source, that source can see those other
libraries.

Now I'm thinking that the usual method of doing:

u_foo : entity work.foo port map (bar => bar, bletch => bletch);

might be better as:

u_foo : entity foo.foo port map (bar => bar, bletch => bletch);

The other option is to create a package with a component definition
for foo, and analyze that package into the foo library, so the
instantiation can be:

u_foo : foo port map (bar => bar, bletch => bletch);

I really don't know which is "better."

-a

 

[KJ]

Am I the only one that makes *no* use of the various "project things"
(either in Modelsim or Aldec)?  I just have a makefile and use the GUI
to run the sim (from "their" command-line) and show me the waveforms.
I guess I don't like to be tied to a tool (as much as I can manage)
much as I don't like to be tied to a particular silicon vendor (as
much as I can manage

But you're also running *their* commands to compile, run and view so
you're not really any more independent. Maintaining make files can be
a chore also, unless you use something to help you manage it...but
then you're now dependent on that tool as well.

Am I missing something valuable, or is it just different?

Probably depends on which scenario is more likely to occur
1. Change sim tools
2. Add new developers (temporary, or because you move on to something
else in the company)

If #1 is prevalent, then maybe using other tools to help you manage
'make' is better. If #2 is more prevalent, then using the tool's
project system is probably better in easing the transition. If
neither is particularly likely...well...then it probably doesn't much
matter since one can probably be just as productive with various
approaches.

Kevin Jennings

 

[KJ]

It turns out that it is reasonable to create one workspace for an FPGA
project and within this workspace create a "design" for the
subentities and the top level. If you let it use the design name as
the working library for the design, then as long as you "use" the
library in a higher-level source, that source can see those other
libraries.

Why do you think that you need to segregate the library that the
source files get compiled into? In other words, what is wrong with
compiling everything into 'work'? That's not a source file, it's an
intermediate folder(s) that gets created along the way to doing what
you need to have done. What do you gain by trying to have tidy
intermediate folders?

Having a separate library helps you avoid name clashes, but for things
that you're developing yourself this is more easily avoided by
considering some of the following points:
- Question the validity of why you have two things named the same
(presumably doing the same thing)
- Consider parameterizing the design instead so that there is only one
thing with that name, but now you have a parameter that can select
what needs to be different.
- If the differences between the designs are significant such that
parameterizing simply encapsulates each approach within big 'if xyz
generate...end generate', if abc generate...end generate' statements
then consider collecting each design as simply differently named
architectures of the same entity (i.e. 'architecture RTL1 of widget',
'architecture RTL2 of widget')
- Avoid the name clash by renaming one of them to be more descriptive
to distinguish it from it's sibling

Now I'm thinking that the usual method of doing:

    u_foo : entity work.foo port map (bar => bar, bletch => bletch);

might be better as:

    u_foo : entity foo.foo port map (bar => bar, bletch => bletch);

The other option is to create a package with a component definition
for foo, and analyze that package into the foo library, so the
instantiation can be:

    u_foo : foo port map (bar => bar, bletch => bletch);

I really don't know which is "better."

Neither one is particularly good in my opinion. The reasons against
the first approach I've mentioned above (i.e. what do you really get
for not simply compiling everything into 'work'?). The only place
I've found a component declaration to be useful is when you would like
to use a configuration to swap things out and about. The only time
I've found configurations to be useful really is when the VHDL source
is not really under my control (such as when a PCBA model is generated
by a CAD tool).

With a component declaration, you still have to decide where to put
that declaration. The best place is in the source file with the
entity so that changes to one are more likely to get changed in both
places. Given that, I don't see how components will help you manage
anything better....my two or three cents

Kevin Jennings

 

[KJ]

What do you gain by trying to have tidy intermediate folders?

as you said, tidiness...

tidy intermediate folders...i.e. folders that are not important to me
as the user of the tool, but are needed by the tool to do it's job.
In other words, I don't care if the tool's private folders are tidy or
not.

I use separate libraries for major categories within the design; e.g. memory
interface, core logic, common (reusable) blocks, testbench - not separate
libraries for foo, bar and bletch.

My point was why even bother to separate them unless there are name
clashes...or perhaps you're creating your own separate IP for resale
and want to avoid clashes with some other potential IP.

I can't say it buys me a whole lot

I agree

but it does help me keep the design hierarchy
straighter - e.g. if the synthesis project contains something from the Testbench
library, the design has gone seriously astray somewhere!

If it's actually a problem, the synthesis tool will complain quickly
(like less than 1 minute into the run)...but the synthesis tool won't
be looking at any libraries (testbench or other) it will create the
libraries itself based on the source files you tell it are in there to
be synthesized. Whether you compile such a testbench file into 'work'
or 'testbench' won't matter. If the source file is included it will
be analyzed. If it happens to be synthesizable code (even if it is
only intended for sim testbench) synthesis will be OK with it. It
won't generate any logic from this extraneous code since it won't be
called from within the hierarchy of the design to be synthesized.

I confess though, I'm not quite sure what your point is here for
compiling stuff into separate libraries. It *sounds* like you're
talking about organizing source files into separate 'libraries'...in
which case what you said would make more sense but that's not at all
the same thing as compiling something into a library other than
'work'.

Kevin Jennings

 

[Martin Thompson]

I find the GUI will save me a lot of typing when instantiating
modules. I use the "generate test bench" feature to build a file
with the meat and potatoes in it and I copy that to the higher level
module.

Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
it

 

[Martin Thompson]

But you're also running *their* commands to compile, run and view so
you're not really any more independent.

This is true, but the "porting" can be done once and pushed into
scripts. Porting my "muscle-memory" is a lot harder, if the buttons
to click move around

Waveform viewing is still an issue, as that will likely change the
most, but I spend a lot less time doing that than most other tasks.
Certainly, the differences between two tools didn't pain me much when
I was trying two in parallel.

Maintaining make files can be a chore also, unless you use something
to help you manage it...but then you're now dependent on that tool
as well.

Emacs. I don't mind being dependent on that so much.

Probably depends on which scenario is more likely to occur
1. Change sim tools

Or using a variety all the time... I'd like to do more experimentation
and comparison, esp. of the open source tools.

2. Add new developers (temporary, or because you move on to something
else in the company)

If #1 is prevalent, then maybe using other tools to help you manage
'make' is better. If #2 is more prevalent, then using the tool's
project system is probably better in easing the transition.

I guess that's a point in its favour (assuming I can't "convert" the
incomers to Emacs

If neither is particularly likely...well...then it probably doesn't
much matter since one can probably be just as productive with
various approaches.

Which is probably why we have lots of approaches - dofferent strokes
and all that!

Cheers,
Martin

 

[Andy Peters]

Why do you think that you need to segregate the library that the
source files get compiled into?  In other words, what is wrong with
compiling everything into 'work'?  That's not a source file, it's an
intermediate folder(s) that gets created along the way to doing what
you need to have done.  What do you gain by trying to have tidy
intermediate folders?

As I said, I have always just dumped everything into 'work' without
thinking too much about it, mainly because it always just worked. I
thought about using separate libraries as a sop to how Active-HDL
organizes its workspaces.

Having a separate library helps you avoid name clashes, but for things
that you're developing yourself this is more easily avoided by
considering some of the following points:
- Question the validity of why you have two things named the same
(presumably doing the same thing)

No issues with namespaces here. I've adopted a simple prefix
nomenclature for things that hopefully mitigates any potential
clashes.

Neither one is particularly good in my opinion.  The reasons against
the first approach I've mentioned above (i.e. what do you really get
for not simply compiling everything into 'work'?).  The only place
I've found a component declaration to be useful is when you would like
to use a configuration to swap things out and about.  The only time
I've found configurations to be useful really is when the VHDL source
is not really under my control (such as when a PCBA model is generated
by a CAD tool).

I agree: I never use component declarations except to work around
other tool issues (like with the Xilinx EDK and how it apparently
analyzes things into particular non-work libraries).

With a component declaration, you still have to decide where to put
that declaration.  The best place is in the source file with the
entity so that changes to one are more likely to get changed in both
places.  Given that, I don't see how components will help you manage
anything better....my two or three cents

Those component declarations I've described are in a package that's in
the same source file as the entity.

I think I need to simply stop using the Active-HDL GUI and do the
command-line thing.

-a

 

[rickman]

Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed
it

Are you saying that Emacs understands VHDL well enough to build a test
bench for you? Will it also build a component declaration or
instantiation automatically? These three things could be automated,
but I have never taken the time to do it. Making it part of the
editor makes perfect sense.

Rick

 

[rickman]

I guess that's a point in its favour (assuming I can't "convert" the
incomers to Emacs

You can convert me. I just need to know that it is an advantage to
switch.

Rick

 

[Andy Peters]

Are you saying that Emacs understands VHDL well enough to build a test
bench for you?

It will create a skeleton for you.

 Will it also build a component declaration or
instantiation automatically?  These three things could be automated,
but I have never taken the time to do it.  Making it part of the
editor makes perfect sense.

The skeleton has a nice header, an instance of the DUT, signal
declarations for all DUT I/O and a simple clock generator. Of course
you have to create your own stimulus and add instantiations of other
models as necessary.

-a

 

[rickman]

It will create a skeleton for you.


The skeleton has a nice header, an instance of the DUT, signal
declarations for all DUT I/O and a simple clock generator. Of course
you have to create your own stimulus and add instantiations of other
models as necessary.

Ok, that's what I get from the Aldec or Lattice ispLever tools. I'll
have to look at EMACs sometime soon. Can it be used to do pretty
print formatting on VHDL files?

Rick

 

[Petter Gustad]

Ok, that's what I get from the Aldec or Lattice ispLever tools. I'll
have to look at EMACs sometime soon. Can it be used to do pretty
print formatting on VHDL files?

Yes, it will "beautify", either the entire buffer or the current
region (using C-c C-b or C-c M-b).

I'm also using Emacs/Gnus writing this message and reading this
newsgroup. I'm using Emacs/Mew for writing E-mail, also writing
Verilog, Common Lisp, Python, C, Java, LaTex, etc., as well as doing
GIT commits, diffs, creating branches, merges, even surfing the web
using w3m. Dired in Emacs provides a great file browser where I can to
bulk editing etc. Whenever I want to perform tedious repetitive
editing tasks I will usually make a small Emacs Lisp function to do it
for me...

Petter