info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
VHDL code error
2,779 views
Skip to first unread message
Youssef Ahmed
Apr 11, 2014, 9:29:59 AM4/11/14
to
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.
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
Apr 11, 2014, 10:11:22 AM4/11/14
to
Hi Youssef,
Youssef Ahmed <eng.yous...@gmail.com> wrote:
[]
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!!
Youssef Ahmed <eng.yous...@gmail.com> wrote:
[]
> 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.
> "std_logic"." while the 3rd just says "VHDL Compiler exiting", any
> help would be greatly appreciated, thanks in advance.
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
Apr 11, 2014, 10:32:39 AM4/11/14
to
On 11/04/2014 14:29, Youssef Ahmed wrote:
> 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;
> 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;
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
> 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,
> 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.
>
Hans
www.ht-lab.com
KJ
Apr 11, 2014, 11:08:28 AM4/11/14
to
On Friday, April 11, 2014 9:29:59 AM UTC-4, Youssef Ahmed wrote:
You need to place the following...
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
You need to place the following...
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
Apr 14, 2014, 12:43:38 PM4/14/14
to
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
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
Apr 15, 2014, 3:39:39 AM4/15/14
to
Hi Kevin,
KJ <kkjen...@sbcglobal.net> wrote:
[]
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.
KJ <kkjen...@sbcglobal.net> wrote:
[]
> ...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
> 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 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
Apr 15, 2014, 4:22:17 AM4/15/14
to
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).
> 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.
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
Apr 15, 2014, 8:45:26 AM4/15/14
to
Hi Thomas,
Thomas Stanka <usenet_no...@stanka-web.de> wrote:
[]
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
Thomas Stanka <usenet_no...@stanka-web.de> wrote:
[]
>> 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.
I have to assume the offending type definition is not on the entity's
>> 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.
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
Apr 15, 2014, 1:13:31 PM4/15/14
to
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
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
Apr 22, 2014, 3:56:36 AM4/22/14
to
Hi Andy,
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 <jone...@comcast.net> wrote:
> 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,
> 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.
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.)
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.
Alan Fitch
Apr 22, 2014, 4:35:19 PM4/22/14
to
"this behaviour is by design".
I suspect the main reason is to minimise the compilation dependencies
for efficiency reasons. In the early days of VHDL, I suspect that
compilation time was significant while on modern computers it is not
such a problem.
regards
Alan
--
Alan Fitch
Andy
Apr 22, 2014, 6:48:08 PM4/22/14
to
On Tuesday, April 22, 2014 2:56:36 AM UTC-5, alb wrote:
> 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.
> the main drawback is that you end up with a package for each component, which is less useful as a package in the end.
Also, with one package per component declaration, the list of packages used by 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
0 new messages