clarification on generics

[Jim Lewis]

Why wouldn't that method be shown more often?

Tradition.

Tool support. Last I checked it is not supported
by Synopsys. Anyone know?

Is it working on all/most FPGA tools: Altera, Xilinx, Synplicity,
Mentor?

Cheers,
Jim

 

[MattLFerraro]

Hello,

I'm looking for clarification on a few points about using generics

1) In the component declaration, do all generics need to be defined?
For example; my entity declaration has 30 generics - and only want to
modify one in the component instantiation. So, can i just include
that one generic definition in the component declaration?

2) If I had a generic DATA_WIDTH : integer = 32 defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined? Does the
components default assignment of the generic override the entities
default assignment of the generic?

Thanks,

Matt

 

[KJ]

On Feb 11, 11:10 am, MattLFerraro <MattLFerr...@gmail.com> wrote:

Hello,

I'm looking for clarification on a few points about using generics

1) In the component declaration, do all generics need to be defined?
For example; my entity declaration has 30 generics - and only want to
modify one in the component instantiation.  So, can i just include
that one generic definition in the component declaration?

As long as the other 29 generics have default values defined then yes
you only need to set the entry for the one that you want to modify.

2) If I had a generic DATA_WIDTH : integer = 32  defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined?  Does the
components default assignment of the generic override the entities
default assignment of the generic?

I don't know...but the reason for not knowing is that I don't use
component definitions instead I use direct entity instantiation.
Maintenance of components definitions is a waste of time and prone to
sometimes subtle, sometimes not so subtle errors as well as
uncertainties in situations like the one you mention.

In any case, having ANY differences between the component definition
and the entity definition is just asking for trouble, there is no good
reason for them to have any differences...which leaves 'OOPS!' and !@#
%&(! as the reasons why they might be...which is why direct entity
instantiation is the better way to go.

Example:
U1 : my_widget generic map(...) port map(...); -- Using components
U1 : entity work.my_widget generic map(...) port map(...); -- Using
DEI

The only time you 'have' to use components is when the thing you are
instantiating is some form of 'black box' (i.e. you don't have the
source, only a pre-compiled something) that you are using in your
design. However in that situation, whoever it is that you got the
'black box' component from is not giving you the entity or
architecture in an editable form so you don't need to maintain that
code to insure that component/entity match.

Kevin Jennings

 

[MattLFerraro]

Thanks for the feedback. I didn't know you could instantiate
components that way.

I have not seen any examples or reference designs from FPGA vendors
that use that method. It is more like Verilog. And less time
consuming. Why wouldn't that method be shown more often?

On second glance; that method has always been described on my VHDL
quick ref card.

LABEL: COMPID
[[generic map ( {GENID => expr,} )]
port map ( {PORTID => SIGID,} )];

LABEL: entity [LIBID.]ENTITYID [(ARCHID)]
[[generic map ( {GENID => expr,} )]
port map ( {PORTID => SIGID,} )];

LABEL: configuration [LIBID.]CONFID
[[generic map ( {GENID => expr,} )]
port map ( {PORTID => SIGID,} )];

On Feb 11, 12:00 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Feb 11, 11:10 am, MattLFerraro <MattLFerr...@gmail.com> wrote:

Hello,

I'm looking for clarification on a few points about using generics

1) In the component declaration, do all generics need to be defined?
For example; my entity declaration has 30 generics - and only want to
modify one in the component instantiation. So, can i just include
that one generic definition in the component declaration?

As long as the other 29 generics have default values defined then yes
you only need to set the entry for the one that you want to modify.

2) If I had a generic DATA_WIDTH : integer = 32 defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined? Does the
components default assignment of the generic override the entities
default assignment of the generic?

I don't know...but the reason for not knowing is that I don't use
component definitions instead I use direct entity instantiation.
Maintenance of components definitions is a waste of time and prone to
sometimes subtle, sometimes not so subtle errors as well as
uncertainties in situations like the one you mention.

