Use of libraries

[PlayDough]

I'm interested in hearing opinions on the use of libraries for
synthesizable code.

Compare the following structural RTL:

architecture structure of system_top is
begin
inst1 : entity work.comp1
port map
(
);

inst2 : entity work.comp2
port map
(
);

inst3 : entity work.comp3
port map
(
);
end architecture structure;

versus this:

library comp1_lib;
library comp2_lib;
library comp3_lib;

architecture structure of system_top is
begin
inst1 : entity comp1_lib.comp1
port map
(
);

inst2 : entity comp2_lib.comp2
port map
(
);

inst3: entity comp3_lib.comp3
port map
(
);
end architecture structure;

What are the arguments for the former versus the latter? In the end,
during synthesis, the library names do not matter. The only advantage
I can see is if there are identically named entities collision could
occur with the former construct. Using separate libraries eliminates
this possible collision.

Any other tradeoffs?

Thanks,
Pete

 

[Mike Treseler]

I'm interested in hearing opinions on the use of libraries for
synthesizable code. ....
In the end,
during synthesis, the library names do not matter. The only advantage
I can see is if there are identically named entities collision could
occur with the former construct. Using separate libraries eliminates
this possible collision.

That advantage is correct for vhdl simulation,
but the downside overrides in my opinion --
unless there were ever a large group of
vhdl designers working on the same project.

Some synthesis "user libraries" are just places
for the tool to look for files missing from the list.
Actual vhdl libraries (other than ieee) are ignored.

For my source code, I prefer using direct instances
from "work" for structural entities because
this is most portable for simulation from project to project.

If I'm using code by others without touching it,
I usually map all the libraries to work and
use emacs vhdl-mode to warn me of collisions.

-- Mike Treseler

 

[Peter LaDow]

(Posting from another account, since Google Groups seems to be on the
fritz.)

That advantage is correct for vhdl simulation,
but the downside overrides in my opinion --
unless there were ever a large group of
vhdl designers working on the same project.

What would the downside be? Management of the library names?

Some synthesis "user libraries" are just places
for the tool to look for files missing from the list.
Actual vhdl libraries (other than ieee) are ignored.

If this were true, at least for ISE and Synplicity, I wouldn't be in the
bind that I am. We have one group developing components using library
statements and another that does not. When we borrow components from
both groups, ISE nor Synplicity will take the "libraried" code without
the mappings.

from "work" for structural entities because
this is most portable for simulation from project to project.

How so? Don't all the (major) simulators support individual libraries?
I know ModelSim, Aldec, and ISE do.

If I'm using code by others without touching it,
I usually map all the libraries to work and
use emacs vhdl-mode to warn me of collisions.

And what do you do if there is a collision? Map just those components
to individual libraries?

This really is a larger issue for me because we have a large set of
support scripts to do the synth-opt process. However, these script rely
upon configuration files that do not have support for individual library
mappings. So we are forced to do one of 2 things:

1. Modify the component we want to re-use to remove the library statements

or

2. Modify the scripts to handle library references.

I don't like #1 because it requires us to touch already tested and
approved code.

I'm in the camp for #2, because it is far more flexible to support
library references. In case a collision occurs, using #2 you have a
workaround. Going through code to change entity names is just as
painful as #1.

In the end, I think the reason I asked this was to see if there were any
other compelling reasons to avoid using libraries for components. A
collision will cause far more work than fixing it now to support library
mappings.

Thanks,
Pete

 

[Mike Treseler]

What would the downside be? Management of the library names?

Yes, and simulation.

If this were true, at least for ISE and Synplicity, I wouldn't be in the
bind that I am.

Does ISE or Synplicity support configurations?

We have one group developing components using library
statements and another that does not. When we borrow components from
both groups, ISE nor Synplicity will take the "libraried" code without
the mappings.

Then the choices are edit the code
or do the mappings. Your original question
asked about preferences for new code.
For that, I like to put everything in work,
and use direct instances instead of components.

How so? Don't all the (major) simulators support individual libraries?
I know ModelSim, Aldec, and ISE do.

