Hallo, ich möchte eine State Machine schreiben, die sofort in den nächsten Zustand springt, wenn der vorherige "abgearbeitet" ist. Bisher verwende ich eine getaktete FSM, möchte aber nicht immer bis zum nächsten Takt warten, um in den nächsten Zustand zu wechseln. Mir fällt allerdings nicht ein, wie das gehen könnte. Ist das generell möglich? Viele Grüße, Oliver.
Ja, aber du musst trotzdem jeweils warten, bis alle Teile der Kombinatorik eingeschwungen sind. Das läuft letztlich auch auf einen quasi synchronen Betrieb hinaus, weil man immer auf den langsamst denkbaren Weg warten muss - und es ist viel aufwändiger. Das einfachste bleibt, eine vollsynchrone FSM mit der maximal erzielbaren Frequenz laufen zu lassen. Das ist das Limit und es ist mit der Unterstützung der Tools viel einfacher zu erreichen, als per Hand.
Nicht so einfach mit den Tools, die es so allgemein gibt, die sind nämlich auf synchrones Design, also getaktete Logik ausgelegt. Es gibt asychnrone Designmethoden, die ungefähr das leiten, das Du willst, aber die sind nicht für den Normalanwender auf einer normalen Architektur geeignet. Abgesehen davon muss man ja auch die Umgebung der FSM betrachten, das ist ja auch üblicherweise getaktete Logik und damit nicht so einfach zum Zusammenspielen mit nicht getakteter Logik gedacht. Insofern: was immer das Problem ist, asynchrone Logik ist fast sicher nicht die Lösung dafür. lg flint
Oliver B. schrieb: > ich möchte eine State Machine schreiben, die sofort in den nächsten > Zustand springt, wenn der vorherige "abgearbeitet" ist. Nicht so ohne weiteres. Denn wer validiert denn den "neuen" Zustand? Das was du da gerade bauen willst, das machen andere aus Versehen. Es nennt sich "Kombinatorische Schleife": http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife
Es gibt spezielle FPGAs die asynchron laufen. Mir ist so, als ob Achronix so etwas im Angebot hat. Wie schon gesagt. Mit "nocrmalen" FPGAs wirste so etwas wohl nicht hinbekommen. Würde mich mal interessieren, ob schon mal jemand mit den Achronix Devices gearbeitet hat...
Rein logisch betrachtet könnte es funktionieren. Aberdu hast ja Signallaufzeiten, z.B. du hast Signal A und B, Signal A kommt vor B, jedoch ist die Laufzeit durchs FPGA von A langsamer als B. Schon ist man im falschen State. jetzt könnte man sagen naja dann füge ich halt gleich viele dummy gatter dazwischen ein ! Aber Die haben ja auch Toleranzen. Man müßte letztendlich immer irgendwie die Signale Synchronisieren. Und damit ist es wieder Synchron irgendwi. Ein "Hybriddesign", bei dem ein bestimmter Bereich asynchron Signale verarbeitet und auswertet bzw. Berechnet usw. kommt schon öfters vor. Eigentlich fast in jeder Statemachine.
Also Leute... Ich wette 1000€ darauf, das ein vollkommen asynchrones Design nicht das ist, was der Threadersteller eigentlich will, auch wenn er es im Moment denkt.
War nicht der Mealy- oder Moore-Automat ungetaktet d.h. asynchron? Schon ein büschen her die Automatentheorie :-) Auf jeden Fall holte man sich mit den asynchronen Schaltwerken immer so schlimme Sachen wie Glitches, Hazards und Races rein.
naja beim Mealy ist die Ausgangslogik Kombinatorisch und hängt wiederrum von den Eingängen ab. Die Eigentliche State-Umschaltung ist jedoch wieder getaktet. Mir wäre da keine Statemachine bekannt die sowas macht. Aber es gibt Ansätze für selfclocked HW - aber wie weit das fortgeschritten sein soll - keine Ahnung. Ich habe dort auch nur am Rande etwas mitbekommen. Das würde aber denke ich sehr nahe an dem liegen, was der Thread-Ersteller haben möchte.
coolcoker schrieb: > War nicht der Mealy- oder Moore-Automat ungetaktet d.h. asynchron? Schon > ein büschen her die Automatentheorie :-) SCHMERZEN!!! Aua! Die Automatentheorie sagt nichts aber auch gar nichts über die technische Realisierung von Automaten aus, da ein Automat nur ein ziemlich abstraktes Konstrukt ist. Ob man das nun als Digitalschaltung, in Software oder als Wasserspiel implementiert wird, hat nichts mit Mealy oder Moore zu tun.
Das hört sich so an, wie wenn diese FSM in einem idealen Baustein in der Zeit 0 durchlaufen würde/müsste... coolcoker schrieb: > War nicht der Mealy- oder Moore-Automat ungetaktet d.h. asynchron? Schon > ein büschen her die Automatentheorie :-) Jeder Automat hat Speicherglieder. Und die technisch am einfachsten handzuhabenden Speicher sind nunmal getaktete...
Hallo, vielen Dank die zahlreichen Antworten, sie haben mir vom Verständnis her weitergeholfen. Vielleicht lässt sich das, was ich machen will, besser mit sequentieller Logik erreichen. Ich versuche das auf die Schnelle mal in Pseudo-VHDL zu fassen (bitte nicht auf Syntax achten, bin gerade erst dabei VHDL zu lernen):
1 | process (clock, reset) |
2 | variable x : unsigned ( A to B ); |
3 | begin |
4 | if (reset =! '1') then |
5 | x := 0; |
6 | output <= (others => '0'); |
7 | elsif (rising_edge(clock)) then |
8 | |
9 | x := 0; |
10 | do |
11 | x := x + 1; |
12 | ... |
13 | while (bedingung) |
14 | |
15 | output <= x; |
16 | end if; |
17 | end process; |
Ich werde das nachher mal im Simulator ausprobieren. Allerdings bin ich mir immer unsicher bei sequentieller Logik, weil es ja immer heißt, dass VHDL keine Programmiersprache ist und dann weiß ich nicht, was sich am Ende auch synthetisieren lässt. Viele Grüße, Oliver.
Oliver B. schrieb: > Ich werde das nachher mal im Simulator ausprobieren. Der kann das schon. Aber deine Hardware kann das nicht... :-/
1 | :
|
2 | elsif (rising_edge(clock)) then -- ein Takt hat KEINE Dauer!!! |
3 | :
|
4 | while (bedingung) -- und währenddessen soll auf irgendwas gewartet werden? |
Davon mal abgesehen: Was, meinst du, macht eine (while-)Schleife in VHDL?
Lothar Miller schrieb: > Der kann das schon. Aber deine Hardware kann das nicht... :-/ Stimmt, ich habe es probeweise mal geschrieben und in der Simulation tut das tadellos, aber while-Schleifen lassen sich wohl leider nicht in Hardware umsetzen. Was ich schreiben möchte, ist ein Hardware-Dividierer. Ich dachte, ich mach das, indem ich den Divisor einfach so oft vom Divident abziehe, bis nichts mehr übrig bleibt (while...). Mit einer getakteten State-Machine hat es übrigens auch schon funktioniert. Allerdings gibt es da ja wesentlich effizientere Verfahren. Verwende jetzt eines, das so funktioniert, wie man es auf Papier macht, salopp formuliert (siehe Anhang). Ich habe es jetzt mal als ungetakteten Prozess implementiert, der die Eingänge (Divident und Divisor) in seiner sensitivity list hat. Das geht jetzt von den State-Machines weg, aber würdet ihr das Entity noch mit Clock und Reset versehen? Welche Vor- / Nachteile hätte das in diesem Fall?
Oliver B. schrieb: > aber while-Schleifen lassen sich wohl leider nicht in > Hardware umsetzen. Doch, aber das gibt nicht die Hardware, die du erwartest. Da wird nicht auf irgendwas gewartet, sondern einfach mehrfach parallele Hardware erzeugt. > Allerdings gibt es da ja wesentlich effizientere Verfahren. Wie definierst du Effizienz? Schnelligkeit? Resseourcenverbrauch? > Ich habe es jetzt mal als ungetakteten Prozess implementiert Wie schnell ist das Ding? Wieviele Ressourcen braucht das Ding? Vergleich das mal damit: http://www.lothar-miller.de/s9y/categories/24-Rechnen Oliver B. schrieb: > Das geht jetzt von den State-Machines weg, aber würdet ihr das Entity > noch mit Clock und Reset versehen? Nein. Wozu? Du brauchst hier keinen Reset und keinen Takt. > Welche Vor- / Nachteile hätte das in diesem Fall? Vorteile: keine Nachteile: Warnungen
Also das hier:
1 | for i in N downto 0 loop |
2 | ...
|
3 | v_divident := v_divident - (v_divisor * (2**i)); |
4 | ...
|
5 | end loop; |
bekommst du meines Wissens nicht synthetisiert...
Damit würdest du einen riesigen komplett kombinatorischen Divider bauen. Das frisst eine Unmenge an Ressourcen. Da du Anfänger bist, wirst du mit ziemlicher Sicherheit so etwas nicht brauchen.
Martin Geisse schrieb: > Also das hier: .... > bekommst du meines Wissens nicht synthetisiert... Warum nicht? Was davon sollte Probleme machen? Ich würde das aber auch eher mit einem Shift machen, denn 11 Multiplizierer brauchen schon Platz... :-)
Lothar Miller schrieb: >> Also das hier: .... >> bekommst du meines Wissens nicht synthetisiert... > Warum nicht? Was davon sollte Probleme machen? Die Tatsache, dass ein FPGA kein Prozi ist, und VHDL kein C. VHDL ist ein virtueller Lötkolben. Du verbindest Elemente mit Leitungen. Zeitliche Abläufe à la C kann der prinzipiell nicht verarbeiten. Variablen in VHDL kannst du zwar schon innerhalb von Prozessen nacheinander überschreiben, aber das sind bloss "Hilfskonstrukte", um das letztendliche Verhalten des Prozesses nach aussen zu schildern. Der Synthi macht daraus eine Wahrheitstabelle für kombinatorische Logik, oder eben FlipFlops, wenn er aufgrund bestimmter Patterns erkennt, das Du wohl FFs willst. Das zu mischen, ist schon ein bisschen gefählich (mit Sorgfalt zu machen)... aber wenn Du solche Rückkopplungen und zeitlche Abläufe synthetisieren willst, überforderst Du den Synthie. Denn Du sagst ihm dann zwar, was Du am Schluss eigentlich willst, aber nichts darüber, wie er das um Himmels Willen bewerkstelligen soll. Natürlich kannst Du mit kombinatorischen Feed-Backs arbeiten, aber das ist ein so heisses Eisen, dass sehr kluge Köpfe da sehr gut aufpassen müssen, dass nichts schief geht. Und der Syntie kann das sicher nicht automatisch machen. Ausserdem: Du sagst, das FPGA soll N+1 mal etwas machen. Das heisst, da muss ein Zähler hin, der zählt, wie oft der das schon gemacht hat. Wo ist der? Den muss der Synthie nun also selber irgendwie erfinden und schlau einbinden. Du siehst: Du lässt den Synthie die Denkarbeit erledigen. Und denken kann der nicht. Was Du natürlich machen kannst, ist, Divisionseinheiten nacheinander zu schalten. Mit Generic-Anweisungen. Das ist aber wieder was ganz anderes.
Simon Huwyler schrieb: > Natürlich kannst Du mit kombinatorischen Feed-Backs arbeiten Das ist kein Feedback, das ist einfach ein Baum aus Multiplizierern/Shiftern und Subtrahierern.
Simon Huwyler schrieb: > Du sagst, das FPGA soll N+1 mal etwas machen. Ja nun, ich eigentlich nicht... ;-) > Das heisst, da muss ein Zähler hin, der zählt, wie oft der das > schon gemacht hat. Wo ist der? Hier: for i in N downto 0 loop Damit weiß der Synthesizer genau genug, wieviele Stufen er hintereinanderschalten muß... ;-) > Du siehst: Du lässt den Synthie die Denkarbeit erledigen. Naja, ich nun wieder nicht... > Und denken kann der nicht. Aber Rechnen kann der. Sauschnell...
> Ich wette 1000€ darauf, das ein vollkommen asynchrones Design nicht > das ist, was der Threadersteller eigentlich will Ich setze maximal €1,00 dagegen :-)
Der Trick bei anynchronen Statemaschinen besteht eigentlich nur dadrin, dass jeder Zustandswechsel nur maximal EIN Bit im Zustandsvektor verändern darf. Bei 4 Zuständen sind z.B: alle Übergänge erlaubt ausser 00 - 11 und 01 - 10, da sich hier 2 Bits ändern. Für einen asynchrone Zähler kann man sich auch mal den Gray-Code anschauen. (http://de.wikipedia.org/wiki/Gray-Code) Der Besucher
> > Also das hier: .... > > bekommst du meines Wissens nicht synthetisiert... > Warum nicht? Was davon sollte Probleme machen? Sorry, ich hatte da fälschlicherweise ein asynchrones Feedback gesehen, aber da v_divident eine Variable ist und die Anzahl der Schleifendurchläufe konstant kann der Synthie das wahrscheinlich wirklich ab.
Hakt das ab. Es wird nicht wirklich schneller und ist kaum zu verfizieren oder mit Redundanz zu belegen, wenn man sicherers Verhalten braucht. Lieber die Frequenz hochdrehen.
Hallo, abermals vielen Dank für die Antworten. Ich versuche mal beim Divider zu bleiben, auch wenn die anderen Aspekte interessant sind: Lothar Miller schrieb: > Ich würde das aber auch eher mit einem Shift machen, denn 11 > Multiplizierer brauchen schon Platz... :-) Stimmt, das kann man umschreiben, aber passiert das nicht während der Synthese automatisch ? Ich kenne es von C-Compilerns so, die diese Art Optimierungen machen. Passiert das bei VHDL nicht oder in geringerem Maße?
Oliver B. schrieb: > Stimmt, das kann man umschreiben, aber passiert das nicht während der > Synthese automatisch ? Ich kenne es von C-Compilerns so, die diese Art > Optimierungen machen. Passiert das bei VHDL nicht oder in geringerem > Maße? Es passiert bei VHDL auch. Es werden Optimierungen gemacht, die das Verhalten des Codes nicht verändern. Aber: Ob eine Division nun rein kombinatorisch durch massiv parallele Hardware, oder in mehreren Takten durch sequenzielle Nutzung der Hardware geschieht, ist ein riesiger Unterschied. Von daher sind automatische Optimierungen dieser Art ausgeschlossen.
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.