Using default value of a generic in VHDL

[filmil]

When making a component instance, how does one specify that one wants
to use the default value of a generic, as specified in the entity
declaration?

I thought that simply omitting the generic in question from the
generic map would do the trick. However, my compiler complains about
the generic not being given an actual value if I do such a thing.

I can work around this problem by looking inside the entity in
question and supplying the default value. But I have a feeling this
kind of defeats the purpose of generics.

f

 

[KJ]

When making a component instance, how does one specify that one wants
to use the default value of a generic, as specified in the entity
declaration?

The best way is to not use components at all, use direct entity
instantiation. To do this you instantiate the widget something like this...
The_Thing : entity work.Thing generic map(...) port map(...);

The next best way (if you insist on using components despite the above
advice) is to define the component in a package that is physically within
the same file as the entity definition. Use copy/paste to keep the
definitions of the two in sync.

The worst way is to define the component in the separate file(s) at the
point where you want to use it. Doing it this way, you've set yourself up
for 'make work' and hard to pin down errors because the component definition
differs from the entity definition.

I thought that simply omitting the generic in question from the
generic map would do the trick. However, my compiler complains about
the generic not being given an actual value if I do such a thing.

Because the component definition needs to be the same as the entity in terms
of signals, generics and default values...in other words you can't do what
you're trying to do. But keep in mind, you don't need to use components at
all (see first advice).

I can work around this problem by looking inside the entity in
question and supplying the default value. But I have a feeling this
kind of defeats the purpose of generics.

Not really, it's 'usually' better to specify the values for all signals and
generics explicitly. It's 'better' in the sense that you've made it plainly
obvious in the code at the point of use what you want for all generics and
doesn't expose you if somewhere down the line somebody changes the default
value and breaks your code because you relied on the default value. It
depends on the stability of the code that you're trying to instantiate
whether you should trust using the default value or not.

Kevin Jennings

 

[filmil]

instantiation. To do this you instantiate the widget something like this...
The_Thing : entity work.Thing generic map(...) port map(...);

This does not talk about generics, if I understand well?

Not really, it's 'usually' better to specify the values for all signals and
generics explicitly. It's 'better' in the sense that you've made it plainly
obvious in the code at the point of use what you want for all generics and
doesn't expose you if somewhere down the line somebody changes the default

This is a fair enough explanation. But, why then does VHDL allow
specifying the default values for the generics, if 1) one cannot use
the default value implicitly; and 2) even if it were possible, it
would be bad practice?

Either way, you don't get to use the default values, except if for
some reason the entity in question is top-level.

A slight off-topic, default parameter values are recognized to be an
useful thing in some other programming languages. C++ comes to mind,
but other examples are there as well.

I have a feeling I am missing something here.

f

 

[KJ]

This does not talk about generics, if I understand well?

Doesn't sound like you understand my point. You will always have an entity,
you do not need a component definition in order to use that entity
somewhere. What I was demonstrating above was how you would instantiate the
entity (i.e. how you would use it) using direct entity instantiation. The
syntax is almost identical to how you would instantiate it if you defined a
component instead.

This is a fair enough explanation. But, why then does VHDL allow
specifying the default values for the generics, if 1) one cannot use
the default value implicitly; and 2) even if it were possible, it
would be bad practice?

I also said it depends on the stability of the code that you're
instantiating. Using defaults when instantiating some code that is not
likely to change is usually OK, if the code is not so rock solid (i.e. it is
still under development) then it might not be a good choice to use the
defaults since those defaults might change for some reason while development
of that entity is finished up.

Either way, you don't get to use the default values, except if for
some reason the entity in question is top-level.

Sure you do, you can use default values at any level.

A slight off-topic, default parameter values are recognized to be an
useful thing in some other programming languages. C++ comes to mind,
but other examples are there as well.

I have a feeling I am missing something here.

I think so too. Your original question had to do with defining a VHDL
component in such a way that you wouldn't need to look at the entity in
order to figure out what the default values for the generics are when you
define the component. My answer is to not use components at all by using
direct entity instantiation. Since you won't need to type in the code that
defines the VHDL component, you won't have to bother with making sure that
the defaults for the generics match the entity since there won't be any VHDL
'component' definition, just the entity.

Hope that clears things up.

Kevin Jennings

 

[Ben Jones]

When making a component instance, how does one specify that one wants
to use the default value of a generic, as specified in the entity
declaration?

You simply omit it from the generic map when you make the instantiation.

I thought that simply omitting the generic in question from the
generic map would do the trick. However, my compiler complains about
the generic not being given an actual value if I do such a thing.

Damn.

What compiler are you using? What error do you get?

-Ben-

 

[filmil]

Doesn't sound like you understand my point. You will always have an entity,
you do not need a component definition in order to use that entity

