VHDL Types/Subtypes

Guest
Hi all,

Could anyone of you explain why the following code fails with the
following error (Modelsim SE PLUS 6.2d):

** Error: tc.vhd(20): (vcom-1136) Unknown identifier "val0".

N.B line 20 is the line: signal ren_enum_b1 : ren_enum := val0 ;

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

package a_pkg is
type enum is (val0, val1, val2, val3) ;
subtype ren_enum is enum ;
end package a_pkg ;

package b_pkg is
subtype ren_enum is work.a_pkg.enum ;
end package b_pkg ;

--===================================================

entity tc is
end entity tc ;

use work.b_pkg.all ;

architecture beh of tc is
signal ren_enum_a : work.a_pkg.ren_enum := work.a_pkg.val0 ;
signal ren_enum_b0 : ren_enum ;
signal ren_enum_b1 : ren_enum := val0 ;
begin
end architecture beh ;

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

It seem that ren_enum_a inherits all the values from the base type
enum, while the other two (ren_enumb0/1) don't! Why?

Regards,

Andrea

P.S. Synopsys Design Compiler exibits the same behavior.
 
On 8 Mar 2007 04:38:44 -0800, sabatini@tiscali.nl wrote:

Hi all,

Could anyone of you explain why the following code fails with the
following error (Modelsim SE PLUS 6.2d):
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

package a_pkg is
type enum is (val0, val1, val2, val3) ;
subtype ren_enum is enum ;
end package a_pkg ;
Click to expand...
Good so far.

package b_pkg is
subtype ren_enum is work.a_pkg.enum ;
end package b_pkg ;
Click to expand...
b_pkg has not imported the literal names. It's a standard gotcha:
importing a type name does not import its literal names.

I don't know of a straightforward way to get enum definitions
through a chain of package imports. It's an ugly problem.
I think you will have to go back to the obvious solution:
import the original defining package directly.

Maybe Jim Lewis can indicate whether VHDL-200x can offer
any help here?

signal ren_enum_b1 : ren_enum := val0 ; --ERROR
Click to expand...
I'm pretty sure that this would work:
signal ren_enum_b1 : ren_enum := work.a_pkg.val0 ;

P.S. Synopsys Design Compiler exibits the same behavior.
Click to expand...
So it should :)
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

On Mar 8, 3:53 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On 8 Mar 2007 04:38:44 -0800, sabat...@tiscali.nl wrote:

Hi all,

Could anyone of you explain why the following code fails with the
following error (Modelsim SE PLUS 6.2d):
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

package a_pkg is
type enum is (val0, val1, val2, val3) ;
subtype ren_enum is enum ;
end package a_pkg ;

Good so far.

package b_pkg is
subtype ren_enum is work.a_pkg.enum ;
end package b_pkg ;

b_pkg has not imported the literal names. It's a standard gotcha:
importing a type name does not import its literal names.

I don't know of a straightforward way to get enum definitions
through a chain of package imports. It's an ugly problem.
I think you will have to go back to the obvious solution:
import the original defining package directly.

Maybe Jim Lewis can indicate whether VHDL-200x can offer
any help here?

signal ren_enum_b1 : ren_enum := val0 ; --ERROR

I'm pretty sure that this would work:
signal ren_enum_b1 : ren_enum := work.a_pkg.val0 ;
Click to expand...
Correct. I already knew that but this is not what I need. The point is
that I do not want to change the source code of the entity (that in my
case is an already existing module) but only the package reference
from a_pkg to b_pkg. I hoped that creating putting in b_pkg the re-
definition of the type would do the trick.

Regards,

Andrea

P.S. Synopsys Design Compiler exibits the same behavior.

So it should :)
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
 
Try changing the word "subtype" to "alias" in b_pkg.

sabatini@tiscali.nl wrote:
Hi Jonathan,

On Mar 8, 3:53 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

On 8 Mar 2007 04:38:44 -0800, sabat...@tiscali.nl wrote:


Hi all,

Could anyone of you explain why the following code fails with the
following error (Modelsim SE PLUS 6.2d):
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

package a_pkg is
type enum is (val0, val1, val2, val3) ;
subtype ren_enum is enum ;
end package a_pkg ;

Good so far.


package b_pkg is
subtype ren_enum is work.a_pkg.enum ;
end package b_pkg ;

b_pkg has not imported the literal names. It's a standard gotcha:
importing a type name does not import its literal names.

I don't know of a straightforward way to get enum definitions
through a chain of package imports. It's an ugly problem.
I think you will have to go back to the obvious solution:
import the original defining package directly.

