VHDL code error

[Youssef Ahmed]

Hello there, i'm new here so i dont know if this is on topic or should be placed somewhere else.

my code is this:
"library ieee;
use ieee.std_logic_1164.all;

package andpackage is
component and2 is
port (a, b: IN std_logic;
c: OUT std_logic);
end component and2;
end package andpackage;

entity circuit2 is
port (a, b, x, y: IN std_logic;
d: OUT std_logic);
end entity circuit2;

architecture mixed of circuit2 is
for gate: and2 use entity work.and2(and2);
signal c,z: std_logic;
begin
gate: and2 port map (a,b,c);
d <= c XOR z;
op: process (x,y) is
begin
z <= x OR y;
end process op;
end architecture mixed;"

i get 3 errors, 2 of them say "(vcom-1136) Unknown identifier "std_logic"." while the 3rd just says "VHDL Compiler exiting", any help would be greatly appreciated, thanks in advance.

 

[alb]

Hi Youssef,

i get 3 errors, 2 of them say "(vcom-1136) Unknown identifier
"std_logic"." while the 3rd just says "VHDL Compiler exiting", any
help would be greatly appreciated, thanks in advance.

the information you are providing is not sufficient to spot the problem.
In order to compile the code the compiler should know *where* to look
for the ieee library and use the package you are referring to.

Do not focus only on the code, try to see if the environment you have is
setup properly. If possible, try to compile something you *know* should
work (like an example from a project tutorial of your tools [1] or
something you borrow from a colleague). Once you are sure your
environment is properly setup then you can focus on the code.

Al

[1] I think long ago I did the exercise for an Orcad project, something
like a Chebyshev filter...it failed miserably!!

 

[HT-Lab]

Hello there, i'm new here so i dont know if this is on topic or should be placed somewhere else.

my code is this:
"library ieee;
use ieee.std_logic_1164.all;

package andpackage is
component and2 is
port (a, b: IN std_logic;
c: OUT std_logic);
end component and2;
end package andpackage;

library ieee;
use ieee.std_logic_1164.all;
use work.andpackage.all;

entity circuit2 is
port (a, b, x, y: IN std_logic;
d: OUT std_logic);
end entity circuit2;

architecture mixed of circuit2 is

-- for gate: and2 use entity work.and2(and2);

signal c,z: std_logic;
begin
gate: and2 port map (a,b,c);
d <= c XOR z;
op: process (x,y) is
begin
z <= x OR y;
end process op;
end architecture mixed;"

i get 3 errors, 2 of them say "(vcom-1136) Unknown identifier "std_logic"." while the 3rd just says "VHDL Compiler exiting", any help would be greatly appreciated, thanks in advance.

Hope this help,

Hans
www.ht-lab.com

 

[KJ]

library ieee;
use ieee.std_logic_1164.all;

....before both the package definition (where you have it now) AND before the entity definition. Packages and entities are considered 'primary design units'. Any libraries you want to include must be listed prior to each one.. The 'architecture' is considered a 'secondary design unit' which does not need yet another round of 'library ieee...' because it has been immediately preceded by the primary design unit.

Kevin Jennings

 

[Andy]

As Hans has noted, The entity needs its context defined too.

In VHDL, there is no "file scope."

Each design unit (entity/architecture/package/package body declaration) in a file includes the context clause (lib..., use... statements) immediately preceding the design unit.

However, an architecture inherits the context of its entity, and a package body inherits the context of its package. This often leads many to mistakenly infer that a "file scope" exists for VHDL.

Andy

 

[alb]

Hi Kevin,

...before both the package definition (where you have it now) AND
before the entity definition. Packages and entities are considered
'primary design units'. Any libraries you want to include must be
listed prior to each one. The 'architecture' is considered a
'secondary design unit' which does not need yet another round of
'library ieee...' because it has been immediately preceded by the
primary design unit.

I'm so used to have packages and entities in separate files that I guess
I forgot about library and use clause scope! But now that we are at it,
what is the reason behind such a language 'feature'?

I like the idea that secondary units inherit primary units' libraries
and use clauses, but scoping those only to the 'first primary unit in a
file' seems quite...quirk.

 

[Thomas Stanka]

Am Dienstag, 15. April 2014 09:39:39 UTC+2 schrieb alb:

I forgot about library and use clause scope! But now that we are at it,
what is the reason behind such a language 'feature'?

I like the idea that secondary units inherit primary units' libraries
and use clauses, but scoping those only to the 'first primary unit in a
file' seems quite...quirk.

Assume your design contains two packages that define the type unsigned (first is the prefered one for your design, second due to IP-usage of bad designed IP).

If every primary unit would inherit from all primaries above, you could compile the design if each primary is in an individual file, but not if you combine several primary units in one file.
That would be real ....quirk.

regards Thomas

 

[alb]

Hi Thomas,

Assume your design contains two packages that define the type unsigned
(first is the prefered one for your design, second due to IP-usage of
bad designed IP).

If every primary unit would inherit from all primaries above, you
could compile the design if each primary is in an individual file, but
not if you combine several primary units in one file. That would be
real ....quirk.

I have to assume the offending type definition is not on the entity's
ports, otherwise you would need a wrapper around it in order to convert
the two unsigned definitions from/to eachother.

Now your primary unit has no indication that a different type defintion
should be used instead, hiding the subtle /feature/ in its context clause.

While I see how in your case a 'file scope' for context clause would not
work, I only see troubles in combining primary units in such a case.

I still see it as an overhead that for each primary unit I have to have
a separate context all of which are most likely the same (library ieee;
use ieee.std_logic_1164.all.

Al

 

[Andy]

I have seen designs where each file contained a package, an entity and its architecture. The package contained a component declaration corresponding to the entity in that file.

The instantiating architecture would use the packages associated with entities it will use, and the packages are guaranteed to be compiled if the entities are compiled.

This is probably the cleanest way of keeping component declarations easily usable, yet in sync with their entities, that I have seen (if you have to use components at all.)

Including, in the same file, a package with a component declaration that the architecture will/may instantiate (the OP's apparent use case) is less useful.

Andy

 

[alb]

Hi Andy,

I have seen designs where each file contained a package, an entity and
its architecture. The package contained a component declaration
corresponding to the entity in that file.

The instantiating architecture would use the packages associated with
entities it will use, and the packages are guaranteed to be compiled
if the entities are compiled.

the main drawback is that you end up with a package for each component,
which is less useful as a package in the end. A possibility maybe is to
define a 'context' (vhdl-2008) and maintain the list of packages in
there.

This is probably the cleanest way of keeping component declarations
easily usable, yet in sync with their entities, that I have seen (if
you have to use components at all.)

Another would be to generate a package with component declarations
automatically from a list of entities. Emacs has keybindings to copy an
entity declaration and paste it as a component, maybe with a little bit
of lisp would be possible to generate an entire package with all
necessary components in the same way.

 

[Andy]

the main drawback is that you end up with a package for each component, which is less useful as a package in the end.

Using a package that declares the component, even if it is only one component, is much easier than repeating (and maintaining!) the component declaration in every architecture that instantiates it.

Also, with one package per component declaration, the list of packages usedby a given architecture will be fairly small (only for those components instantiated in that architecture.) It also gives the reader a heads-up regarding which components are instantiated in the file.

If either a common package containing all componentes is used, or a common context using all the packages is employed, then anytime any one of the packages/components is updated (perhaps due to its corresponding entity being updated), everything has to be recompiled.

On the other hand, compilers (and the computers they run on) have gotten pretty fast these days, especially compared to when VHDL was first introduced(1987)!

Andy