Specifying generics in configuration

  • Thread starter valentin tihomirov
  • Start date
V

valentin tihomirov

entity E is
generic (P: integer)
end E;

-- this configuration asserts an arch to the entity for sinthesis/simulation
providing actual 1 for P
configuration BIND of E is
generic map(P => 1); -- causes error
for A
end for;
end BIND;

I feel difficulty in specifying the generic in configuration. Why?
 
A

Alan Fitch

valentin tihomirov said:
entity E is
generic (P: integer)
end E;

-- this configuration asserts an arch to the entity for sinthesis/simulation
providing actual 1 for P
configuration BIND of E is
generic map(P => 1); -- causes error
for A
end for;
end BIND;

I feel difficulty in specifying the generic in configuration. Why?
Click to expand...

If I understand you correctly, I think you need to apply the generic
to the instance of a component that is bound to entity e. For
instance,

entity tb is
end;

architecture A of tb is

component E is
generic (P: integer);
end component;

begin

U1 : E;

end;

use work.all;
configuration BIND of tb is
for A -- of tb
for u1: e
use entity work.e(a) -- architecture a of e
generic map (P => 1);
end;
end;
end;




--
Alan Fitch
Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
(e-mail address removed)
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

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

MK

entity E is
generic (P: integer)
end E;

-- this configuration asserts an arch to the entity for sinthesis/simulation
providing actual 1 for P
configuration BIND of E is
generic map(P => 1); -- causes error
for A
end for;
end BIND;

I feel difficulty in specifying the generic in configuration. Why?
Click to expand...

You cannot set value of generic in configuration of entity - you can do
it only in instantiation configuration.

regards,
MK.
 
V

valentin tihomirov

I'll try to give more practical example. I have designed an EMULATOR entity.
It instantiates a Circuit Under Simulation (CUS) entity. CUS may be any
circuit with arbitrary number of I/Os. The number of I/Os in emulator and
CUS is matched by WIDTH generic param. Particularly, the WIDTH is a number
of I/Os in a specific CUS. Therefore, when one desides to emulate a cus it
provides synthesiable description of the CUS and number of I/Os in CUS. This
is what configuration is intended for.


Here is an example of CUS that can be simulated by emulator. It has two
inputs and one output:
architecture OR2 of CUS is -- 4 inputs and 2 outputs
begin
OUTPUTS(0) <= INPUTS(0) or INPUTS(1);
end OR2;



Here is my testbench for the emulator:

entity emulator_tb is
end emulator_tb;

architecture TB_ARCHITECTURE of emulator_tb is
component EMULATOR
port(...);
end component;
begin
UUT : EMULATOR
port map (...);
end;

-- the configuration specifies which CUS to emulate and number of I/Os
-- in CUS
configuration TESTBENCH_FOR_emulator of emulator_tb is
for TB_ARCHITECTURE
for UUT : EMULATOR -- instantiate emulator specifying WIDTHs
use entity work.emulator(rtl)
generic map(I_WIDTH => 2, O_WIDTH => 1);
for RTL
for CUS1: CUS
use entity work.CUS(OR2); -- implementation of CUS to
simulate
end for;
end for;

end for;
end TESTBENCH_FOR_emulator;



The TB above looks like what you've recommended. It is good for TB, because
TB as a wrapping entity that should be used anyway. But I'm paranoic in code
optimization. As there is no need for wrapper entity for synthesis, I'm
finding a way to bind the emulator with a CUS using a configuration-only
approach; like this one:

configuration BIND_CUS of emulator is
generic map(I_WIDTH => 2, O_WIDTH => 1); -- error is here
for RTL
for CUS1: CUS
use entity work.CUS(OR2); --
end for;
end for;
end TESTBENCH_FOR_emulator;


Thank you very much.
 
V

valentin tihomirov

You cannot set value of generic in configuration of entity - you can
do
it only in instantiation configuration.
Click to expand...

Does this mean that a wrapper-entity is mandatory?
 
J

Jim Lewis

Valentin,
Does this mean that a wrapper-entity is mandatory?
Click to expand...
No.

Take a look at generics being specified and mapped
in block statements. These can be mapped in a
configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

valentin said:
Does this mean that a wrapper-entity is mandatory?
Click to expand...

~~~~~~~~~~~
 
M

Mike Treseler

valentin said:
entity E is
generic (P: integer)
end E;

-- this configuration asserts an arch to the entity for sinthesis/simulation
providing actual 1 for P
configuration BIND of E is
generic map(P => 1); -- causes error
for A
end for;
end BIND;

I feel difficulty in specifying the generic in configuration. Why?
Click to expand...

Are you using the -93 option?
There is a problem with this in -87.
http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#default_binding

-- Mike Treseler
 
J

Jim Lewis

Perhaps I lied. I was thinking that I could
map generics specified in a block header in
the configuration declaration. I don't seem to be
able to get my test case to work though:

