#941 VHDL attributes not supported

devel
open
nobody
VHDL (4)
5
2014-08-25
2013-12-09
Olof Kindgren
No

The following test fails to compile due to attributes being treated as syntax errors

library ieee;
use ieee.std_logic_1164.all;

entity e is
  port (
    clk : in  std_logic;
    rst : in  std_logic;
    q   : out std_logic);
end e;

architecture a of e is

  signal r : std_logic;

  attribute syn_keep : boolean;
  attribute syn_keep of r : signal is true;

begin

   q <= r;

   process(clk)
   begin
     if rising_edge(clk) then
       if rst = '1' then
         r <= '0';
       else
         r <= not r;
       end if;
     end if;
   end process;
end a;

Discussion

  • Olof Kindgren
    Olof Kindgren
    2013-12-11

    WIP patch for this issue. Looking for a few pointers
    1. Is there a preferred way to issue a warning that support is missing without aborting the parsing? sorrymsg looks like it stops the parser
    2. Is it OK to cheat a bit and use IDENTIFIER instead of implementing all the sub rules, as attribute_{declaration,specification} are the only rules that use them anyway?

    diff --git a/vhdlpp/parse.y b/vhdlpp/parse.y
    index 83e0c2e..3b934f2 100644
    --- a/vhdlpp/parse.y
    +++ b/vhdlpp/parse.y
    @@ -451,6 +451,23 @@ association_list
           }
       ;
    
    +/* FIXME: Attribute declaration and specification are not implemented. These rules
    +are just to make files with attribute declarations/specifications parsable.
    +Probaby good enough for now as many (most?) attributes are for synthesis*/
    +attribute_declaration
    +  : K_attribute IDENTIFIER ':' subtype_indication ';'
    +      {
    +        /*sorrymsg(@1, "Attribute declaration is not yet supported\n");*/
    +      }
    +  ;
    +
    +attribute_specification
    +  : K_attribute IDENTIFIER K_of entity_specification K_is expression ';'
    +      {
    +        /*sorrymsg(@1, "Attribute specification is not yet supported\n");*/
    +      }
    +  ;
    +
     binding_indication
       : K_use entity_aspect_opt port_map_aspect_opt generic_map_aspect_opt
           { $$ = $2;
    @@ -502,6 +519,10 @@ block_declarative_item
    
       | subprogram_body
    
    +  | attribute_declaration
    +
    +  | attribute_specification
    +
           /* Various error handling rules for block_declarative_item... */
    
       | K_signal error ';'
    @@ -964,6 +985,26 @@ entity_aspect_opt
       | { $$ = 0; }
       ;
    
    +entity_class
    +  : K_entity
    +  | K_architecture
    +  | K_configuration
    +  | K_procedure
    +  | K_function
    +  | K_package
    +  | K_type
    +  | K_subtype
    +  | K_constant
    +  | K_signal
    +  | K_variable
    +  | K_component
    +  | K_label
    +  | K_literal
    +  | K_units
    +  | K_group
    +  | K_file
    +  ;
    +
     entity_declaration
       : K_entity IDENTIFIER
         K_is generic_clause_opt port_clause_opt
    @@ -989,6 +1030,12 @@ entity_declaration
           }
       ;
    
    +/*FIXME: IDENTIFIER should be entity_name_list. Cheating for now to
    +allow no op parsing of signal attributes*/
    +entity_specification
    +  : IDENTIFIER ':' entity_class
    +  ;
    +
     enumeration_literal
       : IDENTIFIER
           { list<perm_string>*tmp = new list<perm_string>;
    
     
  • Cary R.
    Cary R.
    2013-12-12

    Here's a little philosophy regarding how messages should be tagged in Icarus.

    Error is for a real syntax error and should eventually abort.

    Sorry is for things that are not supported and may be required so they should also eventually abort.

    Warning is to inform the user that something may not be correct but an appropriate default is available so it will be used and the compilation will not abort.

    All these should display the file and line information if it is available.

    So with what you have said these messages should probably be warnings and you can use cerr to display the message. See the Verilog compiler parse.y (in the top directory) for an example. For the entity specification can you use a list of identifiers to get the full behavior?

    I don't know VHDL very well, but if attributes are not required to effect the simulation or be available using some interface during the simulation just ignoring them without a warning should be okay.

     
    • On 12/11/2013 04:12 PM, Cary R. wrote:

      Warning is to inform the user that something may not be correct but an
      appropriate default is available so it will be used and the compilation
      will not abort.

      Warnings are only for things that are legal, but possibly wrong.
      I think that's what you meant, but not quite what you said.

      --
      Steve Williams "The woods are lovely, dark and deep.
      steve at icarus.com But I have promises to keep,
      http://www.icarus.com and lines to code before I sleep,
      http://www.picturel.com And lines to code before I sleep."