In any case, having ANY differences between the component definition
and the entity definition is just asking for trouble, there is no good
reason for them to have any differences...which leaves 'OOPS!' and !@#
%&(! as the reasons why they might be...which is why direct entity
instantiation is the better way to go.

Example:
U1 : my_widget generic map(...) port map(...); -- Using components
U1 : entity work.my_widget generic map(...) port map(...); -- Using
DEI

The only time you 'have' to use components is when the thing you are
instantiating is some form of 'black box' (i.e. you don't have the
source, only a pre-compiled something) that you are using in your
design. However in that situation, whoever it is that you got the
'black box' component from is not giving you the entity or
architecture in an editable form so you don't need to maintain that
code to insure that component/entity match.

Kevin Jennings

 

[Mike Treseler]

MattLFerraro wrote:

I didn't know you could instantiate
components that way.

Yes.
The vhdl language has no marketing department.

I have not seen any examples or reference designs from FPGA vendors
that use that method.

The FPGA vendors would prefer that I
instance their black box netlist rather than
portable code. This translates
into an unbound component instance 'wizard' synthesis
and a purposely non-synthesizable simulation model.
This causes no end of confusion and questions to
this newsgroup.

To their credit, the vendors do document
some synthesis templates in but I have never seen
a direct instance example.

Here two that I dug up:

From http://home.comcast.net/~mike_treseler/oe_demo.vhd:

oe_demo_1 : entity work.oe_demo
port map (reset => reset_s, -- [in]
clock => clock_s, -- [in]
data => data_s, -- [inout]
ready => ready_s, -- [out]
oe => oe_s); -- [in]

From: http://home.comcast.net/~mike_treseler/test_uart.vhd

dut : entity work.uart
generic map (char_len_g => tb_char_g, -- for vsim cmd line
tic_per_bit_g => tb_tics_g)
port map (
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback dest
serialOut => serialOut_s -- [out]-- by uut, loopback src
);

It is more like Verilog. And less time consuming.

Exactly

Why wouldn't that method be shown more often?

Tradition.

-- Mike Treseler

 

[Paul Uiterlinden]

KJ wrote:

2) If I had a generic DATA_WIDTH : integer = 32 defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined? Does the
components default assignment of the generic override the entities
default assignment of the generic?

Yes indeed, that is how it works.

The only time you 'have' to use components is when the thing you are
instantiating is some form of 'black box' (i.e. you don't have the
source, only a pre-compiled something) that you are using in your
design.

As long as there is a compiled entity in a library, it should not matter how
the instantiation is done. I would expect that both direct- and component-
instantiation work.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[Andy]

On Feb 12, 11:15 am, Mike Treseler <mike_trese...@comcast.net> wrote:

MattLFerraro wrote:
I didn't know you could instantiate
components that way.

Yes.
The vhdl language has no marketing department.

I have not seen any examples or reference designs from FPGA vendors
that use that method.

The FPGA vendors would prefer that I
instance their black box netlist rather than
portable code. This translates
into an unbound component instance 'wizard' synthesis
and a purposely non-synthesizable simulation model.
This causes no end of confusion and questions to
this newsgroup.

To their credit, the vendors do document
some synthesis templates in but I have never seen
a direct instance example.

Here two that I dug up:

Fromhttp://home.comcast.net/~mike_treseler/oe_demo.vhd:

oe_demo_1 : entity work.oe_demo
port map (reset => reset_s, -- [in]
clock => clock_s, -- [in]
data => data_s, -- [inout]
ready => ready_s, -- [out]
oe => oe_s); -- [in]

From:http://home.comcast.net/~mike_treseler/test_uart.vhd

dut : entity work.uart
generic map (char_len_g => tb_char_g, -- for vsim cmd line
tic_per_bit_g => tb_tics_g)
port map (
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback dest
serialOut => serialOut_s -- [out]-- by uut, loopback src
);

It is more like Verilog. And less time consuming.

Exactly

Why wouldn't that method be shown more often?

Tradition.

-- Mike Treseler

Direct entity instantiation was added to VHDL in 1993, so many tools
were initially developed before it was adopted, and therefore did not
use it. Updating working examples in tool documentation would be nice,
but has a lower priority than fixing non-working examples.

Andy

 

[Mike Treseler]

Paul Uiterlinden wrote:

As long as there is a compiled entity in a library, it should not matter how
the instantiation is done. I would expect that both direct- and component-
instantiation work.

I wonder if a direct instance of
an entity with a null architecture would
would look enough like an unbound component
for vendor synthesis to match the netlist id.
Hmmm. Worth a try.

-- Mike Treseler

 

[Mark McDougall]

MattLFerraro wrote:

2) If I had a generic DATA_WIDTH : integer = 32 defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined? Does the
components default assignment of the generic override the entities
default assignment of the generic?

Since the instantiation "sees" the component declaration and not the
entity declaration, I'd *guess* that it would use the value of the generic
from the component. But it's only a guess...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

 

[KJ]

On Feb 12, 5:34 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

KJ wrote:

The only time you 'have' to use components is when the thing you are
instantiating is some form of 'black box' (i.e. you don't have the
source, only a pre-compiled something) that you are using in your
design.