entity test is
end entity test ;
architecture behave of test is
signal M : integer ;
begin
MyBlk : block is
generic (T : integer := 5) ;

begin
MyProc : process
begin
M <= T ;
wait for 5 ns ;
M <= M + T ;
wait for 5 ns ;
M <= M + T ;
wait for 5 ns ;
M <= M + T ;
wait for 5 ns ;
M <= M + T ;
wait for 5 ns ;
M <= M + T ;
wait ;
end process ;
end block ;
end behave ;

Configuration Cfg of test is
for behave
for MyBlk
-- generic map (T => 1) ; -- would be nice, but does not seem to work
end for ;
end for ;
end ;


I am going to have to kick this around a little and
see if we can't work mapping top level generics and/or
block generics into one of the next revisions
of the language.

Cheers,
Jim

valentin said:
Could you, please, provide an example?
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
M

MK

I am going to have to kick this around a little and
see if we can't work mapping top level generics and/or
block generics into one of the next revisions
of the language.
Click to expand...

Good idea - it would be nice feature in some cases, but it will be very
funny, when somebody use such (with generic map) configuration in binding
indication in another configuration containing generic map aspect. Then
there will be 3 sources of value for generic: default, generic map from
configuration, generic map from instantiation - it smells like Verilog with
parameter value, parameter association and defparam :-(

MK.
 
V

valentin tihomirov

Multiple sources, a VHDL example:

process
begin
a <= '0'
end;

process
begin
a <= '1'
end;

Compiler shows you an error if A is not a bus. What is bad in the case where
I have only one source overriding a generic value? I cannot see any
reasonable reason for this top-level configuration not to compile:

entity E is
generic (G: integer)
end E;

architecture A for E is <component instantiations> begin end;

configuration C for E is
G => 1; -- only one source
for A
for <component> use <entity> ...
end C;
 
V

valentin tihomirov

Compiling with strict 93 synthax gives me the same error. The first
statement in configuration should be *for*. Movig the generic map statement
inside *for A* brings similar error.
 
M

MK

valentin tihomirov said:
Multiple sources, a VHDL example:

process
begin
a <= '0'
end;

process
begin
a <= '1'
end;

Compiler shows you an error if A is not a bus. What is bad in the case where
I have only one source overriding a generic value? I cannot see any
reasonable reason for this top-level configuration not to compile:

entity E is
generic (G: integer)
end E;

architecture A for E is <component instantiations> begin end;

configuration C for E is
G => 1; -- only one source
for A
for <component> use <entity> ...
end C;
Click to expand...

Easy, easy - there are two different meaning of "source" - for signals
there are drivers, for generic there are constant value source. I've
forgotten about configuration specification, so finally (after allowing
generic map for corresponding entity in configuration) we can have 4(!)
sources of initial value for generic - maybe this is not so bad for users,
but for simulator implementators looks not so good :-(

BTW.: leaving entity with generic without default value can be
intentional - somebody can avoid using such entity as toplevel, or
instantiated without generic map ...
 
J

Jim Lewis

I am thinking of something similar to what you
can already do for an entity. With an entity,
you can specify a default value on the entity,
override that default with a new default on the
component, override the component value by mapping it
in the component instantiation, and then override
that value in the configuration declaration.
it smells like Verilog with
parameter value, parameter association and defparam :-(
Click to expand...
Don't worry, we will not re-invent Verilog.

Regards,
Jim
Good idea - it would be nice feature in some cases, but it will be very
funny, when somebody use such (with generic map) configuration in binding
indication in another configuration containing generic map aspect. Then
there will be 3 sources of value for generic: default, generic map from
configuration, generic map from instantiation - it smells like Verilog with
parameter value, parameter association and defparam :-(

MK.
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
V

valentin tihomirov

Easy, easy - there are two different meaning of "source" - for signals
there are drivers, for generic there are constant value source. I've
forgotten about configuration specification, so finally (after allowing
generic map for corresponding entity in configuration) we can have 4(!)
sources of initial value for generic - maybe this is not so bad for users,
but for simulator implementators looks not so good :-(
Click to expand...
You forget about implementors of synthesis tools. Once simulating multiple
signal sources, there shouldn't be any problems to do it once again. Water
and electricity have different sources as well.

BTW.: leaving entity with generic without default value can be
intentional - somebody can avoid using such entity as toplevel, or
instantiated without generic map ...
Click to expand...
I am a GOD! DEFAULTS ARE A MUST!!! :eek:)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

configuration problem 3
configurations and generics 4
Creating delay chain with generics 6
Components with GENERICs 3
generics 8
Illegal sequential statement (VHDL) 0
2 JK Circuit in VHDL 0
Use of generics at top level of testbench 0

Members online

No members online now.
Total: 28 (members: 0, guests: 28)
Robots: 214

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top