Yes but my vhdl-mode makefile generator does not
and there is little upside for me anyway.

And what do you do if there is a collision? Map just those components
to individual libraries?

I prefer to get/make a rev with the identifiers clarified.
But this is a very rare occurrence for me.
Sounds like it is more common for you.

This really is a larger issue for me because we have a large set of
support scripts to do the synth-opt process. However, these script rely
upon configuration files that do not have support for individual library
mappings.

Yes, this is my hot button.
Why use vhdl components at all
when configurations don't work at synthesis?

In the end, I think the reason I asked this was to see if there were any
other compelling reasons to avoid using libraries for components.

There is a good argument to avoid components
but library usage is a gray area.

-- Mike Treseler

 

[KJ]

I'm interested in hearing opinions on the use of libraries for
synthesizable code.

What are the arguments for the former versus the latter? In the end,
during synthesis, the library names do not matter. The only advantage
I can see is if there are identically named entities collision could
occur with the former construct. Using separate libraries eliminates
this possible collision.

Frequently, entities have an associated package of type definitions,
conversion functions and such (a simple example would be the bit mappings of
software control/status ports) that need to be accessed both from within the
entity/architecture and from 'somewhere else' where the 'somewhere else' is
either the code that instantiates the entity or a testbench or both. If
that package is contained in the same physical file as the
entity/architecture then it will be compiled to the new libraries
(comp1_lib, etc.) so now all of the places where these packaged
types/functions get used will need to be edited to call out the different
library name.

An alternative would be to separate the package from the entity/architecture
file(s) so that it could still be compiled to 'work' and code changes could
probably be avoided in that case.

Personally I prefer to not have multiple identically named entities in the
same project and will rename one of them since I'm still in the development
stage at that point and the code in question is still under development
either by me or somebody else. If one were trying to construct a 'bake off'
type of testbench where you really want to instantiate two different
identically named entities but didn't want to muck with the code at all
since you're simply trying to use the entities then libraries would be a
good way to go about it.

The other problem with arbitrarily putting something into some library that
the designer of the original code has no knowledge of is that any lower
level entities that they call would probably have problems. For example if
comp1 instantiates comp2 then the code for comp1 would need to be edited so
that it calls out comp2 from the comp2_lib.

Whether package contents or lower level blocks are an issue or not would of
course vary from project to project. Putting things into separate libs
might work out really well on one project and be a pain in the butt on the
next.

KJ

 

[Mike Treseler]

Frequently, entities have an associated package of type definitions,
conversion functions and such (a simple example would be the bit mappings of
software control/status ports) that need to be accessed both from within the
entity/architecture and from 'somewhere else' where the 'somewhere else' is
either the code that instantiates the entity or a testbench or both. If
that package is contained in the same physical file as the
entity/architecture then it will be compiled to the new libraries
(comp1_lib, etc.) so now all of the places where these packaged
types/functions get used will need to be edited to call out the different
library name.

...unless everything is in or mapped to the default library.
Here is an example of a library and entity pair
in the same physical file:

http://home.comcast.net/~mike_treseler/stack.vhd

When this file is compiled
the entity work.stack
and the package work.stack_pkg become visible.

Now any entity needing this unit can say

use work.stack_pkg.all;

to get at the useful declarations and