As long as there is a compiled entity in a library, it should not matter how
the instantiation is done. I would expect that both direct- and component-
instantiation work.

Both methods 'work', my only point is that using components is more
prone to producing otherwise avoidable errors when you're actively
designing the widget and the interface to the widget is somewhat in
flux (i.e. the entity and therefore the component signals/parameters
are changing). Using direct instantiation the compiler will
immediately flag when any usage of widget does not match the entity
definition if you do a 'compile all'.

When you use components you have to update the component definition
(preferably by copy/paste) to match what you just typed in for the
change to the entity and then go to each of the usages of the widget
and update. If you forget to update the component, things compile
just fine and won't fail until elaboration when you thought you ready
to start sim.

If you follow the traditional approach of defining the component prior
to every usage (the worst possible way in my view) then you make even
more work since a change to the entity needs to be reflected in
updated component definition at each point of use.

I'd much prefer the computer to do the work of catching places where
I've forgotten to update a usage of a widget then to spend my own time
trying to figure it out. From my perspective, the advantages of using
components (i.e. can compile files in any order; can change default
values) do not even come close to the advantages of not using them.

Kevin Jennings

 

[KJ]

On Feb 12, 7:07 pm, Mark McDougall <ma...@vl.com.au> wrote:

MattLFerraro wrote:
2) If I had a generic DATA_WIDTH : integer = 32  defined in my entity
declaration; what would happen if the component declaration changed
that definition to DATA_WIDTH : integer = 16 - and the component
instantiation does not have a generic mapping defined?  Does the
components default assignment of the generic override the entities
default assignment of the generic?

Since the instantiation "sees" the component declaration and not the
entity declaration, I'd *guess* that it would use the value of the generic
from the component. But it's only a guess...

You're correct. In the sample below, Modelsim reports that the
generic has taken on the default value as assigned by the component
definition overriding the default value as assigned by the entity
definition.

KJ
------------------
entity Foo_Entity is generic(Parm: integer := 1);
end Foo_Entity;
architecture RTL of Foo_Entity is
begin
end RTL;

entity tb_Foo_Entity is
end tb_Foo_Entity;
architecture RTL of tb_Foo_Entity is
component Foo_Entity is
generic(Parm: integer := 10);
end component Foo_Entity;
begin
DUT : Foo_Entity;
end RTL;

 

[Paul Uiterlinden]

KJ wrote:

On Feb 12, 5:34 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:
KJ wrote:

The only time you 'have' to use components is when the thing you are
instantiating is some form of 'black box' (i.e. you don't have the
source, only a pre-compiled something) that you are using in your
design.

As long as there is a compiled entity in a library, it should not matter
how the instantiation is done. I would expect that both direct- and
component- instantiation work.


Both methods 'work', my only point is that using components is more
prone to producing otherwise avoidable errors when you're actively
designing the widget and the interface to the widget is somewhat in
flux (i.e. the entity and therefore the component signals/parameters
are changing). Using direct instantiation the compiler will
immediately flag when any usage of widget does not match the entity
definition if you do a 'compile all'.

When you use components you have to update the component definition
(preferably by copy/paste) to match what you just typed in for the
change to the entity and then go to each of the usages of the widget
and update. If you forget to update the component, things compile
just fine and won't fail until elaboration when you thought you ready
to start sim.

If you follow the traditional approach of defining the component prior
to every usage (the worst possible way in my view) then you make even
more work since a change to the entity needs to be reflected in
updated component definition at each point of use.

I'd much prefer the computer to do the work of catching places where
I've forgotten to update a usage of a widget then to spend my own time
trying to figure it out. From my perspective, the advantages of using
components (i.e. can compile files in any order; can change default
values) do not even come close to the advantages of not using them.

I completely agree with you, all good points. The only thing that triggered
me was the "you 'have' to use components when the thing you are
instantiating is some form of 'black box'...". I still think it is not
true. But hey, it's just my understanding, which is known not to be
infallible. ;-)

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[KJ]

On Feb 20, 9:15 pm, Jim Lewis <j...@synthworks.com> wrote:

 Why wouldn't that method be shown more often?

Tradition.

Tool support.  Last I checked it is not supported
by Synopsys.  Anyone know?

And to be fair to the tool guys, this feature was only added to the
language back in 1993...15 years ago. The original language was only
6 years old at that time.

Makes you wonder when any 200x features will be available...205x?

Is it working on all/most FPGA tools: Altera, Xilinx, Synplicity,
Mentor?

Direct entity instantiation works just fine with Altera and
Synplicity.

Kevin Jennings