Hallo,
ich habe folgenden Code geschrieben unter der XILINX ISE 7.1.03i:
process (CLOCK)
begin
if rising_edge (CLOCK) then
if RESET = '1' then
TST_OUT <= '0';
else
TST_OUT <= '1';
end if;
else
TST_OUT <= '0';
end if;
end process;
Jetzt bekomme ich immer folgende Fehlermeldung:
Signal TST_OUT cannot be synthesized, bad synchronous description.
Ich habe keine Ahnung warum.
Vielen Dank für Eure Hilfe.
Überleg doch mal was dein Code macht.
Bei der steigenden Taktflanke von "clk" übergibst du dem Signal
TST_OUT eine '1' ansonsten übergibst du '0'. Das kann gar nicht
synthetisiert werden.
if rising_edge (CLOCK) then
TST_OUT <= '1';
else
TST_OUT <= '0';
end if;
end process;
Hi,
es gibt verschiedene Arten, einen synthetisierbaren
synchronen Prozess zu schreiben:
- Mit und ohne Reset
- Falls mit Reset: Synchron oder Asynchron
-- Asynchroner Reset
process (Clock, Reset)
begin
if Reset='1' then
Ausgang <= '0'; -- Initialisierung
elsif rising_edge(Clock) then
-- nun kommt das was Du machen möchtest ...
if ...
Ausgang <= ...
...
else if ...
...
end if;
end if;
end process;
Ausserhalb des "elsif - end if"-Bereiches darf nix anderes
stehen.
Das Signal Reset muss dabei auch in die Sensitivity List.
-- Synchroner Reset
process (Clock)
begin
if rising_edge(Clock) then
if Reset='1' then
Ausgang <= '0'; -- Initialisierung
else
-- nun kommt das was Du machen möchtest ...
if ...
Ausgang <= ...
...
elsif ...
...
end if;
end if;
end if;
end process;
Ausserhalb des if mit dem clock darf nix anderes stehen.
Du scheinst in deinem Beispiel einen synchronen Reset zu
verwenden, hast allerdings Dein 3. TEST_OUT ausserhalb
des "if rising_edge(Clock)", daher funktioniert das ganze
nicht.
(BTW: Die Simulation würde hier folgendes tun: Mit der
steigenden Taktflanke führst Du den oberen Teil aus, also
bei Reset ist der Ausgang gleich null, ansonsten wird er
auf 1 gesetzt. Mit der Fallenden Flanke setzt Du den
Ausgang dann wieder auf 0.)
Dasselbe geht auch ohne Reset - ist wie das 2. Beispiel,
nur dass man den Resetteil weglässt.
Alternativ zu rising_edge(Clock) kannst Du auch
Clock'event and Clock='1' schreiben.
Es gäbe auch noch die Möglichkeit, mit
wait until rising_esge(Clock)
zu arbeiten, wird aber kaum verwendet.
Gruss,
Alex
Hallo, erstmal Danke für Eure Antworten. @Tobias: Also Dein Codefragment funktioniert auch nicht. Ich komme bei einer Clocksignaländerung (rising oder falling) in den process, durch die Sensetiv-Liste. Jetzt teste ich ob eine rising-edge vorlag if rising_edge Ja, dann TST_OUT <= '1'; else (nein) dann TST_OUT <= '0'; end if; Irgenwie kapiere ich das nicht. Warum das nicht gehen soll. Hab das Gefühl das muss was mit der Hardware zu tun haben. Aber was genau??? Danke.
In dem Codebeispiel habe ich nur deinen Code genommen und den
überflüssigen Ballast entfernt, um dir zu verdeutlichen was du dem
Synthesewerkzeug damit antust.
Versuch mal das Verhalten dieses Codefragmentes als Blockschaltbild mit
Gattern und Flip-Flops nachzubilden.
if rising_edge (CLOCK) then
TST_OUT <= '1';
else
TST_OUT <= '0';
end if;
end process;
Auf das Ergebniss bin ich sehr gespannt.
Hi, Du solltest nur eine Flanke des Taktes verwenden, d,h. die ganze Funktion sollte innerhalb des then-Zweiges Deiner if rising_edge stehen. Alles andere macht für die Synthese nur bedingt Sinn. Was Du beschrieben hast, ist ein Signal, dass mit einer steigenden Taktflanke auf 1 gesetzt wird, mit einer fallenden auf 0 - also im Prinzip den Takt selbst (mit dem Zusatz, daß während Reset nix passiert - siehe mein BTW von oben). Wäre hilfreich, wenn Du schreiben würdest, was Du denn tatsächlich machen möchtest. Gruss, Alex PS: Es geht auch die fallende Flanke als Trigger. Im Prinzip geht auch steigende und fallende und dann die Funktion im else-Zweig, dann wird ein FF mit Set und Clear eingebaut - ich weiss aber nicht, ob das alle Synthesetools so können.
>Irgenwie kapiere ich das nicht. Warum das nicht gehen soll. Hab das >Gefühl das muss was mit der Hardware zu tun haben. Aber was genau??? Schau Dir doch mal den Code genau an: Wenn eine steigende Flanke kommt, soll TST_OUT den Wert 1 haben, wenn nicht, dann 0. Das heisst in dem infinitesimal kleinen Zeitpunkt der steigenden Flanke soll es den Wert 1 haben, ansonsten 0. Was soll denn das bitteschön für eine digitale Hardware darstellen? Alex H. hat übrigens nicht recht wenn er schreibt dass der else-Zweig einer fallenden Flanke entspricht. Der else-Zweig ist jeder Zeitpunkt der keine steigende Flanke ist. Und deshalb ist das nicht synthetisierbar.
Hallo,
process (CLOCK)
begin
if rising_edge (CLOCK) then
TST_OUT <= '1';
else
TST_OUT <= '0';
end if;
end process;
Man muss hier klar trennen zwischen VHDL-Ursprung und Synthese.
In der VHDL Simulation funktioniert das oben beschriebene Konstrukt
wunderbar. Der Eintritt in den process wird überdie Sensitivliste
gesteuert. Bei jeder Änderung eines der Sensitivlist-Signale wird
der Prozess bearbeitet. Siehe dazu Simulationstherorie.
Wie sieht's jetzt aber beim Synthetisieren aus?
Ich bin da auch noch nicht so sattelfest, bitte korrekiert mich wenn
ich falsch liege.
Vereinfacht kann man sagen; ein process wird zu einem Baustein. Nun
besitzt dieser Baustein aber keine Sensitivliste (Nur für Simulation
nötig). Sondern nur Eingänge. Diese Eingänge werden auf eine
kombinatorische Logik geroutet. Der Ausgang des Bausteins ist im
Prinzip nichts anderes als der Ausgang der kombinatorischen Logik.
Jetzt zum obigen Konstrukt. Der Ausgang wird mit einem Taktflanken-
Gesteuerten D-Flip-Flop (mit Reset) upgdatet/gelatcht. In einem FPGA
sind diese FF in den Ausgängen der CLB. Diese CLB-FFs können einfach
nur auf eine positiv ODER negative Flanke scharf gestellt werden.
Will man jetzt wie oben auf negative und positive Flanke einen
synthetisieren dann braucht man zwei CLB's. Das fatale die zwei
CLB-Ausgänge müssten sich gegenseitig überschreiben können.
ERROR!!!!!!!!!
Also wie gesagt, ich bin noch nicht so sattelfest.
Aber ich denke das kommt der Sache sehr nahe.
Sebastian
Leider stimmt Dein Verständis nicht ganz. VHDL wurde als Sprache zur SIMULATION von digitaler Hardware entworfen. Dabei gibt es für die Elemente der Hardware (z.B. ein Flip-Flop) bestimmte Beschreibungsmöglichkeiten. Bei der Synthese erkennt der Compiler diese Beschreibung an der STRUKTUR und erzeugt dazu die beschriebene Hardware. Lass mich das an einem Beispiel verdeutlichen. Z.B. kann ein Flip-Flop mit Reset folgendermaßen in VHDL beschrieben werden: process(clock, reset) is begin if (reset = '1') then Q <= '0'; elsif rising_edge(clock) then Q <= 'D'; end if; end process; Dieser Prozess steuert das Signal D, wie wenn es der Ausgang eines FF wäre mit den Eingängen D, clock, reset. Denk daran, hier sprechen wir von der Simulation !! Ein VHDL-Compiler, dem Du das obige VHDL-Stück übergibst, erkennt an der FORM (also process mit sensitivity list reset und clock, sowie "if (reset = '1') und dann elsif rising_edge()), daß es sich um die Beschreibung eines FF's handelt, und erzeugt ein FF in Hardware. Die Namen für reset und clock tun dabei nichts zur Sache. Man sollte also nicht denken, daß ein VHDL-Programm für Simulation einmal so, und für die Synthese einmal anders umgesetzt wird. Der Compiler versucht nur zu erkennen, welche Hardware-Elemente man in VHDL zu modellieren (simulieren) versucht hat, und erzeugt die entsprechende Hardware dazu. Das Problem für Anfänger ist oft, daß VHDL viele Freiheiten bietet. Nicht alles, das man in VHDL gültig beschreiben kann, entspricht auch einer Hardware. Z.B. kann man in VHDL Dateien lesen und schreiben, aber eine Hardware-Schaltung kann das nicht. Wenn Du dem Compiler VHDL-Code übergibts, der zwar gültig ist (so wie Deiner), aber keine Beschreibung von Hardware ist, dann gibt's eben eine Fehlermeldung. Vielleicht solltest Du Dich doch noch einmal ein bischen in VHDL einarbeiten. Hoffentlich habe ich Dich nicht zu sehr verwirrt. Klaus
Hallo, also ich dachte schon das man zwischen VHDL-Compiler und Synthesizer klar unterscheiden kann. Wenn ich aus Modelsim meine VHDL-Dateien compilieren lasse, werden Tabellen erstellt in denen Ereignisse zu bestimmten Zeiten eingetragen werden. (Mir fällt dazu gerad nicht der Fachbegriff für die genau Bezeichnug der Tabellen ein, meine Unterlagen sind daheim.) Das Simulationstool arbeitet doch nur nach diesen Tabellen und fügt wenn nötig DeltaT's ein. Warum sollte der Compiler nach Hardwarestrukturen suchen, wenn er sowieso keine finden kann (z.B. für ReadFile etc.) Nach bekannten Hardware-Elementen sucht das Synthese-Tool. Wenn dies kein passendes Hardware-Element findet wird gemeckert. Allerdings braucht anscheinend das Synthese-Tool das Ergebnis vom Compiler. Weil der Compile-Vorgang (vielleicht nur für den Syntax Check) immer gestartet wird bevor die HDL Synthesis angeworfen wird. (Sieht man schön in der ISE-Shell) Sorry, aber ich würde es gerne voll und ganz verstehen. Und es ist sehr schwer als Autodidakt immer die richtigen Bücher bzw. pdfs zu finden. Wenn man dazu überhaupt was finden kann. Sebastian
Die tabelle nennt sich wohl "event list". Das synthesetool braucht keine ergebnisse aus dem Compile für die simulation. Der Synthaxcheck geht i.d.R mit dem Simutool schneller als mit dem Synthesetool. Es gibt warnings aus dem simulatortool die die synthese nicht bringt aber denoch zu ungewollten ergebnissen führt. Zitat: "Nur Genies und Idioten verzichten auf eine Simulation"
@Xenu > Alex H. hat übrigens nicht recht wenn er schreibt dass der > else-Zweig einer fallenden Flanke entspricht. Der else-Zweig > ist jeder_ Zeitpunkt der _keine steigende Flanke ist. Und > deshalb ist das nicht synthetisierbar. durch "process (CLOCK)" ganz oben ist der Prozess sensitiv auf CLOCK. D.h. er wird immer genau dann durchlaufen, wenn Clock sich ändert. Danach wird die IF-Anweisung ausgeführt. Wird nun eine steigende Flanke erkannt, dann wird der THEN-Teil ausgeführt. Im anderen Fall (also z.B. bei der fallenden Flanke) wird der Else-Zweig ausgefüght. Also folgt das Ausgangssignal dem Clock. (Falls das Signal std_logic ist, wäre daneben z.B. auch ein Übergang von U nach 1 oder von H nach L eine Flanke usw (steigend oder fallend :-?), die den Prozess ausführt, aber ich gehe mal davon aus, dass man Clock i.W. durch eine Folge von 01010101 beschreibt ... ;-) Soviel zum Simulationsverhalten im Beispielcode. Nach wie vor gilt aber: Man sollte so nicht beschreiben. Oben sind Beispiele, wie man einen synchronen Prozess richtig bescchreibt. BTW, die Synthese "versteht" sehr wohl Clocks. Sie ignoriert zwar sensitivity lists, kann aber getaktete Prozesse erkennen. > Schau Dir doch mal den Code genau an: Wenn eine > steigende Flanke kommt, soll TST_OUT den Wert 1 haben, > wenn nicht, dann 0. > Das heisst in dem infinitesimal kleinen Zeitpunkt > der steigenden Flanke soll es den Wert 1 haben, ansonsten 0. Dies stimmt daher so nicht. Der Prozess wird mit einer steigenden Flange angestossen und setzt TST_OUT auf 1. Danach passiert solange NICHTS, bis wieder eine Flanke kommt. Erst dann wird der Prozess erneut gestartet und TST_OUT entsprechend gesetzt ... Sorry, Xenu, aber so ist es nun mal ... ;-) ----- Wie Klaus Falser schon schreibt ... > Ein VHDL-Compiler, dem Du das obige VHDL-Stück übergibst, > erkennt an der FORM (also process mit sensitivity list reset > und clock, sowie "if (reset = '1') und dann > elsif rising_edge()), daß es sich um die > Beschreibung eines FF's handelt, und erzeugt ein FF in Hardware. > Die Namen für reset und clock tun dabei nichts zur Sache. > > Man sollte also nicht denken, daß ein VHDL-Programm für > Simulation einmal so, und für die Synthese einmal anders > umgesetzt wird. Bei der Sensitivity-Liste gibt es diese (kleinen) Unterschiede - wenn man in einem kombinatorischen Prozess nicht alle Signale in die Sensitivity-Liste mit aufnimmt, verhält sich die Simulation anders als die synthesisierte Schaltung. Die Synthese geht immer davon aus, dass alle Signale in der Sensitivity-Liste sind. Macht man dies in Code so, dann passen Simulation und Synthese auch wunderbar zusammen. Man sollte dies daher auch immer so tun. BTW, man wird i.d.R. vom Compiler (bei der Synthese) darauf hingewiesen, wenn man nicht alle Signale in einem kombinatorischen Prozess in der Sensitivity-Liste hat. ----- Abgesehen davon wäre es hilfreich, wenn Absolut Beginner schreiben würde, was er genau machen möchte ... Gruss, Alex
@FPGAküchle: "Nur Genies und Idioten verzichten auf eine Simulation" Naja, das hatte ja keiner vor ;-) Sebastian
Unter VHDL-Compiler versteht man ( verstehe ich ) immer das Synthese-Tool, das andere ist der Simulator (obwohl es dort auch eine Art Compiler gibt, der den Quelltext in die Library compiliert. Beide sind komplett unabhängig. Bei Xilinx wird der Syntax-Check mit dem Synthese-Tool gemacht, der ModelSim Simulator muß gar nicht installiert sein. Der Simulator erstellt aus dem VHDL-Quelltext eine Aufstellung von Signalen, Prozessen und Ereignissen. Die Prozesse ändern die Signale zu bestimmten Zeitpunkten (Ereignisse = Event), die Ereignisse starten dann die Prozesse, welche wiederum die Signale ändern. Im ModelSim kann man dann graphisch verfolgen, wie sich die Signale ändern und überprüfen ob das Design sich so verhält, wie man geplant hat. Der Compiler ( = die Synthese) erstellt eine Liste von Hardware-Elementen (FF's, LUT's, Pins) aus den VHDL-Files, indem er versucht aus den VHDL-Files zu verstehen, welche Elemente zu dem in VHDL beschriebenem Verhalten passen. Damit dies funktioniert, müssen die Elemente in einer bestimmten Art (IEEE Standard) beschrieben sein. In diesem Forum sind schon öfter Bücher und PDF's empfohlen worden, du solltest danach googlen.
>Dies stimmt daher so nicht. Der Prozess wird mit einer >steigenden Flange angestossen und setzt TST_OUT auf 1. >Danach passiert solange NICHTS, bis wieder eine Flanke >kommt. Erst dann wird der Prozess erneut gestartet und >TST_OUT entsprechend gesetzt ... Das stimmt nur für Simulations-VHDL. Aber wenn Du Dir den Code aus der Sicht eines Synthesizers anschaust, stimmt meine Beschreibung sehr wohl. Bei dem ist die Sensitivitätsliste nämlich egal. Und dann steht der else-Zweig in der Tat für jeden Zeitpunkt, der keine steigende Flanke von CLOCK ist. Das kannst Du übrigens auch simulationstechnisch approximieren, indem Du ein weiteres Signal in Sensitivitätsliste mit einfügst, welches mit einer größeren Frequenz als CLOCK toggelt.
Um es nochmals zu wiederholen, es gibt kein Simulations-VHDL und kein Synthese-VHDL. Der Simulator setzt den Standard, die Synthese ist nur das Erkennen bestimmter VHDL-Konstrukte. Deshalb kann man auch nicht sagen, daß die Synthese die sensitivity list ignoriert. Die sensitivity list dient dem Compiler dazu, diese Konstrukte zu erkennen, weil es z.B. der Unterschied zwischen Latch und FF sein kann, ob ein Signal in der sensitivity list steht oder nicht. Leider sind manche Compiler zu schlau, und erkennen bestimmte Strukturen obwohl die sensitivity list nicht korrekt angeben ist. Davon entsteht dann die Meinung, daß die sensitivity list bei der Synthese ignoriert wird. Deshalb hat Du, Xenu nicht recht. Der Synthesizer ist kein Simulator, er weiss nichts über das Signal zu bestimmten Zeitpunkten. Er erkennt die Beschreibung eines FF's oder er erkennt sie nicht, wenn sie falsch ist. Dein Vorschlag mit dem höherfrequentigen Signal beweist nichts. Es stimmt zwar, daß sich die Simulation dann so verhält, wie Du schreibst, aber du simulierst dann kein FF mehr, sondern irgend etwas sinnloses.
Wie schon oben gesagt: > Zitat: > "Nur Genies und Idioten verzichten auf eine Simulation" Die Referenz sollte immer die Simulation sein. Die Synthese versteht i.d.R. ohnehin nur einen Teil des VHDL-Sprachumfanges. Wenn man die Schaltung richtig beschreibt, dann stimmen Simulation und Synthese auch überein. > Aber wenn Du Dir den Code aus der Sicht eines Synthesizers > anschaust, stimmt meine Beschreibung sehr wohl. Soweit ich bisher verstanden habe, wird die Beschreibung ohnehin nicht synthetisiert, Absolut Beginner schreibt was von ner Fehlermeldung "Bad description ..." oder so. Also von welcher Synthese redest Du? Zur Sensitivity-Liste: Laut VHDL muss ein Signal, dass in einem (kombinatorischen) Prozess verwendet wird, nicht notwendigerweise in der Sensitivityliste definiert sein. Daher darf (muss!) der Simulator hier auch einen Unterschied machen: process (A, B) begin C <= A and B; end process; oder process (A) begin C <= A and B; end process; Bei der Synthese wird m.E. in beiden Fällen einunddaselbe UND-Gatter erzeugt (zumindest war das lange Zeit mit ASIC Synthesetools so, hab schon ne Weile nicht mehr synthetisiert - korrigiert mich, wenn sich das mittlerweile geändert hat). Grundsätzlich stimme ich aber mit Klaus überein: Es gibt nur EINE Bedeutung bei VHDL (die ist im Sprachstandard definiert). Der Simulator sollte gefälligst compliant zu dieser sein. Wenn man die Schaltung richtig beschreibt, dann sollte nach der Synthese auch dasselbe Verhalten rauskommen wir zuvor. BTW, VHDL definiert mit einem Zusatz (1076.6 - Standard for RTL Synthesis) auch einen Subset von VHDL, bzw den Weg, wie man VHDL verwenden sollte, dass die Synthesetools damit klarkommen. Meines Wissens nach steht dort auch was in der Art, dass in einer Sensitivityliste eines kombinatorischen Prozesses alle Signale enthalten sein sollen, die im Prozess ("auf der rechten Seite des Zuweisungszeichens") verwendet werden. Daher kann man in obigem Beispiel (mit und ohne B in der Sensitivityliste) auch darüber streiten, ob die 2. Beschreibung von einem Synthesetool erst gar nicht akzeptiert werden sollte und gleich einen Fehler erzeugt (und nicht nur ne Warning), aber das ist Auslegungssache - wie gesagt, Synthese unterstützt ohnehin nur nen Teil des Sprachumfanges. Ich sage nicht, dass es im Sinne von IEEE 1076 richtig ist, wenn ein Synthesetool ein UND-Gatter aus der 2. Beschreibung erzeugt ;-) - aber das Synthesetool nimmt i.d.R. an, dass man den Ausgang kombinatorisch von allen Werten abhängig haben möchte und "interpretiert" dass dann eben so. Wie eingangs gesagt, die Simulation ist die Referenz. Gruss, Alex
@Klaus Falser >Um es nochmals zu wiederholen, es gibt kein Simulations-VHDL und kein >Synthese-VHDL. >Der Simulator setzt den Standard, die Synthese ist nur das Erkennen >bestimmter VHDL-Konstrukte. Das war es eigentlich, was ich damit meinte. Ich weiß sehr wohl, daß VHDL ursprünglich eine Verifikations- und Simulationssprache war, und die Synthesekonstrukte nur eine Untermenge darstellen. Wenn ich von "Simulations-VHDL" spreche, meine ich damit den vollen VHDL-Sprachumfang, und nicht bloß die synthesefähige Untermenge (die ja auch noch herstellerabhängig ist). Die meisten Leute mit denen ich rede, kommen mit dieser Bezeichnung eigentlich gut zurecht... >Die sensitivity list dient dem Compiler dazu, diese >Konstrukte zu erkennen, weil es z.B. der Unterschied zwischen Latch >und FF sein kann, ob ein Signal in der sensitivity list steht oder >nicht. Nein, die Sensitivitätliste ist dem Synthesizer völlig egal. Zumindest mit allen acht Synthesizern, mit denen ich bisher gearbeitet habe. Nenne mir doch bitte einen VHDL-Synthesizer, der sie nicht ignoriert. Ob das gut ist, ist eine anderer Frage. Die meisten Synthesizer bringen eine Warnung. Selbstverständlich sollte man seinen Code so schreiben, daß Simulation und Synthese zusammenpassen, und deswegen die Liste korrekt mit angeben. >Deshalb hat Du, Xenu nicht recht. Der Synthesizer ist kein Simulator, Jetzt wird's ulkig, ausgerechnet ich soll das behauptet haben? Wo? >er weiss nichts über das Signal zu bestimmten Zeitpunkten. Er erkennt >die Beschreibung eines FF's oder er erkennt sie nicht, wenn sie >falsch ist. Habe ich jemals das Gegenteil behauptet? >Dein Vorschlag mit dem höherfrequentigen Signal beweist nichts. Es >stimmt zwar, daß sich die Simulation dann so verhält, wie Du >schreibst, aber du simulierst dann kein FF mehr, sondern irgend etwas >sinnloses. Klar ist das sinnlos und nicht synthetisierbar und kein Flip-Flop. Habe ich das irgendwo behauptet? Ich habe doch nur gesagt wie ein Synthesizer das sieht, wenn er die Sensitivitätliste ignoriert (was er tut!), und dann sieht er eben ein "Dingsbums", dessen Signal TST_OUT für einen infinitesimal kleinen Zeitpunkt '1' ist. Klar ist das nicht synthesefähig, das habe ich doch in meinem ersten Posting geschrieben. Aber um dieses Konstrukt so zu simulieren, wie der Synthesizer es sieht, muss man eben ein weiteres, möglichst hochfrequentes Signal in Liste hängen. Es ging hierbei mir doch nur um die Veranschaulichung.
Guten Morgen,
soweit ich das sehe, ist kaum ein Unterschied zwischen kombinatorischer
Logik und flankengesteuerter Logik.
process (A,B) -- Prozess 1
begin
C <= A and B;
end process;
process (CLOCK) -- Prozess 2
begin
if rising_edge (CLOCK) then -- D-FF
C <= A and B; -- Kombinatorische Logik
end if;
end process;
Im ersten Prozess wird ein UND-Gatter erzeugt. Dessen Ausgang sofort
gültig ist. Man sollte natürlich noch das Einschwingen abwarten.
Im zweiten Prozess wird ebenfalls ein UND-GATTER erzeugt dessen Ausgang
aber auf ein D-FF geroutet ist. Sprich das UND-Gatter schwingt sich ein
wie im ersten process. Und mit der nächsten steigenden Taktflanke wird
der Ausgang des UND-Gatters auch am Ausgang des D-FF übernommen. Oder
anders gesagt. Das Synthesetool erzeugt ein UND-Gatter wie im ersten
Prozess und legt dessen Ausgang auf ein D-FF.
Sebastian
das ist soweit richtig aber unvollständig. beim allersten Takt ist bei der FF Variante unbestimmt. es wird vor dem ersten takt der Initwert des FF haben, ein zweites FF das den Wert des gebufferten AND übernimmt, kann (je nach Initwert) einen von der AND Funktion abweichenden Wert haben. Der grosse Unterschied zw. den beiden Beschreibungen liegt im zeitlichen Verhalten. In der kombinatorischen Schaltung ist unbekannt wann das Signal (spätestens) gültig(eingeschwungen) ist, bei einem FF ist es der Einlauf des Takt + registerdurchlaufzeit (clock to output). Man muss also bei kombinatorischer (asynchroner) beschreibung nicht nur die Funktion sondern auch die tausenden möglichen Schaltzeitpunkte beachten. Synchroner Entwurf macht den Entwurf einfacher, da aus den vielen zu bechtenden möglichen Schaltzeitpunkten einer wird, der des Eintreffen des taktes. Aber es gibt Anwendungen wo asynchroner Entwurf möglich und gewünscht ist.
Hallo Xenu, ich habe geglaubt, deine Aussagen > Aber wenn Du Dir den Code aus der Sicht eines Synthesizers anschaust, > stimmt meine Beschreibung sehr wohl. Bei dem ist die > Sensitivitätsliste nämlich egal. Und dann steht der else-Zweig in der > Tat für jeden Zeitpunkt, der keine steigende Flanke von CLOCK ist. beziehen sich auf das folgende Code-Stück, das zwar gültiges VHDL ist, aber sich nicht synthetisieren läßt. process (CLOCK) begin if rising_edge (CLOCK) then TST_OUT <= '1'; else TST_OUT <= '0'; end if; end process; In diesem Fall gilt der else-Zweig (ausgenommen in der Init-Phase des Simulators) für die abfallende Flanke, und nicht nur für alle Zeitpunkte, die nicht die ansteigende Flanke selbst sind. Ein Sythese-Tool, das korrekt arbeitet (und die entsprechende Hardware zur Verfügung hat), müßte daraus ein FF erzeugen, das bei der ansteigenden Flanke den Ausgang auf 1 und bei der abfallenden Flanke auf 0 setzt. Das Umsetzen von VHDL-Prozessen in Hardware heißt ja nicht, daß die Prozesse nun dauernd laufen, weil sie jetzt ja in HW realisiert sind, während sie bei der Simulation mangels Rechenleistung halt nur angestoßen werden, wenn sich die sensitivity list ändert. Das wäre ein falsches Verständnis der Synthese. In Hardware gibt es keine Prozesse, ein Prozess ist nur ein Hilfsmittel für die Simulation.
>Hallo Xenu, >ich habe geglaubt, deine Aussagen >beziehen sich auf das folgende Code-Stück, das zwar gültiges VHDL >ist, aber sich nicht synthetisieren läßt. Darauf bezog es sich auch. >Ein Sythese-Tool, das korrekt arbeitet (und die entsprechende >Hardware zur Verfügung hat), müßte daraus ein FF erzeugen, das bei >der ansteigenden Flanke den Ausgang auf 1 und bei der abfallenden >Flanke auf 0 setzt. Da aber alle aktuellen VHDL-Synthesizer die Sensitivitätsliste ignorieren, "sehen" sie den Code so, wie ich es beschrieben habe. Zum dritten Mal: Ich weiß, das diese Pseudohardware Käse ist. Das habe ich schon bei meinem ersten Posting geschrieben. Wenn die Synthesizer alles so synthetisieren würden, wie ein VHDL-Simulator es handhabt, dann stimmt die Aussage, daß es sich hierbei um ein Flip-Flop mit steigender/fallender Flanke handelt (und man davon ausgeht, daß CLOCK nur den Wert '0' und '1' annimmt). Nur: Es gibt eben bis heute keinen Synthesizer, der das macht. Alle ignorieren die Sensitivitätsliste. Und alle ignorieren "wait for"- Anweisungen, obwohl es ja auch ganz nett wäre, hätten FPGAs programmierbare Verzögerungsleitungen im Pikosekundenbreich, mit denen diese Anweisung dann tatsächlich halbwegs umsetzbar wäre. Zum Thema Flip-Flop mit steigender/fallender Flanke: Coolrunner II können das, synthesefähiger VHDL-Code schaut so aus: process(clk) begin if(clk'event) then if(clk = '0') then q <= a; elsif(clk = '1') then q <= b; end if; end if; end process; Wenn man das "if (clk'event)" weglässt, erkennt er keine FFs, sondern erzeugt Latches. Einem Simulator wäre das Wurst, da das "clk'event" ja eigentlich implizit durch die Sensitivitätsliste vorhanden ist. Aber VHDL-Synthesizer interessieren sich nicht für Liste, das "(clk)" nach "process" kann man auch weglassen. Dann stimmt freilich die Simulation nicht mehr mit der synthetisierten Hardware überein. >Das Umsetzen von VHDL-Prozessen in Hardware heißt ja nicht, daß die >Prozesse nun dauernd laufen, weil sie jetzt ja in HW realisiert sind, Natürlich "laufen" keine Prozesse in der Hardware. Habe ich nie behauptet. Das Gegenteil ist der Fall. Schau mal ältere Postings von mir an. >während sie bei der Simulation mangels Rechenleistung halt nur >angestoßen werden, wenn sich die sensitivity list ändert. >Das wäre ein falsches Verständnis der Synthese. Freilich ist das ein falsches Verständnis. >In Hardware gibt es keine Prozesse, ein Prozess ist nur ein >Hilfsmittel für die Simulation. Natürlich! Volle Zustimmung. Aber nochmals: Ich habe das doch nie behauptet! Ich habe irgendwie das komische Gefühl Du glaubst ich kenne den Unterschied zwischen Synthese und Simulation nicht. Daß aber Synthesizer die Sensitivitätsliste ignorieren, ist Fakt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.