stack_1: entity work.stack
port map ( ...

for an instance.

Personally I prefer to not have multiple identically named entities in the
same project and will rename one of them since I'm still in the development
stage at that point and the code in question is still under development
either by me or somebody else.

I agree. It's easier for me to use a unique
name for all entities and packages than it
is to manage libraries.

As long as everything compiles and elaborates,
I see no downside to checking in potentially
useful library units that may or may not ever be used.

-- Mike Treseler

 

[KJ]

..unless everything is in or mapped to the default library.
Here is an example of a library and entity pair
in the same physical file:

http://home.comcast.net/~mike_treseler/stack.vhd

When this file is compiled
the entity work.stack
and the package work.stack_pkg become visible.

As in your example, package, entity and architecture in the same file is
also typically what I do in most circumstances.

My point was that if you though you could avoid name clashing by compiling
the file stack.vhd to the 'mikes_stack_lib' library then you would need to
replace references such as
work.stack_pkg.whatever
with
mikes_stack_lib.stack_pkg.whatever

If these references are in the code that you're trying not to touch by
creating unique libraries instead of simply renaming the entity then you'll
simply get stuck with renaming "work.stack_pkg...." with
"mikes_stack_lib.stack_pkg....". You might get lucky if there are no
references but I don't think I've ever had a case where I have a non-empty
package where either the entity or architecture didn't want to get at
something in that package...many times in the "use work.stack_pkg.all;"
statement....which would need to be edited to change the library name thus
defeating the purpose of not touching the code...which I thought was kind of
one of the goals of the original post (and the earlier followup that you and
he had).

KJ

 

[kennheinrich]

I'm interested in hearing opinions on the use of libraries for
synthesizable code.

Compare the following structural RTL:

architecture structure of system_top is
begin
inst1 : entity work.comp1
port map
(
);

inst2 : entity work.comp2
port map
(
);

inst3 : entity work.comp3
port map
(
);
end architecture structure;

versus this:

library comp1_lib;
library comp2_lib;
library comp3_lib;

architecture structure of system_top is
begin
inst1 : entity comp1_lib.comp1
port map
(
);

inst2 : entity comp2_lib.comp2
port map
(
);

inst3: entity comp3_lib.comp3
port map
(
);
end architecture structure;

What are the arguments for the former versus the latter? In the end,
during synthesis, the library names do not matter. The only advantage
I can see is if there are identically named entities collision could
occur with the former construct. Using separate libraries eliminates
this possible collision.

Any other tradeoffs?

Thanks,
Pete

Despite what you might *like* to do, the course you choose may be
determined by tool support. There are some mixed-language VHDL/Verilog
tools that, once you include some Verilog code (like an FPGA vendor's
proprietary core model, for example) , force you to return to an
inelegant ground state where everything must be dumped into work. If
you're planning to stay entirely in the VHDL world, then the libs can
promote clean separation and re-use by letting you separate the name
spaces as you noted. On the other hand, if memory serves, some older
synthesizers seemed to treat *every* library as if it were work,
thereby potentially introducing collisions/ambiguity/errors that
weren't there in the actual design, when interpreted under full LRM
semantics.

HTH,

- Kenn

 

[Mike Treseler]

As in your example, package, entity and architecture in the same file is
also typically what I do in most circumstances.

My point was that if you though you could avoid name clashing by compiling
the file stack.vhd to the 'mikes_stack_lib' library then you would need to
replace references such as
work.stack_pkg.whatever
with
mikes_stack_lib.stack_pkg.whatever

I was advocating compiling everything into work
and Peter wanted separate libraries, but that's right.
If I did compile into 'mikes_stack_lib' then I either
have to map that name to 'work' -- if that is possible --
or edit the code.

-- Mike Treseler

 

[KJ]

If

you're planning to stay entirely in the VHDL world, then the libs can
promote clean separation and re-use by letting you separate the name
spaces as you noted.

Putting things into libraries other than 'work' doesn't do anything to
"promote clean separation and re-use" and, as I noted in other parts of the
thread, frequently you can not just after the fact decide which library to
compile a file into without editing the code as well. Having a long list of
things (preferably everything) compiled into 'work' is just fine.

On the other hand, if memory serves, some older
synthesizers seemed to treat *every* library as if it were work,
thereby potentially introducing collisions/ambiguity/errors that
weren't there in the actual design, when interpreted under full LRM
semantics.

If you're paid up on support for that tool, then that's when you open a
service request to have the tool fixed....and then work on your work around
so you can move ahead.

KJ

 

[Andy]

..unless everything is in or mapped to the default library.
Here is an example of a library and entity pair
in the same physical file:

http://home.comcast.net/~mike_treseler/stack.vhd

When this file is compiled
the entity work.stack
and the package work.stack_pkg become visible.

Now any entity needing this unit can say

use work.stack_pkg.all;

to get at the useful declarations and

stack_1: entity work.stack
port map ( ...

for an instance.


I agree. It's easier for me to use a unique
name for all entities and packages than it
is to manage libraries.

As long as everything compiles and elaborates,
I see no downside to checking in potentially
useful library units that may or may not ever be used.

-- Mike Treseler

Hmmm... Interesting discussion. One thing to add to the fray is that,
no matter what ultimate library name is used to hold a group of
entities or packages, anything within it that references something
else expected to be in the same library should reference it as "work".
That way when/if those files are compiled into library "X", they need
not be edited, no matter what "X" is.

The more complicated problem is when entities or packages reference
something that is not (expected) in their own library (i.e. they
imported it from somewhere else). They have to use an explicit name
for that library, and if you need to change the name of that 3rd
library (maybe it conflicts with one of your own library names), then
you have no choice but to change the code. Luckily this doesn't happen
too often...

BTW, I prefer to put any package that defines data types, functions,
etc. specific to a given entity/architecture, into the same file as
the entity/architecture. That way, I can even define interface types
for the ports on the entity, and be assured that the library that has
the entity will also contain the package that defines its interface
types. Kind of like telling the user "If you need this entity, you'll
need this package too."

Andy

 

[Brian Drummond]

I'm interested in hearing opinions on the use of libraries for
synthesizable code.

Compare the following structural RTL:

architecture structure of system_top is
begin
inst1 : entity work.comp1
port map
(
);

versus this:

library comp1_lib;

architecture structure of system_top is
begin
inst1 : entity comp1_lib.comp1
port map
(
);

What are the arguments for the former versus the latter? In the end,
during synthesis, the library names do not matter.

I find it convenient to use a separate library for common components,
and have also done so for a group of components I wanted to reuse,
rather than lumping the whole project into work. However I concede this
is just personal preference.

The only advantage
I can see is if there are identically named entities collision could
occur with the former construct. Using separate libraries eliminates
this possible collision.

Be aware this is NOT true if you are using Xilinx XSTsynthesis under
Project Navigator. In the past (Webpack 6.x, ISE 7.1) I have simply
renamed components to avoid collisions and moved on, but this discussion
prompted me to try again in Webpack 9.1. (I have ISE 8.x but haven't
tried it.)

I can create a project with two libraries (MathAdd, MathMult) in
addition to work, each with an identically named "mathop" entity (one
adds, the other multiplies - yes it's a contrived example!).
I can instantiate a "mathop" component in each of two entities in Work,
and "add source" and "move to library" in Project Navigator; and if I do
so in EXACTLY the right order for all the source files, XST synthesises
the correct hardware, i.e. one adder and one multiplier, even though the
"sources" view shows both instances as the adder.

But any other order yields a synthesis failure.

Since XST can get the correct result I guess it's the GUI that's at
fault. If I can nail it down tighter I guess I'll submit a webcase...

- Brian

 

[Paul Uiterlinden]

Hmmm... Interesting discussion. One thing to add to the fray is that,
no matter what ultimate library name is used to hold a group of
entities or packages, anything within it that references something
else expected to be in the same library should reference it as "work".
That way when/if those files are compiled into library "X", they need
not be edited, no matter what "X" is.

Exactly! "work" refers to the working library, i.e. the library the current
design unit is being compiled into.

Now the fact that "work" can also be a literal name of a library seems to
cause confusion from time to time. And of course the fact that "work" is
the default working library.

I hope this does not add to the confusion....

 

[Martin Thompson]

BTW, I prefer to put any package that defines data types, functions,
etc. specific to a given entity/architecture, into the same file as
the entity/architecture. That way, I can even define interface types
for the ports on the entity, and be assured that the library that has
the entity will also contain the package that defines its interface
types. Kind of like telling the user "If you need this entity, you'll
need this package too."

Don't you get annoyed recompiling everything that instantiates that
entity when you make a small tweak to the architecture?

I've taken to splitting architectures and package bodies out so that
when I'm developing them I only have to compile a single file (the
one I changed) to rerun the tests.

Yes, I have a makefile, but I can compile and rerun the test before
the makefile has figured out what files to recompile. It comes in
handy when I change a package or entity though!

Cheers,
Martin

 

[Mike Treseler]

Don't you get annoyed recompiling everything that instantiates that
entity when you make a small tweak to the architecture?

I might if I did structural designs.
I prefer handle duplicates as data
structures in the same process.

I've taken to splitting architectures and package bodies out so that
when I'm developing them I only have to compile a single file (the
one I changed) to rerun the tests.
Yes, I have a makefile, but I can compile and rerun the test before
the makefile has figured out what files to recompile. It comes in
handy when I change a package or entity though!

Are we talking about functional simulations?
If so, I haven't seen such delays.

-- Mike Treseler

 

[KJ]

Don't you get annoyed recompiling everything that instantiates that
entity when you make a small tweak to the architecture?

In a file with package/entity/architecture together, if the only thing that
I change is the architecture then I don't have to recompile the things that
use the packages or entities. This is with Modelsim and I typically do a
'Compile out of date' from the GUI and go right on back to simulating. For
the fans of 'make', since the file timestamp changed it will think that the
other files will need recompiling leading to the annoyance that you're
speaking about.

If the entity or package does change and I try to simulate then I do get an
error that package such and such is out of date and so and so needs to be
recompiled (as it should). I guess score one for the GUI over make in this
instance.

I've taken to splitting architectures and package bodies out so that
when I'm developing them I only have to compile a single file (the
one I changed) to rerun the tests.

