mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: hdler (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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"







library IEEE;
use IEEE.STD_LOGIC_1164.ALL;



entity baud_gen is
    Port ( clk : in  STD_LOGIC;
           reset : in  STD_LOGIC;
           tick : out  STD_LOGIC);
end baud_gen;

architecture Behavioral of baud_gen is

signal clk163_next, clk163_reg: unsigned(7 downto 0);
signal s_pulse: std_logic;

begin

  process(clk, reset)
  begin
    if reset='1' then
      clk163_reg <= (others => '0');
    else if (clk 'event and clk='1') then
      clk163_reg <= clk163_next;
    end if;
  end process;
  
  clk163_next <= (others=>'0') when clk163_reg=(div-1) else
            clk163_reg + 1;
  s_pulse <= '1'  when clk163_reg=0 else '0';


end Behavioral;






Autor: Samuel C. (neoexacun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
else if -> elsif

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: hdler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Tipps und Links!

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein vorschlag: nimm Integer für den Zähler:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;

architecture Behavioral of baud_gen is

constant div: integer := 163;
signal clk163: integer range 0 to 163 := 0;
signal s_pulse: std_logic;

begin

  process(clk, reset)
  begin
    if reset='1' then
       clk163 <= 0;
    elsif riging_edg(clk) then
       if clk163<div then
          clk163  <= clk163+1;
          s_pulse <= '0';
       else
          clk163  <= 0;
          s_pulse <= '1';
       end if;
     end if;
  end process;

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
Autor: Style is helpful (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

  P_BUFFERING:PROCESS(clk,reset)
  BEGIN
    IF reset = '1' THEN
      clk163_reg <= 0;
    ELSIF rising_edge(clk) THEN
      clk163_reg <= clk163_next;
    END IF;
 END PROCESS P_BUFFERING;


Autor: Style is helpful (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> elsif riging_edg(clk) then

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

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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:
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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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
Autor: Hans Kanns (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Nutze ghdl um sauberes VHDL zu entwerfen und simulieren.

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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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):
module areset_sync 
(
  input logic     clk_i,
                  rstn_i,                  
                  
  output logic    rstn_o
);

    logic ff0,
          ff1;

    always_ff @(posedge clk_i or negedge rstn_i) begin
        if (~rstn_i) begin
            ff0 <= 'b0;
            ff1 <= 'b0;
        end else begin
            ff0 <= 'b1;
            ff1 <= ff0;
        end
    end // always_ff
    
    assign rstn_o = ff1;
    
endmodule: areset_sync

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.