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

Discussion in 'VHDL' started by d_s_klein, Mar 3, 2010.

  1. d_s_klein

    d_s_klein Guest

    On Mar 3, 5:02 am, "Pete Fraser" <> wrote:
    > 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
    d_s_klein, Mar 3, 2010
    #1
    1. Advertising

  2. d_s_klein

    rickman Guest

    On Mar 3, 5:42 pm, d_s_klein <> wrote:
    > On Mar 3, 5:02 am, "Pete Fraser" <> wrote:
    >
    > > 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


    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
    rickman, Mar 4, 2010
    #2
    1. Advertising

  3. d_s_klein

    HT-Lab Guest

    "d_s_klein" <> wrote in message
    news:...
    On Mar 3, 5:02 am, "Pete Fraser" <> wrote:
    > 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
    HT-Lab, Mar 4, 2010
    #3
  4. d_s_klein

    Andy Peters Guest

    On Mar 3, 3:42 pm, d_s_klein <> wrote:
    > On Mar 3, 5:02 am, "Pete Fraser" <> wrote:
    >
    > > 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)


    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
    Andy Peters, Mar 4, 2010
    #4
  5. Andy Peters <> writes:

    > 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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
    Martin Thompson, Mar 5, 2010
    #5
  6. d_s_klein

    Dave Guest

    > 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...
    Dave, Mar 5, 2010
    #6
  7. Martin Thompson <> writes:

    > 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
    --
    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, Mar 5, 2010
    #7
  8. d_s_klein

    rickman Guest

    On Mar 5, 5:34 am, Martin Thompson <> wrote:
    > Andy Peters <> writes:
    > > 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?


    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
    rickman, Mar 5, 2010
    #8
  9. d_s_klein

    Andy Peters Guest

    On Mar 5, 10:15 am, rickman <> wrote:
    > On Mar 5, 5:34 am, Martin Thompson <> wrote:
    >
    > > Andy Peters <> writes:
    > > > 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?

    >
    > 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
    Andy Peters, Mar 5, 2010
    #9
  10. d_s_klein

    KJ Guest

    On Mar 5, 5:34 am, Martin Thompson <> wrote:
    >
    > 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, Mar 6, 2010
    #10
  11. d_s_klein

    KJ Guest

    On Mar 5, 4:53 pm, Andy Peters <> wrote:
    >
    > 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, Mar 6, 2010
    #11
  12. d_s_klein

    KJ Guest

    > > 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
    KJ, Mar 7, 2010
    #12
  13. rickman <> writes:

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


    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
    Martin Thompson, Mar 8, 2010
    #13
  14. KJ <> writes:

    > On Mar 5, 5:34 am, Martin Thompson <> wrote:
    >>
    >> 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.


    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.

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

    > 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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
    Martin Thompson, Mar 8, 2010
    #14
  15. d_s_klein

    Andy Peters Guest

    On Mar 6, 9:41 am, KJ <> wrote:
    > On Mar 5, 4:53 pm, Andy Peters <> wrote:
    >
    >
    >
    > > 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?


    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.

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


    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
    Andy Peters, Mar 8, 2010
    #15
  16. d_s_klein

    rickman Guest

    On Mar 8, 6:53 am, Martin Thompson <> wrote:
    > rickman <> writes:
    > > 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 :)


    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, Mar 8, 2010
    #16
  17. d_s_klein

    rickman Guest

    On Mar 8, 7:04 am, Martin Thompson <> wrote:
    > KJ <> writes:
    >
    > 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
    rickman, Mar 8, 2010
    #17
  18. d_s_klein

    Andy Peters Guest

    On Mar 8, 1:32 pm, rickman <> wrote:
    > On Mar 8, 6:53 am, Martin Thompson <> wrote:
    >
    > > rickman <> writes:
    > > > 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 :)

    >
    > 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
    Andy Peters, Mar 8, 2010
    #18
  19. d_s_klein

    rickman Guest

    On Mar 8, 4:40 pm, Andy Peters <> wrote:
    > On Mar 8, 1:32 pm, rickman <> wrote:
    >
    > > On Mar 8, 6:53 am, Martin Thompson <> wrote:

    >
    > > > rickman <> writes:
    > > > > 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 :)

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


    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
    rickman, Mar 8, 2010
    #19
  20. rickman <> writes:

    > 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
    --
    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, Mar 9, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. POLUX

    Active-hdl

    POLUX, Dec 18, 2003, in forum: VHDL
    Replies:
    0
    Views:
    579
    POLUX
    Dec 18, 2003
  2. Andy Peters

    ModelSim vs Aldec -- odd difference

    Andy Peters, Sep 4, 2009, in forum: VHDL
    Replies:
    9
    Views:
    1,488
    Andy Peters
    Oct 5, 2009
  3. rickman
    Replies:
    0
    Views:
    501
    rickman
    Mar 3, 2010
  4. Dave
    Replies:
    0
    Views:
    576
  5. Raymund Hofmann

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

    Raymund Hofmann, Mar 4, 2010, in forum: VHDL
    Replies:
    0
    Views:
    541
    Raymund Hofmann
    Mar 4, 2010
Loading...

Share This Page