when using generic

[gharaam]

hello;
im asking when can i use generic
thanks

 

[KJ]

hello;
im asking when can i use generic
thanks

You use generics in an entity.

KJ

 

[Andy]

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

 

[Paul Uiterlinden]

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;

 

[Andy]

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

 

[Mike Treseler]

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

 

[Paul Uiterlinden]

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.

 

[Andy]

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


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.


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.


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,

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

 

[KJ]

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

 

[Mike Treseler]

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

 

[Paul Uiterlinden]

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