On 18/11/2011, at 6:09 AM, Serguey Zefirov wrote:
> It said "a.vhd:10:21: no matching resolution function for 'x_res'".
>
> If I delete "subtype x is rec;" line and make x a record instead of
> subtype, all went fine.
>
> This is clearly a bug.
I'm afraid to see your resolution function with 3 or more elements in a record.
I've seen Ben Cohen's book Real chip design and verification using Verilog and
VHDL and am aware of Jim Lewis wanting to do introspection. The idea being to
have some set of default functions for dealing with record elements instead of
making the VHDL code author grow their own. Integers do seem a little extreme.
Another way to eliminate the analysis error would be to change rec to a
non-record type:
entity a is end entity a;
architecture b of a is
type rec is ('A','B','C','D'); -- type rec is record
-- a : integer;
-- end record;
subtype x is rec;
type x_vec is array (natural range <>) of x;
function x_res(to_resolve : x_vec) return x;
subtype rx is x_res x;
function x_res(to_resolve : x_vec) return x is
variable r : x;
begin
-- r.a := 0;
return r;
end function x_res;
begin
end architecture b;
Which matches how std_logic_1164 implements std_logic_vector in a package.
Translating to a package:
package a_pkg is
type rec is ('A','B','C','D'); -- type rec is record
-- a : integer;
-- end record;
subtype x is rec;
type x_vec is array (natural range <>) of x;
function x_res (to_resolve: x_vec) return x;
subtype rx is x_res x;
end a_pkg;
package body a_pkg is
function x_res (to_resolve: x_vec) return x is
variable r: x;
begin
-- r.a := 0;
return r;
end function x_res;
end a_pkg;
And the behavior matches. So it's clearly unhappy about the subtype
declaration for the record possibly due to it being an unconstrained subtype
(because as you point out removing the subtype declaration passes analysis):
entity a is end entity a;
architecture b of a is
type x is record -- type rec is record
a : integer;
end record;
--subtype x is rec;
type x_vec is array (natural range <>) of x;
function x_res(to_resolve : x_vec) return x;
subtype rx is x_res x;
function x_res(to_resolve : x_vec) return x is
variable r : x;
begin
r.a := 0;
return r;
end function x_res;
begin
end architecture b;
The error message
a.vhd:10:21: no matching resolution function for 'x_res'
occurs in sem_types.adb, procedure Sem_Resolution_Function () which peforms two
predicate tests (functions) - Is_Overload_List() and if that fails
Is_A_Resolution_Function().
The purpose is to return the IIR resolution function 'pointer'. You get the
error when it doesn't get returned.
The overload test determines whether names are overloaded and whether they can
be clearly distinguished. That can involve calling Is_A_Resolution_Function()
as well.
If there is no requirement to resolve overloaded names Is_A_Resolution_Function
() is called.
First Off this is in the context of IEEE Std 1076-1993 (VHDL-93,V93). ghdl is
mostly VHDL-93 compliant and iss capable of V87 compliance in this bit, but not
V08.
Analyzing x_res for name overload isn't an issue when analyzing a.vhdl (entity
a, architecture b of a). There appears no particular difference in scope and
visibility for a type declaration versus a subtype declaration. More than
likely this occurs in one of the four semantic checks in
Is_A_Resolution_Function() found in the second paragraph of section 2.4
Resolution functions (IEEE Std 1076-1993):
A resolution function must be a pure function (see 2.1); moreover, it must have
a single input parameter of class constant that is a one-dimensional,
unconstrained array whose element type is that of the resolved signal. The type
of the return value of the function must also be that of the signal. Errors
occur at the place of the subtype indication containing the name of the
resolution function if any of these checks fail (see 4.2).
--
The error message during analysis of a.vhdl occurs when a valid resolution
function pointer has not been found.
The four semantic checks are in 7 different evaluations in Is_A_Resolution
Function() I did modify a copy of sem_types.adb to see which if any of them
fails once I get a development environment back together. The underlying
problem may exhibit other symptoms, too.
As far as Gna being unfriendly, I don't have full control of ghdl there, nor
can I upload releases to ghdl.free.fr which apparently requires the originating
point to be within free.fr. There's also the issue of numbers of ghdl
contributors. I figure it's more than a man year to go through and make ghdl
fully VHDL-93 compliant including a sizable audit and setting up regression
testing.
Tristan spent the last couple of years in bug fix mode because of lack of
qualified help and is currently off doing intensive Ada stuff. He does notice
when bugs are reported to Gna. We've talked about re-hosting ghdl but what we
really could use more contributors. We could manage to nudge Tristan's elbow
enough for him to do his part and with enough activity it would prompt changes.
I've also got other things going on as well, limiting my time.
The requirements for a contributor are relatively mild. One would need to be a
bit of VHDL lawyer, conversant with the standard, and willing to go to the book
of the law so to speak. A contributor would need to be comfortable writing
VHDL and willing to deal with the differences between VHDL and Ada 95.
Personally gcc has evolved faster than I've kept up, but at some point there's
bound to be a bit of gcc front end effort. If someone can design and implement
a digital design in VHDL they likely have the right qualities to learn
everything as they go. ghdl uses a handwritten lexer and parser, which
eliminates care and feeding of domain specific language modeling tools.
And if anyone has any idea on how to revitalize ghdl development don't be
afraid to speak up. If you have a good story don't be surprised if your
efforts catch on.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
