Forum: FPGA, VHDL & Co. VHDL Sync. schreiben. async. lesen


von Daniel R. (dan066)


Lesenswert?

Ich bin auf ein beim durcharbeiten eines Buches auf die VHDL-Regel 
gestoßen, dass man eine taktsynchron beschriebene Variable nicht 
takt-asynchron lesen darf. (Laut VHDL-Standard müssen gute Synthesetools 
soetwas erkennen und ein Synthetisieren verweigern)
Meine Frage ist:
Wieso ist ein asynchrones Lesen nicht möglich?

Zugegeben, man wird kaum in die Lage kommen das wirklich zu wollen, denn 
es "reicht" ja eine synchron beschrieben Variable nur dann zu lesen wenn 
die beschrieben wurde und nicht zwischendurch nochmal. Trotzdem verstehe 
ich nicht wieso das grundsätzlich verboten/nicht möglich ist.

Folgendes Beispiel (pseudotext):

process(CLK)
var1:bit;
begin
if CLK='1' and CLK'event
var1 := A and B;
out1<=var1;
end if

out2<=var1; --verbotenes async. lesen
end process

Die Variable var1 wird beschrieben ohne vorher gelesen zu werden, 
weswegen sie wohl wegoptimiert und durch kombinatorische Logik ersetzt 
wird. D.h. es entsteht ein out1 <= A and B. Out1 muss als taktsynchron 
beschriebenes Flipflop umgesetzt werden. Out2 wird bei jedem start des 
Prozesses beschrieben (also bei steigender und fallender Taktflanke). Da 
var1 nur bei steigender Taktflanke aktualisiert wird, darf kein out2 <= 
A and B bei der Synthese entstehen. Das heißt aufgrund des async. lesens 
wäre es das Beste für var1 ein taktgesteuertes FF zu erstellen. Dessen 
Ausgangssignal würde bei jeder steigenden Taktflanke vom out1-FF 
übernommen werden und bei beiden Taktflanken vom out2-FF übernommen 
werden.
Scheint also umsetzbar. Wieso ist das trotzdem verboten?

Gruß
Daniel

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


Lesenswert?

Daniel R. schrieb:
> Wieso ist das trotzdem verboten?
Wer verbeitet das?
1
 process(CLK)
2
   var1:bit;
3
4
 begin
5
    if CLK='1' and CLK'event
6
       var1 := A and B;
7
       out1 <= var1;
8
    end if
9
 
10
    out2 <= var1; -- verbotenes async. lesen
11
 end process
Das verbotene "asynchrone Lesen" hier ist ÜBELSTER Beschreibungsstil. In 
einem synchronen Prozess hat niemals eine kombinatorische Zuweisung zu 
erfolgen! Man mischt nicht kombinatorische Beschreibung und synchrone 
Beschreibung in einem Prozess.

