Compiler can't detect std_logic_1164 package

[aijazbaig1]

Hello.
Newbie here. I am trying to write a very simple program to simulate a
multiplexer. I am using the xilinx version of the modelsim compiler
viz. Modelsim XE version.
heres my code:

library ieee;
use ieee.std_logic_1164.all;

entity mux is
port(a,b:IN std_logic_vector(7 downto 0);
sel:IN std_logic_vector(1 downto 0);
c : OUT std_logic_vector(7 downto 0));
end mux;

architecture example of mux is
begin
process(a,b,sel)
begin
if(sel = "00") then
c <= "00000000";
elsif (sel = "01") then
c <= a;
elsif (sel = "10") then
c <= b;
else
c <= (OTHERS => 'Z');
end if;
end process;
end example;

entity tb_mux is
end entity;

architecture mux of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel1 : std_logic_vector(1 downto 0);
component muxc is
port(a,b : in std_logic_vector(7 downto 0);
sel : in std_logic_vector(1 downto 0);
c : out std_logic_vector(7 downto 0));
end muxc;
for all:muxc use entity mux(example);
begin
M1:muxc port map(a,b,sel,c);
process
begin
a <= X"11" after 1 ns,
X"AF" after 2 ns,
X"BB" after 3 ns,
X"6F" after 4 ns;

b <= X"01" after 1 ns,
X"2F" after 2 ns,
X"3C" after 3 ns,
X"BE" after 4 ns;

sel <= B"00" after 1 ns,
B"01" after 2 ns,
B"10" after 3 ns,
B"11" after 4 ns;
wait;
end process;
end mux;

When I try to compile my program into a file called mux.vhd in the work
library it gives me errors at all lines where I use std_logic_vector
saying that it is an unknown identifier though I have included the
library and the needed package in the code above.Alongwith that it says
that I should always end a component declaration with a "end component
component_name" instead of just "end component_name" which is perfectly
legal I guess isn't it?

After that when I replace the line containing ' c <= (OTHERS => 'Z');
' with ' c <= 'Z'; ' it says that "Enumeration literal 'Z' is not
of type std_logic_vector.". And the error about the ending of the
component part doesn't come in the picture.

Hoping to hear from you,

Aijaz Baig.

 

[Peter]

(e-mail address removed) skrev:

entity tb_mux is
end entity;

component muxc is
port(a,b : in std_logic_vector(7 downto 0);
sel : in std_logic_vector(1 downto 0);
c : out std_logic_vector(7 downto 0));
end muxc;

Hi,

Each entity declaration must be preceded with a "Library" and "Use"
clause.

A component declaration is terminated with END COMPONENT and an
optional component identifier.

/Peter

 

[aijazbaig1]

Hello Peter.
I made the corrections as suggested. I used the library and the use
clauses before each entity declaration and also took care of the
component error as mentioned.
Now the only error I get is that it says that
"Enumeration literal 'Z' is not of type std_logic_vector." and the
compiler exits. The 'others' clause assigns each element of the array
to Z which is of type std_logic and the array C is indeed an array of
std_logic elements. So why is the compiler flagging an error.

Hope to hear from you.
Best Regards,
Aijaz Baig.

 

[Ajeetha]

Hi,
You mentioned in your first post:


That's incorrect, you would require:

c <= (others => 'Z')

With that VCSMX compiles your code (with slight typo and Mike's
suggestions);

HTH
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
h**p://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

 

[aijazbaig1]

Hello.
Heres a working code for the above program:
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity mux is
port(a,b:IN std_logic_vector(7 downto 0);
sel:IN std_logic_vector(1 downto 0);
c : OUT std_logic_vector(7 downto 0));
end mux;

architecture example of mux is
begin
process(a,b,sel)
begin
if(sel = "00") then
c <= "00000000";
elsif (sel = "01") then
c <= a;
elsif (sel = "10") then
c <= b;
else
c <= (OTHERS => 'Z');
end if;
end process;
end example;

----------------------------------------------------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;

entity tb_mux is
end entity;

architecture testbench of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel : std_logic_vector(1 downto 0);
component mux is
port(a,b : in std_logic_vector(7 downto 0);
sel : in std_logic_vector(1 downto 0);
c : out std_logic_vector(7 downto 0));
end component;

begin
M1:mux port map(a,b,sel,c);
process
begin
a <= X"11" after 1 ns,
X"AF" after 2 ns,
X"BB" after 3 ns,
X"6F" after 4 ns;

