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

[Analog Guy]

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]

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" <analog_guy@hotmail.com> wrote in message
news:6laPb.11405$U77.718889@news20.bellglobal.com...

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.

 

[Tim Hubberstey]

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

 

[Jim Lewis]

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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Mike Treseler]

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

 

[Jim Lewis]

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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Allan Herriman]

On Tue, 20 Jan 2004 18:35:15 GMT, Tim Hubberstey <bogus@bogusname.com>
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.

 

[Ken]

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

 

[Mike Treseler]

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