Das Problem an diesem Prozess oben ist, dass eigentlich var1 in die 
Sensitivliste müsste, weil sich out2 abhängig von var1 ändert. Man kann 
aber keine Variable in eine Sensitivliste aufnehmen. Zum Glück ist hier 
aber var1 aber sowieso synchron zum clk und wird jedesmal richtig 
berechnet.
Aber jetzt muss eigentlich out2 durch ein Flipflop realisiert werden 
(weil sich out2 ja nur ändern darf, wenn eine Taktflanke kam. 
Andererseits ist out2 kein Flipflop, weil es ja keinen Takt hat (den hat 
nur out1!).
Fazit: der Synthesizer wird evtl. einen Fehler melden und/oder etwas 
zusammenbasteln, aber es wird nicht schön sein. Und vor Allem kann es 
mit der nächsten Softwareversion ein wenig anders aussehen...

: Bearbeitet durch Moderator
von greg (Gast)


Lesenswert?

Darüber hinaus gilt es doch schon als schlechter Stil, überhaupt 
Variablen für Register zu verwenden.

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


Lesenswert?

greg schrieb:
> Darüber hinaus gilt es doch schon als schlechter Stil, überhaupt
> Variablen für Register zu verwenden.
Tja, genau das ist hier verwirrenderweise ja zumindest augenscheinlich 
noch nicht der Fall. In der Realität aber doch, weil out2 ja speichern 
muss. Es darf sich nicht gleich ändern, wenn A oder B sich ändern...

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Lothar Miller schrieb:
> Tja, genau das ist hier verwirrenderweise ja zumindest augenscheinlich
> noch nicht der Fall. In der Realität aber doch, weil out2 ja speichern
> muss. Es darf sich nicht gleich ändern, wenn A oder B sich ändern...
Xilinx-ISE ist sich auch nicht sicher, ob es ein FF oder doch zwei 
werden sollen (siehe Anhang).

Duke

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


Lesenswert?

Duke Scarring schrieb:
> Xilinx-ISE ist sich auch nicht sicher, ob es ein FF oder doch zwei
> werden sollen (siehe Anhang).
Hast du da eine Warnung/Info gesehen?

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Lothar Miller schrieb:
> Hast du da eine Warnung/Info gesehen?
Nein.

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


Lesenswert?

Daniel R. schrieb:
> (Laut VHDL-Standard müssen gute Synthesetools soetwas erkennen und ein
> Synthetisieren verweigern)
Wo hast du das im Standard gesehen?
Ich meine fast, im VHDL Standard steht gar nicht drin, was ein 
Synthesizer können oder nicht können muss. Denn vor nicht allzu langer 
Zeit konnten Synthesizer noch nicht mal Initwerte oder eine "wait until" 
umsetzen...

von Klaus F. (kfalser)


Lesenswert?

Lothar Miller schrieb:
> Ich meine fast, im VHDL Standard steht gar nicht drin, was ein
> Synthesizer können oder nicht können muss.

Da gibt es doch die IEEE 1076.6

von Daniel R. (dan066)


Lesenswert?

@Lothar:
Vielen Dank für die schnelle Antwort.
Ich bin ja noch dabei zu lernen.
1) Kombinatorische Logik hält man besser aus den Abtakt-Registern raus 
um die Clock Skew zu verhindern? Also damit die Prozesse deren 
Sensitivlistensignale "unter" der komb. Logik abgetaktet werden nicht 
später starten als die anderen?
2) Dass var1 in die Sensitivliste müsste sehe ich prinzipiell genauso. 
In Prozessen mit komb. Logik initialisiert man alle Variablen ja 
bestenfalls am Anfang des Prozesses. Wenn man das hier machen würde, 
wäre die Variable damit async. und sync. beschrieben (ebenso wenn man 
sie bei async. Reset initialisieren würde) und damit wäre das async. 
Lesen ja nicht mehr verboten, denk ich mal. Ich vermute es ist sowieso 
keine empfehlenswerte Praxis sich darauf zu verlassen, dass das 
Synthesetool ein FF für eine Variable erstellt um deren Zustand zu 
speichern. Man wird öfter was kriegen, das man nicht erwartet hat.
3) Dass für out2 ein FF erstellt werden muss hab ich schon allein 
deswegen erwartet, da var1 nicht in der Sensitivliste steht. out2 muss 
seinen Wert ja halten, wenn der Prozess mal nicht läuft. Obwohl sich 
var1 ja gar nicht verändern kann wenn der Prozess nicht läuft. Also wäre 
var1 ein Signal, hätte ich für out2 auf jeden Fall ein FF erwartet. Da 
var1 eine Variable ist kann es sein, dass das gar nicht nötig ist. Wenn 
nicht dann ist aber auf jeden Fall ein FF für var1 nötig. Denn wenn der 
Prozess gestartet wird weil eine fallende Taktflanke aufgetreten ist, 
wird var1 kein neuer Wert zugewiesen. var1 wird gelesen bevor sie 
geschrieben wird -> FF notwendig.

Wo ich das im Standard gelesen habe? Gar nicht. Es wurde in einem Buch 
beiläufig erwähnt (VHDL-Synthese von Schwarz, Reichart)

@Duke:
Danke für die Bilder. Hast du die Synthese einfach zweimal laufen lassen 
und es ist was unterschiedliches rausgekommen?

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


Lesenswert?

Daniel R. schrieb:
> 1) Kombinatorische Logik hält man besser aus den Abtakt-Registern raus
> um die Clock Skew zu verhindern?
Man beschreibt nicht kombinatorische UND synchrone Elemente in ein- und 
demselben Prozess. Na gut, mit einer Ausnahme vielleicht: einen 
asynchronen Reset kann man nach der erwähnten 1076.6 tatsächlich so 
beschreiben:
1
process (clk, rst) begin
2
   if rising_edge(clk) then -- getaktet
3
     cnt <= cnt+1;
4
   end if;
5
   if reset='1' then        -- "kombinatorisch"
6
     cnt <= 0;
7
   end if;
Ich setze hier "kombinatorisch" in Anführungszeichen, weil da wirkliche 
Kombinatorik nichts zu suchen hat. Nur der Reset sollte als Signal da 
auftauchen.

> damit die Prozesse deren Sensitivlistensignale "unter" der komb. Logik
> abgetaktet werden nicht später starten
Ein Prozess "startet" nicht. Ein Prozess wird in Hardware übersetzt und 
ist immer da.

> 3) Dass für out2 ein FF erstellt werden muss hab ich schon allein
> deswegen erwartet, da var1 nicht in der Sensitivliste steht.
Selbst wenn var1 in der Sensitivliste stehen könnte und würde, müsste 
irgendwas da speichern, weil sich var1 ja nur mit einem Takt ändert, und 
sonst seinen Wert beibehält. Das ist die Funktion eines Flipflops.