I would too were it not for 'Compile out of date'.

Yes, I have a makefile, but I can compile and rerun the test before
the makefile has figured out what files to recompile. It comes in
handy when I change a package or entity though!

Maybe consider using the GUI

KJ

 

[Martin Thompson]

In a file with package/entity/architecture together, if the only thing that
I change is the architecture then I don't have to recompile the things that
use the packages or entities. This is with Modelsim and I typically do a
'Compile out of date' from the GUI and go right on back to simulating. For
the fans of 'make', since the file timestamp changed it will think that the
other files will need recompiling leading to the annoyance that you're
speaking about.

That's a feature of Modelsim I didn't know about - thanks! I shall
have to find out how to do this from the vsim command-line ;-) I hate mices...

If the entity or package does change and I try to simulate then I do get an
error that package such and such is out of date and so and so needs to be
recompiled (as it should). I guess score one for the GUI over make in this
instance.

Indeed!

I would too were it not for 'Compile out of date'.

Maybe consider using the GUI

I shall have to consider that, although getting my Emacs fingers out
of the habit of prodding C-sC-cC-k then ALT-TAB, up-arrow ENTER to
compile and sim will be hard

Cheers,
Martin

 

[Martin Thompson]

I might if I did structural designs.
I prefer handle duplicates as data
structures in the same process.


