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
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
Darüber hinaus gilt es doch schon als schlechter Stil, überhaupt Variablen für Register zu verwenden.
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...
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
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?
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...
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
@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?
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).
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.
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
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
Duke Scarring schrieb: > Bei Lattice habe ich sie noch nicht gefunden Ist in Synpify Pro enthalten. (HDL-Analyst)
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
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
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.