when using generic

Discussion in 'VHDL' started by gharaam, Oct 26, 2007.

  1. gharaam

    gharaam Guest

    gharaam, Oct 26, 2007
    #1
    1. Advertising

  2. gharaam

    KJ Guest

    "gharaam" <> wrote in message
    news:...
    > hello;
    > im asking when can i use generic
    > thanks
    >


    You use generics in an entity.

    KJ
     
    KJ, Oct 26, 2007
    #2
    1. Advertising

  3. gharaam

    Andy Guest

    On Oct 26, 8:13 am, "KJ" <> wrote:
    > "gharaam" <> wrote in message
    >
    > news:...
    >
    > > hello;
    > > im asking when can i use generic
    > > thanks

    >
    > You use generics in an entity.
    >
    > KJ


    To clarify, you declare generics on an entity (or component).

    You can use generics anywhere you could use a deferred constant (i.e
    they are not locally static)

    You specify generic values either via the default value in the
    declaration, or via the instantiation of the entity/component, or via
    command line arguments for top-level generics.

    Andy
     
    Andy, Oct 26, 2007
    #3
  4. Andy wrote:

    > To clarify, you declare generics on an entity (or component).
    >
    > You can use generics anywhere you could use a deferred constant (i.e
    > they are not locally static)
    >
    > You specify generic values either via the default value in the
    > declaration, or via the instantiation of the entity/component, or via
    > command line arguments for top-level generics.


    Or in a configuration declaration, e.g.:

    CONFIGURATION tc_testcase_cfg OF tc IS
    FOR testcase_arch
    FOR testbench_i: testbench
    USE CONFIGURATION tb_lib.tb_testbench_cfg
    GENERIC MAP
    (
    timebomb => 100 ms
    );
    END FOR;
    END FOR;
    END CONFIGURATION tc_testcase_cfg;

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 2, 2007
    #4
  5. gharaam

    Andy Guest

    Yes, that's the other use.

    However, don't you have to have a "use <entity>" to specify a generic
    map? How do you specify a generic _on_ a configuration? Or am I just
    confused about what your configuration does? (Entirely likely, since I
    don't use them much anymore, in favor of entity instantiation and
    generic records.)

    Andy
     
    Andy, Nov 5, 2007
    #5
  6. Andy wrote:

    > don't you have to have a "use <entity>" to specify a generic
    > map?


    "use entity" is one option.
    The other is "use configuration"
    which just indirects the "use entity"

    I agree with you that a direct instance
    is far less mind-numbing for vhdl 93+.

    > How do you specify a generic _on_ a configuration?


    The base generic is already on the instanced entity.

    -- Mike Treseler
     
    Mike Treseler, Nov 5, 2007
    #6
  7. Andy wrote:

    > Yes, that's the other use.


    I assume you are referring to my previous post. Due to the lack of any
    quoting, it's not completely clear to me.

    > However, don't you have to have a "use <entity>" to specify a generic
    > map?


    No.

    > How do you specify a generic _on_ a configuration?


    Like this:

    CONFIGURATION tc_testcase_cfg OF tc IS
    FOR testcase_arch
    FOR testbench_i: testbench
    USE CONFIGURATION tb_lib.testbench_cfg
    GENERIC MAP
    (
    timebomb => 100 ms
    );
    END FOR;
    END FOR;
    END CONFIGURATION tc_testcase_cfg;

    The code just as well could have read:

    CONFIGURATION tc_testcase_cfg OF tc IS
    FOR testcase_arch
    FOR testbench_i: testbench
    USE ENTITY tb_lib.testbench(tb_arch)
    GENERIC MAP
    (
    timebomb => 100 ms
    );
    END FOR;
    END FOR;
    END CONFIGURATION tc_testcase_cfg;

    The thing you miss then is the binding of the lower components of the
    testbench.

    > Or am I just confused about what your configuration does?


    What all configurations do: bind a component instantiation to a specific
    entity/architecture pair.

    If some joker (and that could well be me) adds another architecture to the
    same entity, the last analyzed architecture is taken in the absence of a
    configuration. With a configuration, such surprises are avoided. Granted: a
    bit far fetched for most of us. But my reasoning is: if something can go
    wrong, it will go wrong. Maybe not now, but perhaps later. Why not make
    sure this cannot happen? And multiple architectures in an verification
    environment are less seldom than in a design.

    > (Entirely likely, since I
    > don't use them much anymore, in favor of entity instantiation and
    > generic records.)


    Configurations are only used by me in in testcases and testbenches, mainly
    to pass generics and configure the testbench that way. And to make sure
    what entity/architecture pairs are used.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 5, 2007
    #7
  8. gharaam

    Andy Guest

    On Nov 5, 3:30 pm, Paul Uiterlinden <> wrote:
    > Andy wrote:
    > > Yes, that's the other use.

    >
    > I assume you are referring to my previous post. Due to the lack of any
    > quoting, it's not completely clear to me.
    >
    > > However, don't you have to have a "use <entity>" to specify a generic
    > > map?

    >
    > No.
    >
    > > How do you specify a generic _on_ a configuration?

    >
    > Like this:
    >
    > CONFIGURATION tc_testcase_cfg OF tc IS
    > FOR testcase_arch
    > FOR testbench_i: testbench
    > USE CONFIGURATION tb_lib.testbench_cfg
    > GENERIC MAP
    > (
    > timebomb => 100 ms
    > );
    > END FOR;
    > END FOR;
    > END CONFIGURATION tc_testcase_cfg;
    >
    > The code just as well could have read:
    >
    > CONFIGURATION tc_testcase_cfg OF tc IS
    > FOR testcase_arch
    > FOR testbench_i: testbench
    > USE ENTITY tb_lib.testbench(tb_arch)
    > GENERIC MAP
    > (
    > timebomb => 100 ms
    > );
    > END FOR;
    > END FOR;
    > END CONFIGURATION tc_testcase_cfg;
    >
    > The thing you miss then is the binding of the lower components of the
    > testbench.
    >
    > > Or am I just confused about what your configuration does?

    >
    > What all configurations do: bind a component instantiation to a specific
    > entity/architecture pair.
    >
    > If some joker (and that could well be me) adds another architecture to the
    > same entity, the last analyzed architecture is taken in the absence of a
    > configuration. With a configuration, such surprises are avoided. Granted: a
    > bit far fetched for most of us. But my reasoning is: if something can go
    > wrong, it will go wrong. Maybe not now, but perhaps later. Why not make
    > sure this cannot happen? And multiple architectures in an verification
    > environment are less seldom than in a design.
    >
    > > (Entirely likely, since I
    > > don't use them much anymore, in favor of entity instantiation and
    > > generic records.)

    >
    > Configurations are only used by me in in testcases and testbenches, mainly
    > to pass generics and configure the testbench that way. And to make sure
    > what entity/architecture pairs are used.
    >
    > --
    > Paul Uiterlindenwww.aimvalley.nl
    > e-mail addres: remove the not.


    Paul,

    Sorry, I use a threaded reader, so I was not aware that it could be
    ambiguous, but yes, I was replying to your message.

    Thanks for the explanation. The syntax is confusing that the generic
    map applies to testbench (the object that the configuration
    configures), and not to the configuration itself (something inside
    testbench). Now I understand.

    I generally specify the architecture in the entity instantiation to
    avoid the problems you mentioned regarding which architecture is bound
    to an entity:

    label: entity my_lib.my_entity(my_architecture)

    Between entity instantiations, if-generates, and generics, I've
    practically eliminated my use of configurations (as you can see, I'm a
    little rusty!), and about the only time left that still I use a
    component is when instantiating a primitive in the synthesis code. I
    also use tools that make it easier to correctly handle order-of-
    analysis issues (one big advantage of configurations if you don't have
    such tools).

    Andy
     
    Andy, Nov 5, 2007
    #8
  9. gharaam

    KJ Guest

    "Andy" <> wrote in message
    news:...

    > Between entity instantiations, if-generates, and generics, I've
    > practically eliminated my use of configurations (as you can see, I'm a
    > little rusty!), and about the only time left that still I use a
    > component is when instantiating a primitive in the synthesis code.


    The one place that I find configurations handy is in the situation where I
    have a CAD tool generated netlist of the PCBA that I'm using as a testbench.
    In that environment I find that resistor models generally need to be hand
    configured. Situations where different resistor models are:
    - Some need to work somewhat like a diode, passing signals only one way
    because a bi-directional model could cause transitions to look like 0->X->1
    and 1->X->0, neither of which will pass the rising_edge/falling_edge
    functions.
    - Other times a need true bi-directional behaviour but can live with the
    momentary 'X' (like series terminators on a DDR data bus).
    - Other times I need to just ignore one and act like an open circuit (if
    there is a pullup/pulldown termination on the net).

    So until a VHDL model for a resistor comes along that can actually correctly
    model all of the typical uses of resistors, I'm forced with having to use
    configurations to get the required behaviour out of the multiple models that
    I have.

    KJ
     
    KJ, Nov 6, 2007
    #9
  10. Andy wrote:
    > Thanks for the explanation. The syntax is confusing that the generic
    > map applies to testbench (the object that the configuration
    > configures), and not to the configuration itself (something inside
    > testbench). Now I understand.


    I'm not sure I do. Looks to me like
    the base testbench entity is named tc
    its architecture is testcase_arch
    which instances another entity named testbench
    which gets the 100 ms value,
    if the library unit tc_testcase_cfg
    is run instead of tc.

    > I generally specify the architecture in the entity instantiation to
    > avoid the problems you mentioned regarding which architecture is bound
    > to an entity:
    >
    > label: entity my_lib.my_entity(my_architecture)


    Yes. I have found no downside to this method.

    -- Mike Treseler
     
    Mike Treseler, Nov 6, 2007
    #10
  11. Mike Treseler wrote:

    > Andy wrote:
    >> Thanks for the explanation. The syntax is confusing that the generic
    >> map applies to testbench (the object that the configuration
    >> configures), and not to the configuration itself (something inside
    >> testbench). Now I understand.

    >
    > I'm not sure I do. Looks to me like
    > the base testbench entity is named tc
    > its architecture is testcase_arch
    > which instances another entity named testbench
    > which gets the 100 ms value,


    Exactly.

    > if the library unit tc_testcase_cfg
    > is run instead of tc.


    Yes indeed. To run the simulation, the toplevel configuration
    tc_testcase_cfg should be elaborated, not the entity tc.

    Below is the complete picture. It is two-layered: a single testbench with
    all the tedious stuff, such as all the plumbing connecting busfunctional
    models to the DUV (device under verification).

    And then there are lots of testcases, each instantiating the testbench and
    optionally configuring the testbench by setting its generics in the
    toplevel (testcase) configuration(s). Each testcase runs a specific
    scenario, verifying a bunch of requirements of the DUV.

    To make it even more complicated (well, in fact: easier): multiple
    configurations of a single testcase may exist. That way, a scenario can be
    run using for example an alternative RAM model connected to your DUV in the
    testbench. You just supply a different generic to the testbench via the
    alternative toplevel configuration.

    The main goal of all this is to avoid duplication of code. The testcases
    only contain the scenario specific stuff while the testbench contains the
    stuff that is needed by each testcase. Without this, maintenance would be
    hell.


    Analyzed into library tb_lib:
    ----------------------------

    PACKAGE testbench_pkg IS
    -- Signal declarations, used in the testbench, made visible in
    -- the testcase
    ...
    -- One of those is 'simulate', which, when set false, will stop all
    -- clock generators and with that end the simulation
    --
    SIGNAL simulate : boolean := true;

    -- Component declaration of the testbench, without generics, so
    -- the ones without a default must be set in the configuration of
    -- the testcase.
    --
    COMPONENT testbench IS
    END COMPONENT testbench;
    END PACKAGE testbench_pkg IS;

    ENTITY testbench IS
    GENERIC
    (
    timebomb : delay_length; -- No default value, so user must supply one
    -- more generics for configuring the testbench
    );
    END ENTITY testbench;


    USE work.testbench_pkg.ALL; -- Make signals from package available
    ARCHITECTURE tb_arch IS
    -- Private signal declarations that will not be visible in
    -- the testcase
    ...
    BEGIN
    -- Instantiation of the DUV and verification components.
    --
    myduv_i: myduv
    PORT MAP
    ...

    ...

    -- All plumbing to connect the components, clock generators,
    -- reset generators, standard initialization sequences, etc
    ...

    -- Timebomb and final simulation result
    --
    -- If the simulation does not stop on its own accord before the specified
    -- maximum simulation time (via generic timebomb), the simulation is
    -- aborted with an error (to prevent a run-away simulation blocking other
    -- simulations in the queue).
    --
    sim_result: PROCESS IS
    BEGIN
    WAIT UNTIL NOT simulate FOR timebomb;

    IF simulate THEN
    REPORT "SIMULATION FAILED! Maximum simulation time expired"
    SEVERITY failure;
    ELSE
    -- Evaluation of error counters, score boards, etc resulting
    -- in a final PASS/FAIL verdict.
    ....
    END IF;

    WAIT;
    END PROCESS sim_result;
    END ARCHITECTURE tb_arch

    CONFIGURATION testbench_cfg OF testbench IS
    FOR tb_arch
    FOR myduv_i: myduv
    USE ENTITY src_myduv_lib.duv(duv_arch);
    END FOR;

    -- More component bindings, for the verification components
    -- such as bus functional models.
    ....
    END FOR:
    END CONFIGURATION testbench_cfg;


    Analyzed into library work:
    ---------------------------

    ENTITY tc IS
    END ENTITY tc;

    USE tb_lib.testbench_pkg.ALL; -- Make signals from testbench available
    ARCHITECTURE testcase_arch IS
    BEGIN
    -- Instantiation of the testbench
    --
    testbench_i: testbench;

    -- The actual scenario
    --
    do_sim: PROCESS IS
    BEGIN
    -- do reset and wait on end of reset
    ....

    -- run the scenario
    ....

    -- End of simulation
    --
    simulate <= false;
    WAIT;
    END PROCESS do_sim;
    END ARCHITECTURE testcase_arch;


    CONFIGURATION tc_testcase_cfg OF tc IS
    FOR testcase_arch
    FOR testbench_i: testbench
    USE CONFIGURATION tb_lib.testbench_cfg
    GENERIC MAP
    (
    timebomb => 100 ms;
    -- optionally more testbench settings
    ....
    );
    END FOR;
    END FOR;
    END CONFIGURATION tc_testcase_cfg;


    To run the simulation (using ModelSim):

    vsim -do 'run -a; quit' tc_testcase_cfg


    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 7, 2007
    #11
    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. Replies:
    9
    Views:
    8,110
    Ralf Hildebrandt
    Jan 19, 2005
  2. Replies:
    3
    Views:
    6,714
    Rob Dekker
    Jan 16, 2006
  3. Murat Tasan
    Replies:
    1
    Views:
    8,132
    Chaitanya
    Feb 3, 2009
  4. Replies:
    2
    Views:
    480
  5. minlearn
    Replies:
    2
    Views:
    495
    red floyd
    Mar 13, 2009
Loading...

Share This Page