package, component, entity ......

Discussion in 'VHDL' started by u_stadler@yahoo.de, Aug 2, 2005.

  1. Guest

    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
     
    , Aug 2, 2005
    #1
    1. Advertising

  2. Hubble Guest

    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.
     
    Hubble, Aug 2, 2005
    #2
    1. Advertising

  3. On 2 Aug 2005 03:28:31 -0700, ""
    <> 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:
    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.
     
    Jonathan Bromley, Aug 2, 2005
    #3
  4. Guest

    thanks that cleared things up quite a bit!!
    Urban
     
    , Aug 3, 2005
    #4
  5. vipinlal

    Joined:
    Feb 25, 2010
    Messages:
    38
    check these links out.. even though they are not a complete guide to vhdl,i believe it will be helpful for beginners..nice ppt man..
    vhdlguru.blogspot.com
     
    vipinlal, Mar 4, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sven Heithecker
    Replies:
    2
    Views:
    664
    Ralf Hildebrandt
    Aug 2, 2004
  2. Samuel van Laere

    Entity Name or Entity Number?

    Samuel van Laere, Feb 24, 2007, in forum: HTML
    Replies:
    4
    Views:
    1,742
    Jukka K. Korpela
    Feb 24, 2007
  3. markla
    Replies:
    1
    Views:
    580
    Steven Cheng
    Oct 6, 2008
  4. Norm
    Replies:
    3
    Views:
    2,880
  5. ThatsIT.net.au

    Entity, problem with entity key

    ThatsIT.net.au, Sep 6, 2009, in forum: ASP .Net
    Replies:
    1
    Views:
    1,244
    ThatsIT.net.au
    Sep 7, 2009
Loading...

Share This Page