Packages, Components ??? How to organize a design ???

Discussion in 'VHDL' started by Analog Guy, Jan 20, 2004.

  1. Analog Guy

    Analog Guy Guest

    HI,

    Our company standard is HDL Designer, and up to now, I have basically been
    using blocks to hierarchically define my design.

    I do see some instances where a component would be useful, especially where
    a
    piece of code is repeated alot. What is the proper way to use components?
    Right
    now, I created a component in HDL Designer, and it appears in my design
    library
    as a separate design unit.

    First of all, is this ok, or should all components exist in a separate
    library. Secondly,
    should all components be placed in a package instead or just left on their
    own as
    separate design units?

    In addition, for my testbench (my first one!), some other designers have
    provided me
    with models (SRAM) with full entities and architectures ... do I convert
    these to components
    or leave them as is? As well, I will be using SmartModels. For proper
    design
    management, how do I organize these? Do I create a package in a separate
    library or just make
    components out of everything?

    My only problem with making components in HDL Designer, is that it seems to
    only make a copy
    of the source (stripping out the entity to make the component symbol).
    Hence, it is keeping two
    copies of the same code that are not related, i.e. if I make a change to the
    code in the component
    architecture, it is not reflected in the original source code (with entity
    and architecture) and
    vice-versa.

    Sorry for be long winded ... I'm just a bit confused. Thanks for your
    help.
    Analog Guy, Jan 20, 2004
    #1
    1. Advertising

  2. Analog Guy

    matt north Guest

    Analog Guy,

    I have had no experience of HDL Designer, but as for good VHDL Design
    techniques i have always split my code into blocks.
    The blocks are realised in VHDL as seperate enities which are eventually
    instatiated as components in the top level design, i find using components
    always simplifies the testing process.

    Each component is a seperate design unit (entity and architecture) but the
    top level design which instantiates it describes how the various components
    are wired together. Think of the top level design as the PCB to which your
    components will fit.

    I haven't heard of components ever being placed in a package (others may
    disagree).
    Packages are commonly used to hold subprograms i.e. functions and
    procedures.

    As for the rest it sounds HDL Designer specific, so i couldn't possibly
    comment!

    Matt

    "Analog Guy" <> wrote in message
    news:6laPb.11405$...
    > HI,
    >
    > Our company standard is HDL Designer, and up to now, I have basically been
    > using blocks to hierarchically define my design.
    >
    > I do see some instances where a component would be useful, especially

    where
    > a
    > piece of code is repeated alot. What is the proper way to use components?
    > Right
    > now, I created a component in HDL Designer, and it appears in my design
    > library
    > as a separate design unit.
    >
    > First of all, is this ok, or should all components exist in a separate
    > library. Secondly,
    > should all components be placed in a package instead or just left on their
    > own as
    > separate design units?
    >
    > In addition, for my testbench (my first one!), some other designers have
    > provided me
    > with models (SRAM) with full entities and architectures ... do I convert
    > these to components
    > or leave them as is? As well, I will be using SmartModels. For proper
    > design
    > management, how do I organize these? Do I create a package in a separate
    > library or just make
    > components out of everything?
    >
    > My only problem with making components in HDL Designer, is that it seems

    to
    > only make a copy
    > of the source (stripping out the entity to make the component symbol).
    > Hence, it is keeping two
    > copies of the same code that are not related, i.e. if I make a change to

    the
    > code in the component
    > architecture, it is not reflected in the original source code (with entity
    > and architecture) and
    > vice-versa.
    >
    > Sorry for be long winded ... I'm just a bit confused. Thanks for your
    > help.
    >
    >
    matt north, Jan 20, 2004
    #2
    1. Advertising

  3. matt north wrote:
    >
    > I haven't heard of components ever being placed in a package (others may
    > disagree).
    > Packages are commonly used to hold subprograms i.e. functions and
    > procedures.


    Placement of component *declarations* in packages is extremely common
    and is the standard way of gaining access to library primitives. Think
    of the "unisim" and "simprims" packages for Xilinx, for instance.

    It also has an advantage in cases where you are going to instantiate a
    component in more than one file as it removes one (or more) of the
    places where changes must be made if you change the port structure of
    the instantiated component. Without a package, you must change both the
    component declaration and the component instantiation in each file. With
    a package, you change the package component declaration and the
    instantiations only. For components that are only instantiated once,
    there is no advantage. You may choose to move the declaration into a
    package anyway, for consistency. I personally find that it is only worth
    the extra work of making a package if the component is used in several
    places or if design reusability is a consideration.
    --
    Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
    Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
    Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
    Tim Hubberstey, Jan 20, 2004
    #3
  4. Analog Guy

    Jim Lewis Guest

    Analog Guy,

    > Our company standard is HDL Designer, and up to now, I have basically been
    > using blocks to hierarchically define my design.
    > I do see some instances where a component would be useful, especially where
    > a piece of code is repeated alot.

    What do you mean by block? Is it a VHDL block statement or
    a hierarchical block in a block diagram tool that is realized
    as a separate entity + architecture?

    In VHDL a component is an indirect means of referencing a
    VHDL entity and architecture pair in a design. One way
    to think of this is that a component instance is very
    similar to a program call.

    It sounds like HDL Designer is using the word component
    to mean the same as an entity/architecture pair.

    > What is the proper way to use components?
    > Right now, I created a component in HDL Designer, and it appears in
    > my design library as a separate design unit.
    >
    > First of all, is this ok, or should all components exist in a separate
    > library.

    This is ok.

    I like to have one library per chip in my design.
    I also like to have a separate library for any IP
    (purchased code) that I may be using.
    When I have multiple chips, I put the chips in separate
    named libraries (lib_chipname) and then put the
    testbench in the work library (ease of simulation).


    > Secondly, should all components be placed in a package
    > instead or just left on their own as separate design units?

    Entities and architectures go in a separate design unit
    (and this seems to be what HDL Designer is calling a component).
    Component declarations typically go in the architecture
    declaration region of the design that references them.

    Note since you are using graphical entry tool, the following
    is an unnecessary step for you. Your graphical entry tool
    should (and probably does) manage all of the tedious
    aspects of connecting components. When connecting components
    with text, some don't like cluttering an architecture declaration
    with the component declarations. As a result, they put the
    component declaration in a package and reference the
    package in the architecture declaration region instead.
    This is an advanced step that you don't need to do.
    The most effective way I have used this is to put a single
    component declaration in a package by itself (and the
    package to be named comp_entityname). Then write a
    script that can generate the package + component declaration
    from the entity declaration.


    Small, non-registered based repeated code (combinational logic)
    can be represented by a subprogram (procedure or function).
    To make these usable by multiple designs, they should go in a
    package.


    > In addition, for my testbench (my first one!), some other designers
    > have provided me with models (SRAM) with full entities and
    > architectures ... do I convert these to components
    > or leave them as is?

    You leave the entity and architectures as is. Compile them into
    a library. Then you reference them as components. Component
    names get associated with entities as the design is being built.

    > As well, I will be using SmartModels. For proper
    > design management, how do I organize these? Do I create a package
    > in a separate library or just make components out of everything?

    Compile these into a separate library.
    Check the packages they provide as they may have provided a
    package with a component declaration.


    > My only problem with making components in HDL Designer, is that
    > it seems to only make a copy of the source (stripping out the
    > entity to make the component symbol).

    It seems there is may be a difference between the terminology
    that HDL designer is using and the terminology VHDL uses.
    My recommendation is that you do the HDL Designer tutorial
    and read parts of the user guide to get oriented. Note,
    there is probably a process for bringing an existing
    entity/architecture into your hdl designer project (often
    under the title of importing).

    If the VHDL parts are giving you difficulty, you will
    benefit from a class. A VHDL training class will save you
    net time as will not have to spend a great deal of time
    struggling to find answers to basic questions.

    We (SynthWorks) have a session of our Comprehensive
    VHDL Introduction comming up in Orlando, FL on
    Feb 16-19. Details are at:
    http://www.synthworks.com/public_vhdl_courses.htm

    Best Regards,
    Jim Lewis

    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Jan 20, 2004
    #4
  5. Jim Lewis wrote:

    > Small, non-registered based repeated code (combinational logic)
    > can be represented by a subprogram (procedure or function).


    A function call gets a value, while
    a procedure call gets a block of sequential statements.
    Such calls can be made from clocked or unclocked processes.

    -- Mike Treseler
    Mike Treseler, Jan 20, 2004
    #5
  6. Analog Guy

    Jim Lewis Guest

    Jim Lewis wrote:
    >> Small, non-registered based repeated code (combinational logic)
    >> can be represented by a subprogram (procedure or function).



    Mike Treseler wrote:
    > A function call gets a value, while
    > a procedure call gets a block of sequential statements.
    > Such calls can be made from clocked or unclocked processes.

    I agree.

    My basic point is that registers can be
    implied internally to procedures, however, this coding
    techinque is not fully portable. It will be when
    1076.6-2004 is implemented by all the synthesis tool
    vendors. When this is implemented, the easiest way to
    get it right is to use an "if" style register implication.
    See the HDLCon (now DVCon) paper on "Extensions to the VHDL RTL
    Synthesis Standard" at:
    http://www.synthworks.com/papers/index.htm
    Note I am doing an new paper on this standard that will be
    available sometime in March.

    As Mike noted, you can call a function or procedure that
    creates combinational logic from a clocked process to
    yield registers and combinational logic. An easy way to
    visualize this is anywhere you can use an "AND" operator,
    you can use a function call (operators are implemented as
    functions).

    YRegProc : process
    begin
    wait until rising_edge(Clk) ;
    Y <= A and B ;
    end process ;


    By the way, if read the above mentioned paper(s), and
    see something you like, be sure to ask your synthesis
    tool vendor to implement it. This is important
    to them as supporting standards is a significant
    investment and they can't afford to do it if you are
    not interested in the standard.

    Regards,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Jan 20, 2004
    #6
  7. On Tue, 20 Jan 2004 18:35:15 GMT, Tim Hubberstey <>
    wrote:

    >matt north wrote:
    >>
    >> I haven't heard of components ever being placed in a package (others may
    >> disagree).
    >> Packages are commonly used to hold subprograms i.e. functions and
    >> procedures.

    >
    >Placement of component *declarations* in packages is extremely common
    >and is the standard way of gaining access to library primitives. Think
    >of the "unisim" and "simprims" packages for Xilinx, for instance.
    >
    >It also has an advantage in cases where you are going to instantiate a
    >component in more than one file as it removes one (or more) of the
    >places where changes must be made if you change the port structure of
    >the instantiated component. Without a package, you must change both the
    >component declaration and the component instantiation in each file. With
    >a package, you change the package component declaration and the
    >instantiations only. For components that are only instantiated once,
    >there is no advantage. You may choose to move the declaration into a
    >package anyway, for consistency. I personally find that it is only worth
    >the extra work of making a package if the component is used in several
    >places or if design reusability is a consideration.



    All of this becomes unnecessary if you use entity instantiation rather
    than component instantiation.

    For the last few years, I've only used component instantiation for
    unisim components and the occasional black box.

    Regards,
    Allan.
    Allan Herriman, Jan 21, 2004
    #7
  8. Analog Guy

    Ken Guest

    > All of this becomes unnecessary if you use entity instantiation rather
    > than component instantiation.
    >
    > For the last few years, I've only used component instantiation for
    > unisim components and the occasional black box.


    Whats the difference between entity and component instantiation?

    Cheers,

    Ken
    Ken, Jan 21, 2004
    #8
  9. Ken wrote:
    >>All of this becomes unnecessary if you use entity instantiation rather
    >>than component instantiation.
    >>
    >>For the last few years, I've only used component instantiation for
    >>unisim components and the occasional black box.

    >
    >
    > Whats the difference between entity and component instantiation?


    See:
    "Instantiating an entity" in
    http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#default_binding

    -- Mike Treseler
    Mike Treseler, Jan 22, 2004
    #9
    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. Ravi Sankar

    Organize projects & directories

    Ravi Sankar, Aug 28, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    343
    Ravi Sankar
    Aug 28, 2003
  2. Paul  Smith
    Replies:
    0
    Views:
    717
    Paul Smith
    Nov 18, 2003
  3. Mickey Segal
    Replies:
    0
    Views:
    854
    Mickey Segal
    Feb 2, 2004
  4. David Lyon
    Replies:
    19
    Views:
    554
    David Lyon
    Apr 24, 2009
  5. Ian
    Replies:
    3
    Views:
    155
Loading...

Share This Page