I did not understand it, until I made an example. It turns out that
the compiler does not complain about missing generics mappings if the
component is instantiated using:

c1 : entity work.Thing ...;

whereas :

component Thing ... ;

followed by:

c1: Thing ...;

would cause the compiler to complain about missing generics. I missed
your point because I didn't see how changing instantiation syntax
would help solve the generics problem.

Now that I saw it does, I could not leave it at that, but had to dig
further. Turns out that if you specify a default value for a generic
in the component declaration, you are not required to mention that
particular generic when instantiating a component.

To illustrate:

Assume we have:

entity Thing is generic (v : integer := 2 ); end;

Now we try using Thing (assuming library 'work'),

....
component Thing generic ( v : integer := 2 );
....
c : Thing;

will work, but

....
component Thing generic ( v : integer );
....
c : Thing;

won't.

Further,

c: entity work.Thing;

works if you pardon the VHDL93 syntax.

I disliked the latter variety as qualified names mean I must hunt them
all down and change them should Thing be moved to another library. At
least in the 'old style' the library usage was (mostly) confined to
the file headers.

To remedy,
library work;
use work.Thing;

allows:

c: entity Thing;

to work too. Nice.

I also said it depends on the stability of the code that you're
instantiating. Using defaults when instantiating some code that is not

I agree that the choice of the default values will depend on whether
the defaults do what you want. For designs that change during the
development of your product it indeed is smart to fix the values
yourself, because at least then you are yourself responsible for the
outcome.

On the other hand, my question only had to do with the language
semantics, so conditioning generics usage on the code stability is
kind of moving away from the point. I was expecting an answer only in
terms of VHDL specs.

But it is a good practical advice nevertheless, so it is appreciated.

Hope that clears things up.

Well now I have seen what works and what does not. It still beats me,
however, as to why exactly the working examples work, and why the non-
working one does not.

Looking at the working 'no-component' example, it seems clear that, in
order for it to work, the compiler must take a look at the entity
declaration in question in order to even begin the instantiation.
Once this lookup is done, the default generic values are found and can
be applied.

However, I see no reason why exactly the same thing could not happen
if a component declaration is used. It is possible, at least in
principle, to do this, but the compiler still chooses not to.

The only guess I can make is that the presence of a component
declaration constitutes a promise that any instantiation would conform
exactly to the component declaration, saving the compiler the trouble
of actually hunting the corresponding entity down in a file elsewhere.

I think I learned something today.

f

 

[Mike Treseler]

The only guess I can make is that the presence of a component
declaration constitutes a promise that any instantiation would conform
exactly to the component declaration, saving the compiler the trouble
of actually hunting the corresponding entity down in a file elsewhere.

A component instance without a configuration declaration
relies on a default binding which relies on
no critical mismatches.

But I agree with KJ. With rare exceptions,
components are more trouble than they are worth.

-- Mike Treseler

 

[Andy]

You can also specify the name of the architecture to use for the
entity:

u1: entity work.my_entity(my_arch)

So, unless you have multiple configurations where you bind the same
entities and/or architectures differently for different run cases,
there really isn't much need for component instantiation any more.
i.e. if all you ever use is the default binding (no configuration) or
a single configuration, then you're better off using entity
instantiation.

As for generics, I like to use them alot, no matter whether I think it
will ever change or not. I also like to use a record structure to
centralize the generic management effort. That way, if I need to add a
generic to a lower level entity, I just add it to the generic record
definition, define the value at the top, and away we go. The record
acts like a conduit through the levels of hierachy so that each
element does not have to be explicitly passed down through each level
of the hierarchy to its destination.

Andy

 

[Martin Thompson]

The best way is to not use components at all, use direct entity
instantiation. To do this you instantiate the widget something like this...
The_Thing : entity work.Thing generic map(...) port map(...);

The next best way (if you insist on using components despite the above
advice) is to define the component in a package that is physically within
the same file as the entity definition. Use copy/paste to keep the
definitions of the two in sync.

Or use emacs vhdl-mode to create a single file with all the components
in it. And remember to recreate it when you change things

The worst way is to define the component in the separate file(s) at the
point where you want to use it. Doing it this way, you've set yourself up
for 'make work' and hard to pin down errors because the component definition
differs from the entity definition.

Unless you want to use the component in multiple places (eg
testbenches)... then where do you put it? I started off putting the
component declaration inside the architecture that instantiated it,
but then I had to change it *twice* every time I changed the
interface.

I now have my interface using records, which means I don't have as
many problems like that

Because the component definition needs to be the same as the entity in terms
of signals, generics and default values...in other words you can't do what
you're trying to do. But keep in mind, you don't need to use components at
all (see first advice).

