VHDL Types/Subtypes

[sabatini]

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.

 

[Jonathan Bromley]

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 ;

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
(e-mail address removed)
http://www.MYCOMPANY.com

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

 

[sabatini]

Hi Jonathan,

Good so far.


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?


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

 

[James Unterburger]

Try changing the word "subtype" to "alias" in b_pkg.

 

[sabatini]

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

 

[James Unterburger]

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--

 

[Jonathan Bromley]

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!
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

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

 

[Brian Drummond]

Cool. I didn't know that little trick. Many thanks!

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

 

[Jonathan Bromley]

Johnathan, if *you* didn't know it, I'm left worrying how many design
tools don't know it either!

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...

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
(e-mail address removed)
http://www.MYCOMPANY.com

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