IF syntax error in simple VHDL code

Question

I'm pretty new to vhdl and I can't seem to find the error in my code, I keep getting these errors.

alarm.vhdl (line 19, col 5):  (E10) Syntax error at/before reserved symbol 'if'.
Error occurred within 'ARCHITECTURE' at line 16, column 28 in alarm.vhdl.
alarm.vhdl (line 31, col 9):  (E56) Expected ;, but got IF
alarm.vhdl (line 31, col 9):  (E10) Syntax error at/before reserved symbol 'if'.
alarm.vhdl (line 33, col 4):  (E10) Syntax error at/before reserved symbol 'end'.

Is there something wrong with my if statement?

library IEEE;
use ieee.std_logic_1164.all;

entity alarm is
  port( master_switch:       in    std_logic;       
        door_sensor:         in    std_logic;
        wheel_sensor:        in    std_logic;
        clock:               in    std_logic;
        Z :                  out   std_logic;
        J :                  in    std_logic_vector(1 downto 0);
        K :                  in    std_logic_vector(1 downto 0);
        Q :                  inout std_logic_vector(1 downto 0);
       Qcomp :               inout std_logic_vector(1 downto 0) );
end alarm;

architecture behav of alarm is

begin
if clock='1' then

J(1) <= Qcomp(1) AND Q(0) AND master_switch AND door_sensor;
K(1) <= Q(0) OR Q(1);

J(0) <= Qcomp(0);
K(0) <= Qcomp(1) OR (Q(0) AND Q(1));

Q(1) <= ((NOT K(1)) AND Q(1)) OR (J(1) AND Qcomp(1));
Q(0) <= ((NOT K(0)) AND Q(0)) OR (J(0) AND Qcomp(0));

Z <= Q(1) AND Qcomp(0);
 end if;
end;
end behav;

Answer 1

on nebulous syntax error messages

alarm.vhdl (line 19, col 5):  (E10) Syntax error at/before reserved symbol 'if'.
Error occurred within 'ARCHITECTURE' at line 16, column 28 in alarm.vhdl.

This is caused by a lack of a label preceding the reserved word if, presumed to be a generate statement scheme.

The issue being as Brian says that an if statement which is a sequential statement can only appear in a process, or a subprogram (a function or a procedure).

The apparent poor quality of the error message comes from how the error is detected in the parser.

The statements found inside an architecture statement part are concurrent statements:

 architecture_statement_part ::=
      { concurrent_statement }

The curly brackets meaning zero or more concurrent statements are allowed (An architecture statement part can be empty).

 concurrent_statement ::=
       block_statement
     | process_statement
     | concurrent_procedure_call_statement
     | concurrent_assertion_statement
     | concurrent_signal_assignment_statement
     | component_instantiation_statement
     | generate_statement

A block statement begins with the reserved word block.

A process statement beginning with the reserved word process or postponed.

A concurrent procedure call statement beginning with the a procedure name or the reserved word postponed.

A concurrent assertion statement beginning with the reserved word assert.

A concurrent signal assignment statement beginning with the name of a signal or the keyword postponed.

A component instantiation statement beginning with the reserved word component, or the reserved word entity, or the reserved word configuration, or the name of an entity.

All the above concurrent statements may be optionally labeled, the label preceding either a reserved word or a name (an identifier, which can be a selected name).

The last choice for the generate statement requires a label and can have the reserved word if.

 generate_statement ::=
     generate_label :
         generation_scheme generate
             [ { block_declarative_item }
         begin ]
             { concurrent_statement }
         end generate [ generate_label ] ;

 generation_scheme ::=
      for generate_parameter_specification
   | if condition

 label ::=  identifier

We see that after a mandatory label we'd expect to see the generation scheme, either indicated by the the reserved word if or the reserved word for.

The parser tested for these in order. You could note that concurrent_statement is not a terminal. One of the various concurrent statements would be a terminal production. Without the ability to hang an error message on a non-terminal everything will get swept up in the last concurrent statement choice (generate statement).

Rather than tell you there's something wrong with the generate statement:

ghdl -a alarm.vhdl
alarm.vhdl:19:1: a generate statement must have a label
alarm.vhdl:19:14: 'generate' is expected instead of 'then'

The parser you used told there's simply something wrong around the reserved word if. Although there is only one concurrent statement that can 'start' with if, the lack of a mandatory label aside.

A VHDL parser can operate with a look ahead of one, assuming semantic predicates are used (e.g. entity_name).

It's sometime possible to use a larger look ahead to avoid backtracking (which makes no sense in the last concurrent statement choice). There was an expression followed by the reserved word then, which disqualifies the current concurrent statement as a generate statement.

It's possible to produce a better error message:

nvc -a alarm.vhdl
** Error: syntax error, unexpected if, expecting process
    File alarm.vhdl, Line 19
    if clock='1' then
    ^^

This determining that if is inappropriate without being preceded by a label, and in the case of nvc noting that an if statement is a sequential statement, allowed in, in this case a process statement.

(Notice Brian's answer said "The if statement here must be in a process,..").

Note that neither ghdl nor nvc preceded beyond this error. ghdl treats the current portion of the design description as a generate statement (no non-terminal error messages), while nvc is capable of non-terminal error messages (not using a bison construct in this case). Your tool vendor's parser throws up it's hands a bit sooner but attempts a poor non-terminal error message.

However, there's no excuse or need for preceding further:

alarm.vhdl (line 31, col 9):  (E56) Expected ;, but got IF
alarm.vhdl (line 31, col 9):  (E10) Syntax error at/before reserved symbol 'if'.
alarm.vhdl (line 33, col 4):  (E10) Syntax error at/before reserved symbol 'end'.

Why is an unknown concurrent statement choice being attempted when any error in parsing is sufficient to invalidate the output? There's an attempt to give more context, however referencing line and columns as well as reserved words is likely not the way to do it.

You could also note that nvc's error message can have shortcomings. Label the if statement and you get:

nvc -a alarm.vhdl
** Error: syntax error, unexpected then
    File alarm.vhdl, Line 20
    if clock='1' then
                 ^^^^

The shortcoming here is that it doesn't tell you it's parsing a generate statement (nor does you're tool vendor's parser).

While ghdl gets a bit more specific:

ghdl -a alarm.vhdl
alarm.vhdl:20:14: 'generate' is expected instead of 'then'
ghdl: compilation error

And one of the things all three of these parsers has in common is that they all required VHDL language expertise to interpret.

In these cases a tool vendor could provide an expanded narrative optionally to explain how the message was produced.

For instance Modelsim has a verror facility which produces a narrative description when provided with an error number.

In your case you appear to be synthesizing the VHDL design description directly. In general a synthesis tool assumes some familiarity with VHDL, which might indicate you'd be better off simulating a design first or failing that based on complexity using a different analyzer to root out syntax errors.

Your error messages appear to come from Cypress's WARP, the Reference Manual (1996, PDF,1.4 MB) tells us:

E10 :Syntax error at/before reserved symbol ‘%s’.
You used a reserved word in an illegal fashion, e.g., as a signal or variable name.

And you can see the message is a bit less than helpful.

WARP is considered obsolete intended to support a discontinued CPLD line and discontinued itself in 2012, otherwise lacking in support. It reinforces the notion of analyzing your VHDL designs with another tool.

Answer 2

The if statement here must be in a process, with clock in its sensitivity list. (Also you want to use rising_edge(clock) rather than clock = '1' for correct synthesis)