Specifying generics in configuration

  • Thread starter valentin tihomirov
  • Start date
V

valentin tihomirov

Guest
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?
 
"valentin tihomirov" <valentinNOSPAM@abelectron.com> wrote in message
news:btbuqd$5brv8$1@ID-212430.news.uni-berlin.de...
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:
alan.fitch@doulos.com
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.
 
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.
 
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.
 
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?
 
Valentin,
Does this mean that a wrapper-entity is mandatory?
No.
Click to expand...

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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

valentin tihomirov wrote:
You cannot set value of generic in configuration of entity - you can

do

it only in instantiation configuration.


Does this mean that a wrapper-entity is mandatory?
Click to expand...
~~~~~~~~~~~
 
valentin tihomirov wrote:
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
 
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 tihomirov wrote:
Could you, please, provide an example?
Click to expand...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
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.
 
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;
 
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.
 
"valentin tihomirov" <valentinNOSPAM@abelectron.com> wrote in message
news:btgksf$6vlbh$1@ID-212430.news.uni-berlin.de...
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 ...
 
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 :-(
Don't worry, we will not re-invent Verilog.
Click to expand...

Regards,
Jim

MK wrote:

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.


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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
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 :-(
You forget about implementors of synthesis tools. Once simulating multiple
Click to expand...
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 ...
I am a GOD! DEFAULTS ARE A MUST!!! :eek:)
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top