> dass das Synthesetool ein FF für eine Variable erstellt
Ein FF wird für all das erstellt, was zusammen mit einer Taktflanke 
etwas speichern muss. Denn die einzigen ernstzunehmenden 
Speicherelemente sind Flipflops (neben den nicht erst zu nehmenden 
Latches).

von Daniel R. (dan066)


Lesenswert?

Lothar Miller schrieb:
>> 3) Dass für out2 ein FF erstellt werden muss hab ich schon allein
>> deswegen erwartet, da var1 nicht in der Sensitivliste steht.
> Selbst wenn var1 in der Sensitivliste stehen könnte und würde, müsste
> irgendwas da speichern, weil sich var1 ja nur mit einem Takt ändert, und
> sonst seinen Wert beibehält. Das ist die Funktion eines Flipflops.

Ok, ich bezog mich darauf, dass eine async. Signalzuweisung in einem 
Prozess auf die selbe Weise wegoptimiert wird wie eine concurrent 
Signalzuweisung außerhalb des Prozesses. Also dass
process(CLK, SIG)
 begin
    ...
    out2 <= SIG;  --1)
    ...
 end process
out2 <= SIG;   --2)

1) genauso zu einer einfachen Leitung wegoptimiert wird wie 2). Aber das 
sind ja jetzt sehr bizarre Gedankenexperimente.


> Ein Prozess "startet" nicht. Ein Prozess wird in Hardware übersetzt und
> ist immer da.
Selbstverständlich, aber kann man nicht sagen, dass ein Prozess durch 
Veränderungen in seiner Sensitivliste gestartet wird? Ich hab mir das 
bisher immer so vorgestellt, dass einige FFs dann eben nicht ein clock 
Signal am clock-Eingang haben sondern ein Signal aus der Sensitivliste. 
Kommt diese Vorstellung der Realität nahe?

> Ein FF wird für all das erstellt, was zusammen mit einer Taktflanke
> etwas speichern muss.
Soweit ich weiß gibt es nur zwei Arten wie das Synthesetool mit einer 
Variable umgeht.
Erste Möglichkeit:
process (A,B)
variable var1:bit;
begin
  var1 := A or B;
  OUT <= var1;
end process
In diesem Beispiel wird kein FF gebraucht, weil var1 durch komb. Logik 
ersetzt werden kann. Dies trifft auf alle Variablen zu die in einem 
Prozess  immer zuerst beschrieben werden, bevor sie gelesen werden. Es 
ist kein FF für var1 nötig.

Zweite Möglichkeit:
process (A,RES)
variable var1:bit;
begin
  if RES='1' then
    var1 := '0';
  end if
  var1 := var1 and A;
  OUT <= var1;
end process
In diesem Beispiel wird von der Möglichkeit gebrauch gemacht, dass sich 
Variablen wie statische Variablen die man aus C kennt verhalten. Im 
einen Fällen wird var1 zuerst beschrieben und dann gelesen (wie in 
Beispiel 1). Im anderen Fall wird sie zuerst gelesen und dann 
beschrieben. Var1 kann in diesem Fall nicht wegoptimiert werden, weil 
ihr alter Wert mit in die komb. Logik eingeht. Hier ist ein FF für var1 
nötig.

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


Lesenswert?

Daniel R. schrieb:
> Kommt diese Vorstellung der Realität nahe?
Ich muss dich desillusionieren:
die Sensitivliste ist nur und ausschließlich für die Simulation. Die 
Synthese schert sich keinen Cent um diese Liste...

> In diesem Beispiel wird von der Möglichkeit gebrauch gemacht, dass sich
> Variablen wie statische Variablen die man aus C kennt verhalten.
Ja, und genau mit dieser Strategie und Denkweise wirst du sehr schnell 
Schiffbruch erleiden. Denn auch wenn es Syntaxelemente gibt, die sich 
wie eine dir bestens bekannte Programmiersprache anfühlen, verhalten Sie 
sich in Hardware komplett anders: schon bei einer simplen Schleife fängt 
es an. Und eine Variable in VHDL ist mitnichten annähernd so was wie in 
C...

Du musst in Hardware denken und die dann mit VHDL beschreiben. Deshalb 
und es eine Hardware-Beschreibungssprache.
Die Lösung der Möglichkeit 2 ist: es ergibt ein Patch. Und die 
Simulation passt nicht zur Realität, weil var1 in die Sensitivliste 
müsste.
Das wird dort auch diskutiert: 
Beitrag "Re: VHDL-Code Funktioniert in Modelsim und auf FPGA nicht"

