package, component, entity ......

[u_stadler@yahoo.de]

hi

i'm just beginning to learn vhdl and im a little bit confused now. i
know thet i need an entity to define my interface to the outside world
and that the coresponding arciteture implements the behavior. my
question now is how to spilt up a big project properly. i'm from the
c/c++ side an there i would have multiple *.c and *.h files and use
#include to work with them.
but how do i do this in vhdl.
whats the difference between a libary and a package, or a component.
how are they properly used?
say for example i habe a lookup table in one file with an 8 bit wide
input and 8 bit wide output and i want to use it in another file. would
the lookup table be a package or component?
i have a small vhdl reference ("VHDL Kompakt") but it didn't clear
things up for me. does anyone know a good (and perhaps free) online
tutorial?

thanks

Urban

 

[Hubble]

If you have a chip design, you will probably
define an *entity* with the pins of the chip as ports.

This will contain at least one architecture, which could be a
behavioural model or synthesizeable code or a netlist depending on
your needs. You can define any number of architectures for a given
entity.

Most likely, the top architecture of your chip will be structural
(architecture "struct") and contain *components* of the next level sub
modules. components are assigned to entities of the sub modules, the
*ports* connected through *signals* via *port maps*. Each such entity
can also have several architectures, which can also be a struct. Each
entity can be used several times as component.

You can go further like this. At the lower levels, there are components
which can be instantiated by entities supplied by third parties. Your
entity/architectures are in *library* work while you develop your
models. The components (say flip flops, gates, i/o drivers) are in a
vendor library.

At the lower levels, architectures can be defined by concurrent
statements. One such concurrent statement is a process, which contains
sequential statements like in ordinary programming languages. These
processes can react on signal changes (the same signals as in the
structures) and drive other signals creating events.

libraries contain components as descriped previously. They can also
contain *packages*, which are collections of utitily functions,
procedures and constants making your life easier.

HTH
Hubble.

 

[Jonathan Bromley]

On 2 Aug 2005 03:28:31 -0700, "u_stadler@yahoo.de"
<u_stadler@yahoo.de> wrote:

i'm just beginning to learn vhdl and im a little bit confused now.

Do you know Ada? The package/library concepts are much closer to
Ada than they are to C.

know thet i need an entity to define my interface to the outside world
and that the coresponding arciteture implements the behavior. my
question now is how to spilt up a big project properly. i'm from the
c/c++ side an there i would have multiple *.c and *.h files and use
#include to work with them. but how do i do this in vhdl.

There's no #include. Everything is compiled separately.

whats the difference between a libary and a package, or a component.

ummmm, category error

a LIBRARY is some structure, typically just a directory with a
bunch of object files in it, but it's tool dependent and you are
not supposed to ask. A library is the place where your tool puts
the result of a compilation, and the place whence it extracts that
result when it needs it.

a PACKAGE is one of five different kinds of thing ("design unit",
in VHDL jargon) that can be compiled into a library. The special
feature of a package is that its contents can be imported into
other design units by means of a USE CLAUSE. By far the most
common example is the way you get hold of the definitions of
"std_logic" and its related subprograms, literal values and so on...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
library IEEE; -- tell compiler that IEEE is the name of
-- a library that it should go and find

use IEEE.std_logic_1164.all; -- tell compiler to import all the named
-- things (types, constants, subprograms)
-- previously compiled from the package
-- std_logic_1164 into the library IEEE

entity My_Design is -- start defining your own stuff
port (a: in std_logic; -- compiler now knows about "std_logic"
... -- because its definition was in the
-- std_logic_1164 package
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The other kinds of design unit are...

package body the implementation part of a package, containing the
bodies of all subprograms declared in the package

entity defines the interface to a design module

architecture implementation of a design module

configuration describes which architectures should be plugged-in
for each instance of given entities in a design

However, there's an additional level of difficulty that VHDL
introduces to facilitate clean top-down design: COMPONENTS. A
component is something that describes the interface of an
entity. When you want to instantiate an entity in your code,
and the entity already exists in a library, you can do it
directly:

MyInstanceName: entity SomeLibrary.SomeEntity(SomeArchitecture)
port map (....);

In this case, the compiler can look at the entity (which already
has been compiled into the library) and check that its ports are
being hooked up correctly. But suppose you haven't yet designed
the lower-level entity? You can't just leave a hole in your
design. So instead you create a component declaration, which
looks almost exactly the same as an entity but IT IS NOT A
DESIGN UNIT - it's just a declaration. You can write it out
longhand in the architecture....

architecture A of SomeTopLevelEntity is
component SomeDesign is
port(... -- port list, same as the entity will have
end component;
begin
MyInstanceName: SomeDesign port map (...);

and now the compiler knows the shape of this entity, even though
it doesn't exist yet. But if you are going to use the lower-
level component in more than one architecture, it will be both
tedious and error-prone to write out the component declaration
in each architecture. So you put the component declaration in
a package, compile the package and then "Use" (import) the
package into each architecture that needs that component.

Finally, when you have at last designed ALL the pieces, you
will need to stitch together the top-level entity. But it
contains instances of components, which now need to be filled-in
with real modules - entity/architecture pairs. There are default
rules for how to do that automatically, but if you want to get
explicit control you need a CONFIGURATION. Configurations describe
which entities and architectures should be plugged in for each
component instance in the design.

say for example i habe a lookup table in one file with an 8 bit wide
input and 8 bit wide output and i want to use it in another file. would
the lookup table be a package or component?

It certainly would not be a package. It might be a constant, which
could be one of many things defined in a package. Alternatively,
perhaps your lookup table has been created as an entity/architecture
pair, in which case it would be compiled as those two design units
and you would probably need a component declaration to match it.
That component declaration might be in a package, or it might be
written-out explicitly in the design that instantiates the lookup
table.

Any good VHDL textbook (see this group's FAQ for a list) will
describe all these ideas in more detail.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[u_stadler@yahoo.de]

thanks that cleared things up quite a bit!!
Urban