equivalent types in different packages

L

Lolo

This is a question about how to connect signals having
"equivalent" types but defined in different packages.

Here is the skeleton of the problem:

----------------------
package P1:
type t is <something>;
end
----------------------
use P1;
entity M1 is port (a: in t);
----------------------
package P2:
type t is <something> -- exactly the same as in P1
end
----------------------
use P2;
entity M2 is port (b: out t);
-----------------------
package P3:
type t is <something> -- the same as in P1 and P2
end
-----------------------
use P3;
entity M3 is port (...);
architecture of M3 is
signal x: t;
begin
c1:M1 port map (a=>x);
c2:M2 port map (b=>x);
end

Modelsim and other VHDL tools complain because a, b and x have different types.
This is because they consider the types as being different because in different
packages. How to **simply** make them understand they are the same types ?
I'd like to apply changes to P3 and/or M3 only.

My current solution consists in modifying M3 as follows:

use P3;
entity M3 is port (...);
architecture of M3 is
signal x: t;
signal x_aux_1: work.P1.t;
signal x_aux_2: work.P2.t;
begin

x_aux_1 <= work.P1.t(x);
c1:M1 port map (a=>x_aux_1);
x <= t(x_aux_2);
c2:M2 port map (b=>x_aux_2);
end

Can anybody propose a nicer solution ? Possibly without creating additional
signals ?

Thanks in advance.

Laurent Arditi
Esterel Technologies
Laurent.Arditi@<company name, replace blank with dash>.com
 
L

Lolo

Thanks Jonathan,
your solution fits perfectly in my requirements.
Unfortunately, it doesn't always pass into Modelsim,
depending on what the type T is:

compiles fine:
subtype std_logic_3 is std_logic_vector(2 downto 0);
type T is array (3 downto 0) of std_logic_3;

doesn't compile with Modelsim:
type boolean_3 is array (2 downto 0) of boolean;
type T is array (3 downto 0) of boolean_3;
==>
** Error: abrotab2val.vhd(98): Illegal type conversion

I recall the types have exactly the same definitions in the different
packages. Do you have any explanation for that ?

(e-mail address removed) (remove all w)
 
J

Jonathan Bromley

doesn't compile with Modelsim:
type boolean_3 is array (2 downto 0) of boolean;
type T is array (3 downto 0) of boolean_3;
==>
** Error: abrotab2val.vhd(98): Illegal type conversion

I recall the types have exactly the same definitions in the different
packages. Do you have any explanation for that ?

I am fairly sure that the reason is...

P1.T and P2.T are not closely related, because:
the elements of P1.T are of type P1.boolean_3,
but:
the elements of P2.T are of type P2.boolean_3.

If this is the problem, then writing a not-very-difficult
explicit type conversion function will easily fix it.

Is there really, truly, positively, definitely no way you can
put the type definitions in a single common package, and
spare yourself all this pain?
--
Jonathan Bromley, 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.
 
L

Lolo

You're right, the elements of *.T are not closely related.

Actually, I think the type conversions will definitively be very heavy (I hate
this language !!!). So I managed to build a single package containing all types
used by modules. This is much simpler.

Thanks again,

Laurent.

doesn't compile with Modelsim:
type boolean_3 is array (2 downto 0) of boolean;
type T is array (3 downto 0) of boolean_3;
==>
** Error: abrotab2val.vhd(98): Illegal type conversion

I recall the types have exactly the same definitions in the different
packages. Do you have any explanation for that ?

I am fairly sure that the reason is...

P1.T and P2.T are not closely related, because:
the elements of P1.T are of type P1.boolean_3,
but:
the elements of P2.T are of type P2.boolean_3.

If this is the problem, then writing a not-very-difficult
explicit type conversion function will easily fix it.

Is there really, truly, positively, definitely no way you can
put the type definitions in a single common package, and
spare yourself all this pain?
--
Jonathan Bromley, 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.
 

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

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top