very simple question vhd files

Discussion in 'VHDL' started by Xin Xiao, Dec 6, 2007.

  1. Xin Xiao

    Xin Xiao Guest

    Hi , perhaps this is a very simple question...

    is it a good practice to include several entities-architectures in the same
    vhd file or should I separate them in different vhd files?
     
    Xin Xiao, Dec 6, 2007
    #1
    1. Advertising

  2. Xin Xiao wrote:

    > is it a good practice to include several entities-architectures in the
    > same vhd file or should I separate them in different vhd files?


    I use the same file.
    I often put a package in front of the entity, like this:
    http://home.comcast.net/~mike_treseler/stack.vhd

    -- Mike Treseler
     
    Mike Treseler, Dec 7, 2007
    #2
    1. Advertising

  3. Mike Treseler wrote:
    > Xin Xiao wrote:
    >
    >> is it a good practice to include several entities-architectures in the
    >> same vhd file


    Sorry, make that one file per entities-architecture pair.
    To many dependencies otherwise.

    or should I separate them in different vhd files?

    Yes. I read the question too quickly.
    Some separate the entity and architecture
    as well, but I find no advantage to that.

    -- Mike Treseler
     
    Mike Treseler, Dec 7, 2007
    #3
  4. Xin Xiao

    Guest

    On Dec 6, 3:20 pm, "Xin Xiao" <> wrote:
    > Hi , perhaps this is a very simple question...
    >
    > is it a good practice to include several entities-architectures in the same
    > vhd file or should I separate them in different vhd files?


    In addition to separate files for each entity, the name of the file
    should match the name of the entity.

    Just like Mike did it: stack.vhd has one entity: stack.

    G.
     
    , Dec 7, 2007
    #4
  5. Mike Treseler wrote:

    > Mike Treseler wrote:
    >> Xin Xiao wrote:
    >>
    >>> is it a good practice to include several entities-architectures in the
    >>> same vhd file

    >
    > Sorry, make that one file per entities-architecture pair.
    > To many dependencies otherwise.
    >
    > or should I separate them in different vhd files?
    >
    > Yes. I read the question too quickly.
    > Some separate the entity and architecture
    > as well, but I find no advantage to that.


    Dependencies.

    Putting one design unit (entity, architecture, package, package body,
    configuration) in a file reduces the number of dependencies.

    Changing for example a package body does not cause a need for recompilation
    of any other design unit. If it was put in one file together with the
    package, every design unit using the package would need to be recompiled.

    Especially when maintaining a set of compiled libraries used by many people,
    having only one design unit per file is a real advantage.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Dec 7, 2007
    #5
  6. Xin Xiao

    KJ Guest

    On Dec 6, 6:20 pm, "Xin Xiao" <> wrote:
    > Hi , perhaps this is a very simple question...
    >
    > is it a good practice to include several entities-architectures in the same
    > vhd file or should I separate them in different vhd files?


    It can depend on your specific work habits, file naming conventions,
    etc. but generally I find it best to put one entity/architecture in a
    single file named with the entity name to make it easy to find.

    If an entity requires use of record definitions, conversion functions,
    etc. in order for the typical user of the entity to work with it (and
    more times than not, it will), I put the package and package body that
    contains all of that stuff in the same file prior to the entity/
    architecture (so that the e/a can use it as well). This is the same
    method that Mike uses in his posting with his link to an example.

    Paul has a good point about separating the package from the entity in
    order to minimize the number of dependent files that need
    recompiling. Many times though I don't run across the situation where
    only the package body needs to change, usually the package itself
    needs to change as well so separating the package into a separate file
    just means I have one more file to manage and nothing to gain from the
    extra management which is why I combine them....it also makes it easy
    to update at least some of the dependent changes since they are
    generally in the entity/architecture which are in the same file.

    What is 'best practice' probably may come down to how many different
    groups/people not counting yourself are the users of your code and how
    onerous it is (or isn't) to recompile some extra supposedly dependent
    files where the dependency is defined by 'make' which works at the
    file level.

    Kevin Jennings
     
    KJ, Dec 7, 2007
    #6
  7. Xin Xiao

    Andy Guest

    On Dec 7, 6:43 am, KJ <> wrote:
    > On Dec 6, 6:20 pm, "Xin Xiao" <> wrote:
    >
    > > Hi , perhaps this is a very simple question...

    >
    > > is it a good practice to include several entities-architectures in the same
    > > vhd file or should I separate them in different vhd files?

    >
    > It can depend on your specific work habits, file naming conventions,
    > etc. but generally I find it best to put one entity/architecture in a
    > single file named with the entity name to make it easy to find.
    >
    > If an entity requires use of record definitions, conversion functions,
    > etc. in order for the typical user of the entity to work with it (and
    > more times than not, it will), I put the package and package body that
    > contains all of that stuff in the same file prior to the entity/
    > architecture (so that the e/a can use it as well). This is the same
    > method that Mike uses in his posting with his link to an example.
    >
    > Paul has a good point about separating the package from the entity in
    > order to minimize the number of dependent files that need
    > recompiling. Many times though I don't run across the situation where
    > only the package body needs to change, usually the package itself
    > needs to change as well so separating the package into a separate file
    > just means I have one more file to manage and nothing to gain from the
    > extra management which is why I combine them....it also makes it easy
    > to update at least some of the dependent changes since they are
    > generally in the entity/architecture which are in the same file.
    >
    > What is 'best practice' probably may come down to how many different
    > groups/people not counting yourself are the users of your code and how
    > onerous it is (or isn't) to recompile some extra supposedly dependent
    > files where the dependency is defined by 'make' which works at the
    > file level.
    >
    > Kevin Jennings


    Like Kevin, I now prefer to keep logical things together, and let
    smarter tools figure it out. Some simulators have a mode where if
    recompilation of a file did not change the library unit, then it does
    not update that unit in the library, and avoids the downstream
    recompilation of other units dependent upon that unit. Some also have
    options to only compile certain types of units found in the file(s).
    So, if your entity and package did not change, you could tell it to
    compile only bodies and architectures in the file.

    I use a lot of entity(architecture) instantiation, so compile
    dependencies are something I'm willing to live with to keep the files
    manageable anyway.

    Compile dependencies were a big deal when compilers (and the computers
    they ran on) were agonizingly slow, but I find them fast enough today
    to handle a little extra work so I don't have to.

    Andy
     
    Andy, Dec 7, 2007
    #7
  8. On 7 Dez., 00:20, "Xin Xiao" <> wrote:
    > Hi , perhaps this is a very simple question...
    >
    > is it a good practice to include several entities-architectures in the same
    > vhd file or should I separate them in different vhd files?


    Having you design in one file simplifies the toolchain on first glance
    but avoids nearly every code reuse.

    I prefer having entity, architecture and configurations in seperate
    files. This eases the work with different architectures (e.g. for
    different technologies) for one entity.
    A good naming convention is necessary to handle the different files.

    bye Thomas
     
    Thomas Stanka, Dec 9, 2007
    #8
    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. MACEI'S
    Replies:
    0
    Views:
    1,351
    MACEI'S
    Jul 10, 2003
  2. Raymond Arthur St. Marie II of III

    very Very VERY dumb Question About The new Set( ) 's

    Raymond Arthur St. Marie II of III, Jul 23, 2003, in forum: Python
    Replies:
    4
    Views:
    486
    Raymond Hettinger
    Jul 27, 2003
  3. shanx__=|;-

    very very very long integer

    shanx__=|;-, Oct 16, 2004, in forum: C Programming
    Replies:
    19
    Views:
    1,642
    Merrill & Michele
    Oct 19, 2004
  4. Peter

    Very very very basic question

    Peter, Feb 8, 2005, in forum: C Programming
    Replies:
    14
    Views:
    521
    Dave Thompson
    Feb 14, 2005
  5. olivier.melcher

    Help running a very very very simple code

    olivier.melcher, May 12, 2008, in forum: Java
    Replies:
    8
    Views:
    2,310
Loading...

Share This Page