Forum: FPGA, VHDL & Co. Syntax Error HDL Compiler 806


von hdler (Gast)


Lesenswert?

Hallo,

Der HDL Compiler hat folgende Fehlermeldung ausgegeben und ich verstehe 
nicht wo da ein Syntax fehler sein soll!?


ERROR:HDLCompiler:806 - 
"C:/Users/hdler/workspace_FPGA/uart/uart_rx/baud_gen.vhd" Line 52: 
Syntax error near "process".

ERROR:HDLCompiler:806 - 
"C:/Users/hdler/workspace_FPGA/uart/uart_rx/baud_gen.vhd" Line 59: 
Syntax error near "Behavioral"





1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
4
5
6
entity baud_gen is
7
    Port ( clk : in  STD_LOGIC;
8
           reset : in  STD_LOGIC;
9
           tick : out  STD_LOGIC);
10
end baud_gen;
11
12
architecture Behavioral of baud_gen is
13
14
signal clk163_next, clk163_reg: unsigned(7 downto 0);
15
signal s_pulse: std_logic;
16
17
begin
18
19
  process(clk, reset)
20
  begin
21
    if reset='1' then
22
      clk163_reg <= (others => '0');
23
    else if (clk 'event and clk='1') then
24
      clk163_reg <= clk163_next;
25
    end if;
26
  end process;
27
  
28
  clk163_next <= (others=>'0') when clk163_reg=(div-1) else
29
            clk163_reg + 1;
30
  s_pulse <= '1'  when clk163_reg=0 else '0';
31
32
33
end Behavioral;

von Samuel C. (neoexacun)


Lesenswert?

else if -> elsif

von Fitzebutze (Gast)


Lesenswert?

Du nutzt 'unsigned' und hast die numeric_std nicht eingebunden.
Und wo ist 'div' deklariert?
Und gleich schon mal angewöhnen:
- keinen asynchronen Reset nutzen wenn nicht zwingend nötig
- rising_edge(clk) liest sich besser als die alte 'event-Notation

Tip: Nutze ghdl um sauberes VHDL zu entwerfen und simulieren.

von hdler (Gast)


Lesenswert?

Danke für die Tipps und Links!

Ja div ist eine Konstante: 163.
Habe ich ganz vergessen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Mein vorschlag: nimm Integer für den Zähler:
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use ieee.numeric_std.all;
4
5
architecture Behavioral of baud_gen is
6
7
constant div: integer := 163;
8
signal clk163: integer range 0 to 163 := 0;
9
signal s_pulse: std_logic;
10
11
begin
12
13
  process(clk, reset)
14
  begin
15
    if reset='1' then
16
       clk163 <= 0;
17
    elsif riging_edg(clk) then
18
       if clk163<div then
19
          clk163  <= clk163+1;
20
          s_pulse <= '0';
21
       else
22
          clk163  <= 0;
23
          s_pulse <= '1';
24
       end if;
25
     end if;
26
  end process;
27
28
end Behavioral;
Und denk nochmal ausgeibig über die Notwendigkeit des Reset nach. Und 
wenn du da wirklich durch 163 teilen willst, dann darfst du nur von 
0..162 zählen. Der Effekt, wenn du von 0..163 zählst, nennt sich 
"Off-by-One".

: Bearbeitet durch Moderator
von Style is helpful (Gast)


Lesenswert?

1
  P_BUFFERING:PROCESS(clk,reset)
2
  BEGIN
3
    IF reset = '1' THEN
4
      clk163_reg <= 0;
5
    ELSIF rising_edge(clk) THEN
6
      clk163_reg <= clk163_next;
7
    END IF;
8
 END PROCESS P_BUFFERING;

von Style is helpful (Gast)


Lesenswert?

Lothar M. schrieb:
> elsif riging_edg(clk) then

mal die Tastatur nachjustieren, da sollte wohl
 rising_edge(clk)
getippt werden.

von Vancouver (Gast)


Lesenswert?

Hatten wir alles schon mal, aber da wir gerade wieder davon sprechen, 
ein paar Anmerkungen zum Thema Reset:

- Bei FPGA kann man oft auf den Reset verzichten, weil die FFs nach der 
Konfiguration in einem definierten Zustand sind und man ihnen auch einen 
Defaultwert geben kann. Bei ASICs funktioniert das nicht. Diese Zeile:
1
signal clk163: integer range 0 to 163 := 0;

führt bei der ASIC-Synthese zu einer dunkelroten Warning, die man besser 
nicht ignorieren sollte. ASIC-FFS haben nach dem Power-Up erstmal 
zufällige Werte, hier ist ein Reset zwingend erforderlich.

- Wir hatten kürzlich wieder ein FPGA-Projekt, bei dem zwingend ein 
asynchroner Reset gefordert war, aus einem einfachen Grund: Das ganze 
System muss auch bei einem Totalausfall des Clockoszillators noch 
zuverlässig resettet werden können. Diese Forderung ist bei vielen 
sicherheitskritischen Anwendungen anzutreffen.


- Das große Problem beim asynchronen Reset ist, dass ein FF metastabil 
werden kann, wenn der Reset zu nahe bei einer aktiven Taktflanke 
losgelassen wird. Um das zu verhindern, verwendet man Synchronizer, die 
die  aktive Flanke asynchron durchreichen und die inaktive Flanke 
synchronisieren.

Das ganze Reset-Thema ist erstaunlich kompliziert und wird in diesem 
Paper im Detail durchmeditiert:
http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Vancouver schrieb:
> führt bei der ASIC-Synthese
Mit hoher, quasi an Sicherheit grenzender Wahrscheinlichkeit haben wir 
es hier mit einem FPGA zu tun. Und mit gewisser Wahrscheinlichkeit ist 
es ein RAM-basiertes und nicht eines von Actel/Microsemi. Denn auch für 
letztere gilt der Hinweis, dass ein expliziter Reset nötig ist. Aber da 
sagt dann auch wie im 
Beitrag "Re: Modelsim: Zählerausgang funktioniert nicht" der Synthesizer, 
dass er diesen Defaultwert nicht umsetzen kann.

> - Wir hatten kürzlich wieder ein FPGA-Projekt, bei dem zwingend ein
> asynchroner Reset gefordert war, aus einem einfachen Grund: Das ganze
> System muss auch bei einem Totalausfall des Clockoszillators noch
> zuverlässig resettet werden können.
Das betrifft aber dann meist nur die IO-Zellen bzw. Ausgänge, die einen 
definierten sicheren Zustand einnehmen müssen bzw. sollen. Und dann 
würde ich dort einen Reset ansetzen. Denn ohne Oszillator ist das Design 
intern ja sowieso eingefroren.

> - Das große Problem beim asynchronen Reset ist, dass ein FF metastabil
> werden kann, wenn der Reset zu nahe bei einer aktiven Taktflanke
> losgelassen wird.
Das Problem ist hier wieder mal weniger die Metastabiliät, sondern die 
unterschiedliche Laufzeit des Resetsignals auf dem Reset-Netz. Dann 
läuft u.U. beim Deaktivieren des Resets ein Teil des Designas oder einer 
FSM erst einen Takt später an. Das kann urige Effekte hervorrufen. I.A. 
ist das ganz einfach daran zu erkennen, dass das Design "manchmal" nicht 
anläuft. Wenn es aber läuft, dann problemlos bis zum nächsten 
Ausschalten.
Siehe die letzten Zeilen dort im Lichte der Betrachtungen davor:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html

Es kommt beim Reset also auf die verwendete Architektur an. Das meinte 
ich mit dem Hinweis, sich die Notwendigkeit dieses Resets nochmal zu 
betrachten.

: Bearbeitet durch Moderator
von Hans Kanns (Gast)


Lesenswert?

Fitzebutze schrieb:
> Nutze ghdl um sauberes VHDL zu entwerfen und simulieren.

Wo siehst du den prinzipiellen Vorteil?
...gegenüber z.B. ModelSIM?

von S. R. (svenska)


Lesenswert?

Hans Kanns schrieb:
>> Nutze ghdl um sauberes VHDL zu entwerfen und simulieren.
> Wo siehst du den prinzipiellen Vorteil?
> ...gegenüber z.B. ModelSIM?

Naja, ghdl ist (a) frei und (b) strenger in Bezug auf VHDL als z.B. 
Vivado. Mit ModelSIM kann ich nicht vergleichen.

von Vancouver (Gast)


Lesenswert?

Lothar M. schrieb:
> Mit hoher, quasi an Sicherheit grenzender Wahrscheinlichkeit haben wir
> es hier mit einem FPGA zu tun.

Sicher. Ich hab mir nur im Laufe der Jahre angewöhnt, den Code möglichst 
technologieunabhängig zu schreiben, das zahlt sich meistens aus. Und sei 
es nur, weil man auf einen Flash-FPGA wechselt.

> Das betrifft aber dann meist nur die IO-Zellen bzw. Ausgänge, die einen
> definierten sicheren Zustand einnehmen müssen bzw. sollen. Und dann
> würde ich dort einen Reset ansetzen. Denn ohne Oszillator ist das Design
> intern ja sowieso eingefroren.

Außer wenn die Taktquelle wieder einsetzt, dann erscheint der 
Durcheinander auch wieder an den IOs. In unserem Fall wurde das PCB 
starken Vibrationen ausgesetzt, das ganze bei Temperaturen um die 100°C. 
Da passieren laut Aussage des Kunden bisweilen seltsame Dinge. Daher 
bestand die Forderung, dass das gesamte Design jederzeit vollständig in 
einen definierten Zustand versetzt werden können muss.


> Siehe die letzten Zeilen dort im Lichte der Betrachtungen davor:
> 
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html

Guter Artikel. "Fazit: natürlich muss insbesondere auch der Reset 
einsynchronisiert werden!"

Wenn man den Reset synchronisiert im Sinne von Einsamplen, dann wird aus 
dem asynchronen ein synchroner Reset, und der funktioniert eben nur mit 
Takt. Dann kannst Du gleich das Design mit einem Sync-Reset beschreiben. 
Zudem stellt sich die Frage, mit welchem Takt man den Reset samplet, und 
dann muss man Annahmen über die Länge des Reset-Impulses machen. Ist 
meistens kein Problem, muss man aber dran denken. Ein externer Reset 
kommt nicht immer von einem Pushbutton.

Um den Reset auch ohne clock asynchron auslösen zu können, kann man 
folgendendes Design verwenden (hier Systemverilog):
1
module areset_sync 
2
(
3
  input logic     clk_i,
4
                  rstn_i,                  
5
                  
6
  output logic    rstn_o
7
);
8
9
    logic ff0,
10
          ff1;
11
12
    always_ff @(posedge clk_i or negedge rstn_i) begin
13
        if (~rstn_i) begin
14
            ff0 <= 'b0;
15
            ff1 <= 'b0;
16
        end else begin
17
            ff0 <= 'b1;
18
            ff1 <= ff0;
19
        end
20
    end // always_ff
21
    
22
    assign rstn_o = ff1;
23
    
24
endmodule: areset_sync

von Duke Scarring (Gast)


Lesenswert?

Hans Kanns schrieb:
> Wo siehst du den prinzipiellen Vorteil?
> ...gegenüber z.B. ModelSIM?
Modelsim zeigt 'nur' in welcher Quelltextzeile der Fehler sitzt.
Bei GHDL bekommt man noch die Spalte mit angezeigt ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.