WORK

[glen herrmannsfeldt]

I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references
many other entities without any problem. But then I wanted
one of those to reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

I am more used to verilog, but structural VHDL isn't all that
different from structural verilog, if you change a few words.

-- glen

 

[KJ]

On Thursday, July 9, 2015 at 1:52:57 PM UTC-4, glen herrmannsfeldt wrote:

I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references
many other entities without any problem. But then I wanted
one of those to reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

Yes. To instantiate entity xyz directly you would type:
My_Thingy : entity work.xyz port map(...);

The other way is to define a component in which case you would instantiate the component this way:
My_Thingy : xyz port map(...);

But creating a component is busy work that can lead to other problems. Better to use the direct entity instantiation as shown in the first example.

Kevin Jennings

 

[glen herrmannsfeldt]

KJ <kkjennings@sbcglobal.net> wrote:

On Thursday, July 9, 2015 at 1:52:57 PM UTC-4, glen herrmannsfeldt wrote:
I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references
many other entities without any problem. But then I wanted
one of those to reference an entity, and got errors from Xilinx ISE.

(snip)

Am I supposed to put WORK. in front of all the entity refernces?

Yes. To instantiate entity xyz directly you would type:
My_Thingy : entity work.xyz port map(...);

The other way is to define a component in which case you would
instantiate the component this way:
My_Thingy : xyz port map(...);

But creating a component is busy work that can lead to other
problems. Better to use the direct entity instantiation as shown
in the first example.