Unless you want to use configurations, which I do to make lots of
testbenches that only differ slightly.

Not really, it's 'usually' better to specify the values for all signals and
generics explicitly. It's 'better' in the sense that you've made it plainly
obvious in the code at the point of use what you want for all generics and
doesn't expose you if somewhere down the line somebody changes the default
value and breaks your code because you relied on the default value. It
depends on the stability of the code that you're trying to instantiate
whether you should trust using the default value or not.

Most of the time I use default values it's because I've added
functionality to the thing in question and I want it to continue to
behave the same for "older" code. I get to maintain the same
interface as I used to have, but with extensions.

Cheers,
Martin

 

[KJ]

Or use emacs vhdl-mode to create a single file with all the components
in it. And remember to recreate it when you change things

And then while editing that file, ask yourself why you're bothering with
this effort knowing now that it is not needed.

Unless you want to use the component in multiple places (eg
testbenches)... then where do you put it? I started off putting the
component declaration inside the architecture that instantiated it,
but then I had to change it *twice* every time I changed the
interface.

I would put it in a package that is in the same physical file as the
entity...at least that is the way I used to do it. Doesn't matter where or
how many places you use it, there was only one entity and one component
definition.

I now have my interface using records, which means I don't have as
many problems like that

As long as you use components when not needed you have the same problem,
just less likely to have it come up because the interfaces don't change
(which is a good thing, but a side topic).

Kevin Jennings

 

[Andy]

I commonly use very few, if any, component instantiations in the
synthesizable code, but often use a lot of them in the testbench.
Creating a package at the top of the same file that has the entity/
architecture, that contains the component declaration (if required)
for the entity, any type definitions for ports or generics that I may
need, etc. is a handy way to keep all that stuff together for that
entity. Then I just use the package wherever I instantiate the entity
or component. This does force order of analysis considerations that
are not present if all your components are declared in one file or
locally at point of use. But after the project is built once, those
issues are pretty transparent anyway.

Andy

 

[KJ]

I commonly use very few, if any, component instantiations in the
synthesizable code, but often use a lot of them in the testbench.

Just curious...why do you use them in the testbench? The only place
I've run into the need for components is with 'black box' instances
but in that situation whoever supplied the black box also supplies the
interface and did so usually in the form of a component. In any case,
I don't need to do any work maintaining it so it's not a bother to me.

Creating a package at the top of the same file that has the entity/
architecture, that contains the component declaration (if required)
for the entity, any type definitions for ports or generics that I may
need, etc. is a handy way to keep all that stuff together for that
entity. Then I just use the package wherever I instantiate the entity
or component.

I used to do exactly the same thing...remove the component declaration
and were up to how I do things now-a-days.

Kevin Jennings

 

[Martin Thompson]

Just curious...why do you use them in the testbench?

Dunnop about Andy, but I use them so I can create lots of tests by
tweaking generics in a configuration.

For example, I have some code which extracts a window of data from an
input source, and I need to check that it works in the corner cases of
"no data" and "all the data". I can do this by passing a generic
through the TB.

In synth code, I only use components if I have to black box things.

Cheers,
Martin

 

[Martin Thompson]

And then while editing that file, ask yourself why you're bothering with
this effort knowing now that it is not needed.

I don't edit it, vhdl-mode does it for me.

I would put it in a package that is in the same physical file as the
entity...at least that is the way I used to do it. Doesn't matter where or
how many places you use it, there was only one entity and one component
definition.

Agreed! Although, I've not tended to put it in the same physical file
as it gets in the way. But with folding-mode, I can hide it
so... maybe I'll give that a go.

As long as you use components when not needed you have the same problem,
just less likely to have it come up because the interfaces don't change
(which is a good thing, but a side topic).

I only use components when needed (see my reply to your other
message).

