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"
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.
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".
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
signalclk163:integerrange0to163:=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
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.
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.
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):
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 ;-)