Are we talking about functional simulations?
Yes.

If so, I haven't seen such delays.

Maybe I'm oversensitive!

It's much worse when the files are on the network, but even locally I
"feel" the lag.

Cheers,
Martin

 

[NigelE]

That's a feature of Modelsim I didn't know about - thanks! I shall
have to find out how to do this from the vsim command-line ;-) I hate mices...





I shall have to consider that, although getting my Emacs fingers out
of the habit of prodding C-sC-cC-k then ALT-TAB, up-arrow ENTER to
compile and sim will be hard

Cheers,
Martin

--
(e-mail address removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html- Hide quoted text -

- Show quoted text -

The vcom -just <abcep> option can help here, where
a = architectures
b = bodies
c = configurations
e = entities
p = packages

as this will only comnpile the stated design units from the specified
file

Thus

vcom -just p *.vhd
vcom -just b *.vhd
vcom -just e *.vhd
vcom -just a *.vhd
vcom -just c *.vhd

is a generic compile script that should compile your files in the
correct order, independent of how you've organised your design units.

- Nigel

 

[KJ]

That's a feature of Modelsim I didn't know about - thanks! I shall
have to find out how to do this from the vsim command-line ;-) I hate
mices...

I looked a little bit for a command line way to do it without luck so if you
do find such a command post it back up here.

KJ