Using default value of a generic in VHDL

Discussion in 'VHDL' started by filmil, Mar 28, 2007.

  1. filmil

    filmil Guest

    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
     
    filmil, Mar 28, 2007
    #1
    1. Advertising

  2. filmil

    KJ Guest

    "filmil" <> wrote in message
    news:...
    > 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
     
    KJ, Mar 28, 2007
    #2
    1. Advertising

  3. filmil

    filmil Guest

    On Mar 28, 12:16 pm, "KJ" <> wrote:
    > 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
     
    filmil, Mar 28, 2007
    #3
  4. filmil

    KJ Guest

    "filmil" <> wrote in message
    news:...
    > On Mar 28, 12:16 pm, "KJ" <> wrote:
    >> 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?


    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.

    >
    >> 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?

    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
     
    KJ, Mar 28, 2007
    #4
  5. filmil

    Ben Jones Guest

    "filmil" <> wrote in message
    news:...
    > 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-
     
    Ben Jones, Mar 28, 2007
    #5
  6. filmil

    filmil Guest

    On Mar 28, 1:19 pm, "KJ" <> wrote:
    > 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
     
    filmil, Mar 28, 2007
    #6
  7. filmil wrote:
    > 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
     
    Mike Treseler, Mar 28, 2007
    #7
  8. filmil

    Andy Guest

    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

    On Mar 28, 9:17 am, Mike Treseler <> wrote:
    > filmil wrote:
    > > 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, Mar 28, 2007
    #8
  9. "KJ" <> writes:

    > "filmil" <> wrote in message
    > news:...
    >> 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.


    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 :)

    >>
    >> 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).
    >


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

    >> 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.
    >


    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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Mar 29, 2007
    #9
  10. filmil

    KJ Guest

    "Martin Thompson" <> wrote in message
    news:...
    > "KJ" <> writes:
    >
    >> "filmil" <> wrote in message
    >> news:...
    >>> 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.

    >
    > 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.

    >
    >>
    >> 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 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
     
    KJ, Mar 29, 2007
    #10
  11. filmil

    Andy Guest

    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

    On Mar 29, 4:06 am, Martin Thompson <> wrote:
    > "KJ" <> writes:
    > > "filmil" <> wrote in message
    > >news:...
    > >> 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.

    >
    > 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 :)
    >
    >
    >
    > >> 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).

    >
    > Unless you want to use configurations, which I do to make lots of
    > testbenches that only differ slightly.
    >
    > >> 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.

    >
    > 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
    >
    > --
    >
    > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html
     
    Andy, Mar 29, 2007
    #11
  12. filmil

    KJ Guest

    On Mar 29, 2:00 pm, "Andy" <> wrote:
    > 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
     
    KJ, Mar 29, 2007
    #12
  13. "KJ" <> writes:

    > On Mar 29, 2:00 pm, "Andy" <> wrote:
    >> 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?


    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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Mar 30, 2007
    #13
  14. "KJ" <> writes:

    > "Martin Thompson" <> wrote in message
    > news:...
    >> "KJ" <> writes:
    >>
    >> 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.
    >


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

    >>
    >>>
    >>> 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 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.

    >>
    >> 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).
    >


    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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Mar 30, 2007
    #14
  15. Martin Thompson wrote:

    > 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/
     
    Mike Treseler, Mar 30, 2007
    #15
  16. filmil

    Andy Guest

    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

    On Mar 30, 5:55 am, Mike Treseler <> wrote:
    > Martin Thompson wrote:
    > > 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, Mar 30, 2007
    #16
  17. On 28 Mar 2007 05:33:40 -0700, "filmil"
    <> wrote:


    >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

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Mar 31, 2007
    #17
  18. filmil

    KJ Guest

    "Jonathan Bromley" <> wrote in message
    news:...
    >
    > 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
     
    KJ, Apr 1, 2007
    #18
  19. "Andy" <> writes:

    > 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 :)

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Apr 2, 2007
    #19
    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. Murat Tasan
    Replies:
    1
    Views:
    8,097
    Chaitanya
    Feb 3, 2009
  2. Replies:
    2
    Views:
    457
  3. C Gillespie
    Replies:
    3
    Views:
    432
    Peter Hansen
    Mar 22, 2005
  4. afd
    Replies:
    1
    Views:
    8,484
    Colin Paul Gloster
    Mar 23, 2007
  5. sridar

    Generic Comparator using VHDL

    sridar, Nov 6, 2009, in forum: VHDL
    Replies:
    2
    Views:
    3,241
    vipinlal
    Mar 10, 2010
Loading...

Share This Page