Maybe Jim Lewis can indicate whether VHDL-200x can offer
any help here?


signal ren_enum_b1 : ren_enum := val0 ; --ERROR

I'm pretty sure that this would work:
signal ren_enum_b1 : ren_enum := work.a_pkg.val0 ;


Correct. I already knew that but this is not what I need. The point is
that I do not want to change the source code of the entity (that in my
case is an already existing module) but only the package reference
from a_pkg to b_pkg. I hoped that creating putting in b_pkg the re-
definition of the type would do the trick.

Regards,

Andrea


P.S. Synopsys Design Compiler exibits the same behavior.

So it should :)
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
 
Hi James,

I just saw your post and I immediately compilerd the modified code and
everything was fine, no problem importing literals names at all! I am
curious to see if also the synthesizer accepts this. Thanks for the
tip!

Regards,

Andrea

On Mar 9, 8:03 pm, James Unterburger <jam...@europa.com> wrote:
Try changing the word "subtype" to "alias" in b_pkg.

sabat...@tiscali.nl wrote:
Hi Jonathan,

On Mar 8, 3:53 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

On 8 Mar 2007 04:38:44 -0800, sabat...@tiscali.nl wrote:

Hi all,

Could anyone of you explain why the following code fails with the
following error (Modelsim SE PLUS 6.2d):
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

package a_pkg is
typeenum is (val0, val1, val2, val3) ;
subtyperen_enum is enum ;
end package a_pkg ;

Good so far.

package b_pkg is
subtyperen_enum is work.a_pkg.enum ;
end package b_pkg ;

b_pkg has not imported the literal names. It's a standard gotcha:
importing atypename does not import its literal names.

I don't know of a straightforward way to get enum definitions
through a chain of package imports. It's an ugly problem.
I think you will have to go back to the obvious solution:
import the original defining package directly.

Maybe Jim Lewis can indicate whetherVHDL-200x can offer
any help here?

signal ren_enum_b1 : ren_enum := val0 ; --ERROR

I'm pretty sure that this would work:
signal ren_enum_b1 : ren_enum := work.a_pkg.val0 ;

Correct. I already knew that but this is not what I need. The point is
that I do not want to change the source code of the entity (that in my
case is an already existing module) but only the package reference
from a_pkg to b_pkg. I hoped that creating putting in b_pkg the re-
definition of thetypewould do the trick.

Regards,

Andrea

P.S. Synopsys Design Compiler exibits the same behavior.

So it should :)
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
 
You're welcome.
It works because creating an alias of a type will cause
implicit aliases for the type's implicit decls (this includes
enumeration literals and implicit operators) to be created
(in b_pkg; the use work.b_pkg.all makes them all visible
to the architecture). See 4.3.3.2 items c) and e).

--JamesU--
 
On Tue, 13 Mar 2007 12:14:07 -0700, James Unterburger
<jamesu@europa.com> wrote:

You're welcome.
It works because creating an alias of a type will cause
implicit aliases for the type's implicit decls (this includes
enumeration literals and implicit operators) to be created
(in b_pkg; the use work.b_pkg.all makes them all visible
to the architecture). See 4.3.3.2 items c) and e).
Click to expand...
Cool. I didn't know that little trick. Many thanks!
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Wed, 14 Mar 2007 08:46:45 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Tue, 13 Mar 2007 12:14:07 -0700, James Unterburger
jamesu@europa.com> wrote:

You're welcome.
It works because creating an alias of a type will cause
implicit aliases for the type's implicit decls (this includes
enumeration literals and implicit operators) to be created
(in b_pkg; the use work.b_pkg.all makes them all visible
to the architecture). See 4.3.3.2 items c) and e).

Cool. I didn't know that little trick. Many thanks!
Click to expand...
Johnathan, if *you* didn't know it, I'm left worrying how many design
tools don't know it either!

But potentially, it looks very useful...

- Brian
 
On Wed, 14 Mar 2007 15:59:04 +0000, Brian Drummond
<brian_drummond@btconnect.com> wrote:

Johnathan, if *you* didn't know it, I'm left worrying how many design
tools don't know it either!
Click to expand...
You overestimate me... there is LOTS of VHDL that I don't
use regularly and am not totally familiar with!
Don't ask me about guarded blocks, for example. Too hard :)

I have not taken much notice of "alias" because there
are usually other ways to get the equivalent effect
(not in this case,though!) and in the past it has had
fairly limited synthesis tool support.

But potentially, it looks very useful...
Click to expand...
Agreed.
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top