very simple question vhd files

[Xin Xiao]

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?

 

[Mike Treseler]

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]

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

 

[ghelbig]

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.

 

[Paul Uiterlinden]

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.

 

[KJ]

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

 

[Andy]

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

 

[Thomas Stanka]

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