Yes, I first learned component, but quickly found out about
entity and is so much easier. (Though I often put in a comment
explaining the ports so I don't forget.)

It seems to work for the first level without work. but not deeper.

The Xilinx explanation compares it to Java's this, which you
normally don't need to put in front of every variable and method
reference. It sounds like work is supposed to be the default.

It seems that Xilinx uses a different parser for Spartan 6, which
is part of the explanation for why this recently came up.

Can I say:

library work;

and get around needing it for each one?

thanks,

-- glen

 

[rickman]

On 7/9/2015 1:52 PM, glen herrmannsfeldt wrote:

I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references
many other entities without any problem. But then I wanted
one of those to reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

I am more used to verilog, but structural VHDL isn't all that
different from structural verilog, if you change a few words.

Work is the default working directory of the tools where all the code
that is not specifically assigned to a library/package resides. I won't
say I am overly familiar with all the details of using libraries. I
often just mess with stuff until it works. But I don't recall ever
having to add "work" to the name of an entity for the tools to find it.
Perhaps you have tweaked something that changed the default?

--

Rick

 

[rickman]

On 7/9/2015 2:19 PM, rickman wrote:

On 7/9/2015 1:52 PM, glen herrmannsfeldt wrote:
I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references
many other entities without any problem. But then I wanted
one of those to reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

I am more used to verilog, but structural VHDL isn't all that
different from structural verilog, if you change a few words.

Work is the default working directory of the tools where all the code
that is not specifically assigned to a library/package resides. I won't
say I am overly familiar with all the details of using libraries. I
often just mess with stuff until it works. But I don't recall ever
having to add "work" to the name of an entity for the tools to find it.
Perhaps you have tweaked something that changed the default?

BTW, is this a Maynard G Krebs thread? WORK!!??

--

Rick

 

[Allan Herriman]

On Thu, 09 Jul 2015 17:52:53 +0000, glen herrmannsfeldt wrote:

I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references many other
entities without any problem. But then I wanted one of those to
reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

I am more used to verilog, but structural VHDL isn't all that different
from structural verilog, if you change a few words.

From a 2002 comp.lang.vhdl post of mine ...


[In an entity instantiation] entity 'E' will need to be qualified in some
way. I know of three ways:

1.
library lib; -- not needed if 'lib' is work
use lib.E;
....
label : entity E
generic map (
...

2.
library lib; -- not needed if 'lib' is work
use lib.all; -- 'all' picks up E (and possibly other stuff)
....
label : entity E
generic map (
...

3.
library lib; -- not needed if 'lib' is work
....
label : entity lib.E
generic map (
...


All three methods should work in any 1993 (or later) compliant VHDL
compiler. Method 3 is by far the most popular. Also, most designers
only use one library, so the entity instantiation will typically look
like:

label : entity work.E
generic map (
...


It's also possible to specify an architecture, e.g.

label : entity lib.E(A)
generic map (
...

would select architecture "A" of entity "E" in the library "lib". This
is handy in testbenches if you want to instantiate two different
architectures for the same entity, without needing to use a configuration.


I rarely use component instantiations, but when I do, I include the
(optional) component keyword to make them stand out in my source code,
e.g.

label : component E
generic map (
...



Regards,
Allan

 

[Allan Herriman]

On Fri, 10 Jul 2015 10:57:07 +0000, Allan Herriman wrote:

On Thu, 09 Jul 2015 17:52:53 +0000, glen herrmannsfeldt wrote:

I don't understand the use of WORK in VHDL.

I have a large module, well entity in VHDL, that references many other
entities without any problem. But then I wanted one of those to
reference an entity, and got errors from Xilinx ISE.

The fix seems to be to put WORK. in front of the entity name.

Am I supposed to put WORK. in front of all the entity refernces?

I am more used to verilog, but structural VHDL isn't all that different
from structural verilog, if you change a few words.



From a 2002 comp.lang.vhdl post of mine ...


[In an entity instantiation] entity 'E' will need to be qualified in
some way. I know of three ways:

1.
library lib; -- not needed if 'lib' is work use lib.E;
...
label : entity E
generic map (
...

2.
library lib; -- not needed if 'lib' is work use lib.all; -- 'all'
picks up E (and possibly other stuff)
...
label : entity E
generic map (
...

3.
library lib; -- not needed if 'lib' is work ...
label : entity lib.E
generic map (
...


All three methods should work in any 1993 (or later) compliant VHDL
compiler. Method 3 is by far the most popular. Also, most designers
only use one library, so the entity instantiation will typically look
like:

label : entity work.E
generic map (
...


It's also possible to specify an architecture, e.g.

label : entity lib.E(A)
generic map (
...

would select architecture "A" of entity "E" in the library "lib". This
is handy in testbenches if you want to instantiate two different
architectures for the same entity, without needing to use a
configuration.


I rarely use component instantiations, but when I do, I include the
(optional) component keyword to make them stand out in my source code,
e.g.

label : component E
generic map (
...

Pan's word wrap strikes again. Those use clauses were meant to be on new
lines.

Allan

 

[Jim Lewis]

One motivation to use component instantiation is they can be configured with a configuration declaration.

In a testbench, this allows you to remove components from a simulation when they are not in use, and hence, do core level simulations using a chip level testbench. My goal is the reduction of the number of unique testbench frameworks I need to support.

It is planned to revise configurations to allow the architecture of direct entity instances (the one you prefer without component declarations) to be configured, but it will take time to get it into the standard and then more time to get it in a simulator.

Jim

 

[Andy]

There are additional options for "configuring" entities without using components using 93 - 2008 versions of VHDL. They all require that the entity instantiation in the design code NOT specify the architecture (optional, in parentheses after the entity name).

When elaborated, if no architecture is specified in the entity instantiation, the most recently analyzed architecture for the entity will be used. Thus, if for simulation, you analyze (compiled) a new architecture for an entity, AFTER the original architecture is analyzed, the new architecture will be used for the entity in the simulation.

Such an architecture may be completely different (empty/benign/broken, gate level, behavioral, etc.) than the original architecture.

Such an architecture can also re-instantiate the entity with the original architecture by specifying the original architecture with its entity instantiation. I call this a "wrapper" architecture. A wrapper architecture can effectively alter the generic map, assert conditions on intefaces and even modify interface behavior (such as forcing output data to X when the valid signal is not asserted). A wrapper architecture can also conditionally do these things based on a generic value, using if-generate statements as needed.

In practice such "configurations" are managed through compile scripts rather than a configuration unit. Sometimes it is easier to just bite the bullet and use configurations & components, but for limited cases, it is easier to manage the compile scripts. Or, just wait until vhdl 201x.

BTW, "work" provides a library-name-independent method of specifying that a needed resource can be found in the same library which contains the referencing unit. This provides independence from the name of the library. This allows, among other ways, the same library code to be compiled into different libraries, with different names, and referenced separately for different/duplicate purposes. Imagine a design that uses a package do declare a bunch of "global" signals, but you want to run a simulation that includes more than one copy of the design, but those global signals can't be shared between both copies. Compile one copy of the design into one library, and another copy into another library, and their "global" signals will be local to each design copy.

Andy