b <= X"01" after 1 ns,
X"2F" after 2 ns,
X"3C" after 3 ns,
X"BE" after 4 ns;

sel <= B"00" after 1 ns,
B"01" after 2 ns,
B"10" after 3 ns,
B"11" after 4 ns;
wait;
end process;
End testbench.
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
However there are a few things in this program that I don't understand.

First of all, the line where I associated the component
muxc with the entity mux has been removed. Inspite of that it worked.
Is it because the
component and entity name were the same, i.e. in thsi case both of them
are called mux? Is this a kind of a rule wherein if the names of the
component and the entity are the same then we need not explicitly link
the entity with the given component?
Does the name of the port pins also have to be the same for the
compiler to detect which entity maps to which component or vice-versa?

Secondly when we use the port map clause the arguments are actually
passed and substituted position-wise in the component isn't it?

Well this is kind of confusing. Please elaborate.

Hoping to hear from you soon,
Aijaz Baig.

 

[Ajeetha]

Hi,

Hello.

First of all, the line where I associated the component
muxc with the entity mux has been removed.

This is called "default binding", read VHDL FAQ @
www.vhdl.org/comp.lang.vhdl

Inspite of that it worked.
Is it because the
component and entity name were the same, i.e. in thsi case both of them
are called mux?

I don't believe that's the correct reason, in VHDL the component and
entity must have the same name - IIRC (didn't check a book/LRM).

Is this a kind of a rule wherein if the names of the
component and the entity are the same then we need not explicitly link
the entity with the given component?

If there is only one mux available in your entire set of libraries
(in this case perhaps only one lib), then it is bound as "default".

Does the name of the port pins also have to be the same for the
compiler to detect which entity maps to which component or vice-versa?

Entity and component declarations have to be 100% matching.

Secondly when we use the port map clause the arguments are actually
passed and substituted position-wise in the component isn't it?

No that's a choice and IMHO a bad style. Use named port map as in:

M1:muxc port map(a => a,b => b,sel => sel,c => c);

Yes it is more typing work, but Emacs + VHDL Mode does this
automatically for you!!

Well this is kind of confusing. Please elaborate.

HTH,
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

 

[Andy]

You can bypass all this component/entity binding hogwash if you
directly instantiate entities:

M1: entity work.mux(rtl) port map (....

You also don't need the component declaration any more either.

The only time I have to use components is when I'm instantiating a
black box in synthsizable code. In this case, the only
entity/architecture that exists is a non-synthesizable, gate level
simulation model, that is not what I want the synthesis tool to see.
Using the default binding for synthesis and a either the default
binding or a configuration for simulation just "makes it work" for each
tool, without having to change the vhdl source.

Andy

 

[KJ]

You can bypass all this component/entity binding hogwash if you
directly instantiate entities:

M1: entity work.mux(rtl) port map (....

You also don't need the component declaration any more either.

The only time I have to use components is when I'm instantiating a
black box in synthsizable code.

I'd take it even further and say that use of component declarations
should generally be discouraged (except for the above mentioned black
box) because it leads to harder to maintain code. When you do create a
component, at best, the component declaration is included in a package
physically in the exact same file as the entity and whenever one makes
a change to either the component or the entity one remembers to
copy/paste the generics/signal list from one to the other.

At it's best, making the component declaration is an (unneccessary)
exercise in copy/pasting. At it's worst, you find multiple component
declarations strewn about wherever the component happens to be
instantiated which means any change to the generics/signals means
hunting down those instances since each now out of date file will still
compile just fine and it won't be until you go to start the simulation
that the complaint is made about the differences. Using direct entity
instantiation, the error message is clearer and comes right out when
you compile.

My 2 cents for the day.

KJ

 

[Mike Treseler]

I'd take it even further and say that use of component declarations
should generally be discouraged (except for the above mentioned black
box) because it leads to harder to maintain code.

And let all the people say, Amen.

-- Mike Treseler

 

[Mike Treseler]

You can bypass all this component/entity binding hogwash if you
directly instantiate entities:

M1: entity work.mux(rtl) port map (....

You also don't need the component declaration any more either.

The only time I have to use components is when I'm instantiating a
black box in synthsizable code. In this case, the only
entity/architecture that exists is a non-synthesizable, gate level
simulation model, that is not what I want the synthesis tool to see.

I agree.

Using the default binding for synthesis and a either the default
binding or a configuration for simulation just "makes it work" for each
tool, without having to change the vhdl source.

Do you mean -87 tools that can't do direct instances?

-- Mike Treseler
-- bypass component mismatch:
-- i2: some_ent port map(
i2: entity work.some_ent port map(

 

[Andy]

Do you mean -87 tools that can't do direct instances?

No, I mean you cannot use direct entity instancing for a black box in
synthesis, no matter whether the tool is -93 compliant or not (it would
not be legal vhdl unless you had already analyzed the entity and
architecture into the library). You have no choice but to use a
component instance, and let the synthesis tool assume it is a black
box.

Then the only way to get the same exact code to simulate is with either
a default binding (i.e. analyze into the same library an additional
file for simulation only that declares the entity and a simulation
architecture for it), and/or use a configuration to explicitly bind it
to a simulation entity/architecture.

The architecture specification on directly instantiated entities is
optional. If left off, it assumes the most recently analyzed
architecture as of elaboration time.

Note that directly instantiating entities and/or architectures does
force the entities and/or arhitectures to be analyzed before the
architecture that instantiates them is analyzed. This is not so with
components. Small (tiny) price to pay...

Andy

 

[Mike Treseler]

No, I mean you cannot use direct entity instancing for a black box in
synthesis, no matter whether the tool is -93 compliant or not

OK, I see. You were talking about the same case --
a default binding to a non-inferable vendor netlist
like a PLL. Yes, there's no way around
an indirect instance it that case.

Too bad some designers suffer through the same process
for "wizardly" counters and muxes.

Note that directly instantiating entities and/or architectures does
force the entities and/or architectures to be analyzed before the
architecture that instantiates them is analyzed. This is not so with
components.

Yes, I guess there has to be *something*
in the plus column for components.

Small (tiny) price to pay...

Yes. No price at all if I have a makefile generator
like vhdl-mode. Just "make" for simulation,
or "make clean; make" for an ordered synthesis file list.

But even if I were without emacs, I would rather
write a "compile.do" than suffer long term component
maintenance.

Thanks for the posting.

-- Mike Treseler

 

[Andy]

Too bad some designers suffer through the same process
for "wizardly" counters and muxes.

Yeah, the simple things that some folks will rely on a wizard for, or
almost worse, write it themselves in an entity/architecture all its
own, never cease to amaze me. I wonder if that comes from reading
examples in textbooks that are necessarily brief, just to get the point
across. But the examples are not meant to imply that simple counters,
etc. are the upper limit of complexity for a single entity with no
further hierarchy.

There are some tools out there (Cadence NC-Sim is one) that have an
"order independent compilation" switch, in which they pre-parse the
file(s), and then compile the units in the correct order, even
reordering units in the same file if necessary. I wish all of them
would do it...

On the other hand, there are some tools, Synopsys VCS-MX among them,
that can't handle direct entity instantiations in some cases (like
sometimes inside a generate loop) yet either. Hey, its a new feature
that was only introduced 13 years ago.

Andy

 

[Mike Treseler]

There are some tools out there (Cadence NC-Sim is one) that have an
"order independent compilation" switch, in which they pre-parse the
file(s), and then compile the units in the correct order, even
reordering units in the same file if necessary.

Good show Cadence.

On the other hand, there are some tools, Synopsys VCS-MX among them,
that can't handle direct entity instantiations in some cases (like
sometimes inside a generate loop) yet either. Hey, its a new feature
that was only introduced 13 years ago.

Synopsys has all its bets on Verilog and SystemVerilog.
But I will add that to my list of reasons
I don't use "generate"

-- Mike Treseler

ps: my spell checker just advised:
SystemVerilog - consider "mysteriously"

 

[Andy]

Synopsys has all its bets on Verilog and SystemVerilog.
But I will add that to my list of reasons
I don't use "generate"

How do you get along without generate loops?!

I'd rather get along without Synopsys...

Andy

 

[Mike Treseler]

How do you get along without generate loops?!

I declare a variable array/structure and
update it with a for loop like this:
http://home.comcast.net/~mike_treseler/no_gen.vhd

I'd rather get along without Synopsys...

They're number one in asics, but number
ten in vhdl support. Last I heard dc can't
even unwind my parameterless procedures
as in the example above.

Maybe someday fpgas will be cheap enough
that it won't matter ...

-- Mike Treseler