: Bearbeitet durch Moderator
von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Daniel R. schrieb:
> Hast du die Synthese einfach zweimal laufen lassen
> und es ist was unterschiedliches rausgekommen?
Nein. Es gibt die Möglichkeit sich anzuschauen, was der Synthesizer aus 
der Beschreibung gemacht hat.

Dabei gibt es zwei Varianten: eine Abstakte und eine sehr 
Hardwarespezifische, wobei die Letztere schnell unübersichtlich wird.

Dieser Schematic-View ist m.E. gerade für Anfänger recht hilfreich.
Leider gibt es bei Xilinx da ab und zu Aussetzer. Die Altera-Software 
hat auch so eine Funktion. Bei Lattice habe ich sie noch nicht gefunden 
und zu Microsemi kann ich nix sagen.

Duke

von Lattice User (Gast)


Lesenswert?

Duke Scarring schrieb:
>  Bei Lattice habe ich sie noch nicht gefunden

Ist in Synpify Pro enthalten. (HDL-Analyst)

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


Lesenswert?

Lattice User schrieb:
> Ist in Synpify Pro enthalten. (HDL-Analyst)
Siehe z.B. den Beitrag "Re: Erste Schritte mit FPGA - ich komme nicht weiter"

: Bearbeitet durch Moderator
von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Lattice User schrieb:
> Ist in Synpify Pro enthalten. (HDL-Analyst)
Super, Danke. Ich hatte es bei "Diamond - Process" vermisst.

Die Darstellung ist aber ebenfalls gewöhnungsbedürftig.

Im Anhang ist mal ein Links-Rechts-Lauflicht mit Teiler für's Enable.
Und zum Vergleich auch die Xilinx ISE - Darstellung.

Taugt m.E. wirklich nur für sehr kleine Module.

Duke

von Lattice User (Gast)


Lesenswert?

Duke Scarring schrieb:
> Lattice User schrieb:
>> Ist in Synpify Pro enthalten. (HDL-Analyst)
> Super, Danke. Ich hatte es bei "Diamond - Process" vermisst.
>
> Die Darstellung ist aber ebenfalls gewöhnungsbedürftig.
>
> Im Anhang ist mal ein Links-Rechts-Lauflicht mit Teiler für's Enable.
> Und zum Vergleich auch die Xilinx ISE - Darstellung.
>
> Taugt m.E. wirklich nur für sehr kleine Module.
>
> Duke

Der RTL View ist in der Tat etwas arg abstract, Adder, Zähler, State 
Machines etc als eigene Symbole. Die Anordung lässt auch zu wünschen 
übrig. Bei State Machines kann man sich dafür aber ein State Diagramm 
anzeigen lassen.

Beim Technolgoy View gibt es die Ansicht flattened to Gates, das wird 
dir vertrauter vorkommen (aber halt ohne Hierarchie)

Um Implentierungs Details zu erforschen macht man sich halt kleine 
Testmodule.

Ich verwende den RTL View es meist nur um zu überprüfen ob alle 
Ports/Pins verbunden sind und in den Modulen auch verwendet werden.

von Daniel R. (dan066)


Lesenswert?

Lothar Miller schrieb:
> Ich muss dich desillusionieren:
> die Sensitivliste ist nur und ausschließlich für die Simulation. Die
> Synthese schert sich keinen Cent um diese Liste...
Sehr interessant. Kannst du mir vielleicht einen Beitrag etc. nennen in 
dem erklärt wird wie das Synthesetool mit Sensitivlisten bzw. wait-for's 
umgeht? Dazu hab ich bisher noch nichts konkretes gefunden.

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


Lesenswert?

Daniel R. schrieb:
> Sehr interessant. Kannst du mir vielleicht einen Beitrag etc. nennen in
> dem erklärt wird wie das Synthesetool mit Sensitivlisten bzw. wait-for's
> umgeht? Dazu hab ich bisher noch nichts konkretes gefunden.
Lies den die Bedienungsanleitung deines Synthesizers (bei Xilinx wäre 
das der XST User Guide). Lies die Infos und Warnungen deines 
Synthesizers, dort tauchen entsprechende Meldungen auf.

Wenn ich z.B. einen asynchronen Reset weglasse, dann kommt z.B. sowas:
WARNING:Xst:819 - "....vhd" line 39: One or more signals are missing in 
the process sensitivity list. To enable synthesis of FPGA/CPLD hardware, 
XST will assume that all necessary signals are present in the 
sensitivity list. Please note that the result of the synthesis may 
differ from the initial design specification. The missing signals are: 
<reset>

"will assume that all necessary signals are present in the sensitivity 
list" bedeutet hierbei nicht, dass der Synthesizer nur die Signale in 
der Sensitivliste beachtet, sondern, dass er die Sensitivliste einfach 
ignoriert.

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.