The vast majority of the time they are not needed. the other times, I
have yet to find a good way of doing without them :-(

Cheers,
Martin

 

[Mike Treseler]

Dunnop about Andy, but I use them so I can create lots of tests by
tweaking generics in a configuration.

For example, I have some code which extracts a window of data from an
input source, and I need to check that it works in the corner cases of
"no data" and "all the data". I can do this by passing a generic
through the TB.

I also pass generics to my testbenches
from the vsim command line to cover special cases.
This does not require components or configurations.

-- Mike Treseler

-- vsim -Gwire_g=random -c test_uart -do "run -all; exit"
-- vsim -Gwire_g=stuck_hi -c test_uart -do "run -all; exit"
-- vsim -Gtemplate_g=s_rst -c test_uart -do "run -all; exit"
-- slow baud: vsim -Gtb_tics_g=42 -c test_uart -do "run -all; exit"
-- run with waves: vsim test_uart -do uart.do
-- verify strobe calibration: vsim -Gtb_tics_g=42 test_uart
-- http://home.comcast.net/~mike_treseler/

 

[Andy]

Like Mike, I tend to customize via top level generics specified via
command line. I've started moving away from configurations/components
even in the test bench. Even if I need to change an entity or
architecture in the testbench, I've become more inclined to use a
generic to drive if-generate statements to directly instantiate the
entity(arch) I want. I still use configurations in some testbenches,
but less and less. With generate statements, I can include type
conversions that are not as restrictive as the functions required on
ports in configurations.

Andy

 

[Jonathan Bromley]

Well now I have seen what works and what does not. It still beats me,
however, as to why exactly the working examples work, and why the non-
working one does not.

Looking at the working 'no-component' example, it seems clear that, in
order for it to work, the compiler must take a look at the entity
declaration in question in order to even begin the instantiation.
Once this lookup is done, the default generic values are found and can
be applied.

However, I see no reason why exactly the same thing could not happen
if a component declaration is used. It is possible, at least in
principle, to do this, but the compiler still chooses not to.

The only guess I can make is that the presence of a component
declaration constitutes a promise that any instantiation would conform
exactly to the component declaration, saving the compiler the trouble
of actually hunting the corresponding entity down in a file elsewhere.

I think that last description is exactly correct. The whole point of
components is to permit separate compilation. Your description
of the component providing a "promise" about the entity's
appearance is spot-on. What's more, it is a promise that can
be checked later (at elaboration time) to ensure that the entity
indeed delivers what the component promised.

Many people here have good reasons for thinking that this
extra level of indirection is not sufficiently useful to justify
the trouble, and therefore they always use direct entity
instantiation. That is a perfectly justifiable point of view,
though I don't think I agree with it 100%.

To answer your specific question:

A default on a generic says "if the generic isn't wired-up, use this
value instead". You can do this in two places: the component,
or the entity (or neither, or both).

If you think of a component as a socket, and the entity as the
chip itself, then it starts to make some sense. VHDL can
bind a component with no default on its generic to an entity
with a default on that generic; but in that case, the entity
thinks the generic has been wired-up (to the generic
value coming through the component) and the component
requires that the generic be associated, since it has no
default. Not terribly useful.

It *is* useful to do it the other way around: put a default
on the component's generic, but not the entity's. If you
do that, and don't associate the generic on your component
instance, then the component's default will be used and
will be passed through to the entity. In fact, this is what
happens if you supply a default on both: the component's
default is passed through to the entity, and the entity's
default is ignored.

Of course, if you use direct instantiation of the entity
then any component declaration is irrelevant.

Despite what everyone has said about why it's better
to use direct instantiation of entities rather than
traditional component instantiation, there *are*
a few reasons why components come in useful.
One interesting possibility is to provide several
*different* component declarations for a given
entity; each component can have its own
specific value of default for a generic, for example.
You write the general-purpose entity only once, and
provide several different "application views" of it
by providing several components with different
defaults. Unfortunately, this probably means
that all the components need different names
and therefore you need to use explicit configuration
to bind them, so it's not as nice as you might hope.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

Despite what everyone has said about why it's better
to use direct instantiation of entities rather than
traditional component instantiation, there *are*
a few reasons why components come in useful.
One interesting possibility is to provide several
*different* component declarations for a given
entity; each component can have its own
specific value of default for a generic, for example.
You write the general-purpose entity only once, and
provide several different "application views" of it
by providing several components with different
defaults. Unfortunately, this probably means
that all the components need different names
and therefore you need to use explicit configuration
to bind them, so it's not as nice as you might hope.

From your description, it doesn't appear (at least not to me) that what you
described is a particularly 'good' use for components where it saves you any
amount of work (or whatever metric one might use to measure 'good').

Another example would be those that think it's nice to not have file
dependencies (plus) but are willing to put up with updating all known (and
unknown) usages of the component when the interface changes in some manner
(minus). In this case, the minus outweighs the plus in my opinion, others
might think differently.

So can you articulate a particular case (other than the black box entity)
where components actually are better than direct entity instantiation? I'm
assuming that whatever use one comes up with with will have plusses and
minuses just like any other approach just as the one you mentioned above.

Kevin Jennings

 

[Martin Thompson]

Like Mike, I tend to customize via top level generics specified via
command line. I've started moving away from configurations/components
even in the test bench. Even if I need to change an entity or
architecture in the testbench, I've become more inclined to use a
generic to drive if-generate statements to directly instantiate the
entity(arch) I want. I still use configurations in some testbenches,
but less and less. With generate statements, I can include type
conversions that are not as restrictive as the functions required on
ports in configurations.

Hmm, OK, I'll have to ponder the command-line approach...

Some of my TB configurations have rather a lot of generics passed into
them though, so it might get unpleasant