Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Packages, Components ??? How to organize a design ???

Reply
Thread Tools

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

 
 
Analog Guy
Guest
Posts: n/a
 
      01-20-2004
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.


 
Reply With Quote
 
 
 
 
matt north
Guest
Posts: n/a
 
      01-20-2004
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" <(E-Mail Removed)> wrote in message
news:6laPb.11405$(E-Mail Removed). ..
> 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.
>
>



 
Reply With Quote
 
 
 
 
Tim Hubberstey
Guest
Posts: n/a
 
      01-20-2004
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
 
Reply With Quote
 
Jim Lewis
Guest
Posts: n/a
 
      01-20-2004
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 (E-Mail Removed)
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      01-20-2004
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


 
Reply With Quote
 
Jim Lewis
Guest
Posts: n/a
 
      01-20-2004
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 (E-Mail Removed)
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

 
Reply With Quote
 
Allan Herriman
Guest
Posts: n/a
 
      01-21-2004
On Tue, 20 Jan 2004 18:35:15 GMT, Tim Hubberstey <(E-Mail Removed)>
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.
 
Reply With Quote
 
Ken
Guest
Posts: n/a
 
      01-21-2004
> 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


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      01-22-2004
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/F...efault_binding

-- Mike Treseler

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Way to Organize ACL on PIX Matt Cisco 8 01-07-2007 07:33 AM
linking web controls and components at design time in asp 2.0 Lucio Mania ASP .Net Building Controls 0 12-22-2005 06:20 PM
SWING components adjustment in different resolutions - Should show scrollbars less than 800X600 and expand components over this resolution Bluetears76 Java 1 07-01-2004 09:01 PM
Can Choice components respond to keyboard input like HTML Choice components? Mickey Segal Java 0 02-02-2004 10:59 PM
Organize projects & directories Ravi Sankar ASP .Net 2 08-28-2003 07:44 AM



Advertisments