> On 14/06/2016, at 6:26 am, Tristan Gingold <tging...@free.fr> wrote:
>
> On 12/06/16 15:26, Walter F.J. Mueller wrote:
>> Hi *,
>>
>> the Xilinx vivado tool chain creates simulation model where signal are
>> decorated with an 'attribute RTL_KEEP'. That can happen even for port
>> signals.
>>
>> ghdl apparently does not allow that port signals are decorated and aborts
>> with an error
>> ...:30690:25: no named entities '...' in declarative part
>>
>> A reproducer is appended. Apparently ghdl considers only locally declared
>> signals, but not ports, in this case.
>>
>> The syntax of attribute allows many entity_classes, one is 'signal', but
>> 'port' isn't listed. My understanding is that port is, for these purposes,
>> simply a signal I see no reason why it can't be decorated with an
>> attribute.
>>
>> It be great if that would be corrected in a future release.
>
> I am pretty sure that ghdl is correct here and Xilinx model is not.
> But this could be relaxed with -frelax-rules
>
> (Do not hesitate to open an issue on github).
>
> Regards,
> Tristan.
From IEEE Std 1076-1993, 5.1 Attribute specification, paragraph 9:
An attribute specification for an attribute of a design unit (i.e., an entity
interface, an architecture, a configuration, or a package) must appear
immediately within the declarative part of that design unit. Similarly, an
attribute specification for an attribute of an interface object of a design
unit, subprogram, or block statement must appear immediately within the
declarative part of that design unit, subprogram, or block statement. An
attribute specification for an attribute of a procedure, a function, a type, a
subtype, an object (i.e., a constant, a file, a signal, or a variable), a
component, literal, unit name, group, or a labeled entity must appear within
the declarative part in which that procedure, function, type, subtype,
object,component, literal, unit name, group, or label, respectively, is
explicitly or implicitly declared.
--
(The above text is found in the -2008 standard with little change).
This means your attribute declaration and attribute specification are found in
the wrong place, while:
library ieee;
use ieee.std_logic_1164.all;
entity bad_attribute is
port (
A : in std_logic;
B : in std_logic;
C : out std_logic
);
attribute RTL_KEEP : string;
attribute RTL_KEEP of C : signal is "yes";
end bad_attribute;
architecture syn of bad_attribute is
-- attribute RTL_KEEP : string;
-- attribute RTL_KEEP of C : signal is "yes";
begin
C <= A and B;
end syn;
is valid and accepted by ghdl. Notice the attribute declaration is visible for
other uses in any architecture as well.
Tristan has a lot of the semantic rules referenced in ghdl source code against
the standard. You can trace from the error message (" in declarative part") or
use the standard as a semantic reference.
The message is generated in sem_specs.adb, a procedure
Sem_Attribute_Specification. You need the standard to find the semantic rule in
this case (paragraph 9 is not excerpted, but reading the source would lead you
to LRM93 5.1). Personally I understood the distinction between attribute
declaration and specification (associating the attribute with the object)
implied by the error message so jumped to the appropriate place in the
standard.
It's not possible to determine the validity or invalidity of a design
specification without referencing the standard. Historically a validation suite
was produced that purportedly checks 'testable sentences' in the Language
Reference Manual (the standard, in this case -1987 with some -1993 support).
Those test cases and additional ones resulting from issues/tickets having been
opened on github, sourceforge or gna plus new revision language features being
added are found in the testsuite accompanying the ghdl source code in Tristan's
github repository.
I'd suggest submitting a bug report to Xilinx so their tool can be improved. I
don't believe it's possible for them to successfully argue there tool's
operation is standard compliant in this case.
As to how an error is found in Xilinx Vivado's ISIM, there are semantic errors
that creep into new (-ish) implementations due to the manual method required
for identifying semantic restrictions found in the standard and the lack of a
valid published set of test cases (the earlier effort abandoned due to effort
and cost (lack of support, having a private accurate validation suite can also
be seen as a competitive advantage). It doesn't help that the effort hast to be
largely redone for each revision of the standard. VHDL tool developers need to
be somewhere between guild masters, religious scholars (or VHDL lawyers) and
historians (VHDL dates from 1985).
(Don't let Tristan's modesty understate how much work has gone into ghdl).
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
