ist es möglich einen process innerhalb eines anderen prozesses zu starten also etwas in der art process(t0) begin case z_alt is when z0 => process(t1) usw.
Jein ... Man kann umständlich Signale setzen, die andere Prozesse triggern. Ist aber oft nicht notwendig und/oder sinnvoll. Gurgel mal nach "Statemaschine"
also wenn es sich bei obigen programmausschnitt um einen automaten handelt welche drei zustände kennt von denen zustand z0 bedeutet eine uhr soll laufen dann brauche ich doch zwangsläufig einen process in z0 der in der sensitivity list einen takt mit 1 sekunde periodendauer enthält um die uhr jede sekunde um eins hoch zu zählen
marco meier schrieb: > also wenn es sich bei obigen programmausschnitt um einen automaten > handelt welche drei zustände kennt von denen zustand z0 bedeutet eine > uhr soll laufen dann brauche ich doch zwangsläufig einen process in z0 > der in der sensitivity list einen takt mit 1 sekunde periodendauer > enthält um die uhr jede sekunde um eins hoch zu zählen Öööh, das war jetzt nicht so ganz verständlich. Erstmal zum Grundlegenden ... Wenn du etwas anderes hast als:
1 | process (clk) |
2 | begin
|
3 | if clk'event and clk='1' then |
4 | ...
|
5 | end if; |
6 | end process; |
Dann richte erstmal das. Es ist fast immer falsch, in der Sensitivity-List was anderes zu haben als nur den clk. Wenn du deinen Prozess so umgebaut hast, kannst du überlegen anfangen, wie du einen anderen Prozess anstoßen und auf sein Ergebnis warten kannst.
marco meier schrieb: > when z0 => process(t1) Oh, ein Softie, der Hardware machen will/soll/muss... ;-) Kurz: du kannst deine komplette Softwaredenkweise vergessen. VHDL ist keine Programmiersprache, sondern eine Beschreibungssprache. Du musst also quasi einen Schaltplann in Text giessen. Wenn du da in vorher und nachher, oder auch in zuerst, und danach denkst, liegst du mit gut 95% Wahrscheinlichkeit daneben. Abläufe in VHDL/Hardware werden in Zustandsmaschinen beschrieben. Ein Flipflop speichert den aktuellen Zustand, und Signale "aussen rum" bilden die Fortschaltbedingung. >> Erstmal zum Grundlegenden ... Richtig:erst mal eine blinkende LED. Wie würdest du das machen? Und warum mache ich das so: http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html Und dann käme schon das legendäre Lauflicht. Machs wieder so: überleg du dir, wie ein Lauflicht mit 8 LEDs aussehen könnte, und dann sieh dir das da an: http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html Such mal hier im Forum nach "VHDL Postulate", du wirst ein paar solche Anfängerthreads finden...
Fetz schrieb: > Dann richte erstmal das. Es ist fast immer falsch, in der > Sensitivity-List was anderes zu haben als nur den clk. Bitte nicht solchen Unsinn verbreiten!
Fetz schrieb: > Erstmal zum Grundlegenden ... Wenn du etwas anderes hast als:process (clk) > begin > if clk'event and clk='1' then > ... > end if; > end process; tomb schrieb: > Fetz schrieb: >> Dann richte erstmal das. Es ist fast immer falsch, in der >> Sensitivity-List was anderes zu haben als nur den clk. > > Bitte nicht solchen Unsinn verbreiten! ich glaube Fetz bezieht sich hier auf synchrone Processe.Es könnte andere Signale in der Sensitivity-List stehen,haben aber keinen Einfluss auf der Process-Aktivierung.
Sparxx schrieb: > ich glaube Fetz bezieht sich hier auf synchrone Processe.Es könnte > andere Signale in der Sensitivity-List stehen,haben aber keinen Einfluss > auf der Process-Aktivierung. Nicht mal das stimmt. Immerhin gibt es noch asynchrone resets in synchronen Prozessen. So wie das Fetz geschrieben hat, sollte man nur getaktete Prozesse verwenden und das ist auf jedenfall Unsinn. Bei einem sauberen Design stehen dort gerade mal die Registerzuweisungen drinnen, der Rest (>95% vom Code) ist rein kombinatorisch und nicht getaktet.
tomb schrieb: > Nicht mal das stimmt. Immerhin gibt es noch asynchrone resets in > synchronen Prozessen. Profi ... Hast du schonmal gesehen, was bei asynchronen Resets passieren kann? Offensichtlich nicht ... > So wie das Fetz geschrieben hat, sollte man nur getaktete Prozesse > verwenden und das ist auf jedenfall Unsinn. Bei einem sauberen Design > stehen dort gerade mal die Registerzuweisungen drinnen, der Rest (>95% > vom Code) ist rein kombinatorisch und nicht getaktet. Das sauberste Design ist 100% getaktet :)
Naja gut, hätte ich einen Account, hätte ich jetzt tatsächlich meinen letzten Post abgeändert. Ich hätte es anders schreiben sollen. Wenn ich Prozesse werwende, dann haben die Prozesse nur clock in der Sensitivity-List. Konbinatorische Logik hat man selbstverständlich auch. Dafür verwende ich aber keinen Prozess ... Erklär die Unterschiede, wann man was nimmt und was nicht mal einem Anfänger ...
Fetz schrieb: > Profi ... Hast du schonmal gesehen, was bei asynchronen Resets passieren > kann? Offensichtlich nicht ... Natürlich, trotzdem verwendet man sie mindesten so häufig wie synchrone Resets. Gerade im ASIC-Bereich wo Fläche zählt, wird man meist asynchrone und nicht synchrone Resets finden. Beides hat seine Berechtigung und manches geht überhaupt nur auf eine Weise. > Das sauberste Design ist 100% getaktet :) Kombinatorik ist nicht getaktet, warum sollte man es in einen getakteten Prozess schreiben? Synchrones Design benötigt halt noch etwas mehr als Flipflops ;) Natürlich ist das nur eine Sichtweise. Viele fahren gut, auch ohne dieser Trennung. Bei etwas größeren Projekten habe ich zumindest festgestellt, dass eine saubere Trennung einfacher zu handhaben ist. Kleinere Dinge wie einen Counter mach ich noch in einem getakteten Prozess. Alles was komplexer ist, wird strikt gesplittet.
tomb schrieb: > Gerade im ASIC-Bereich Ich tippe das Verhältnis Entwickler FPGA:ASIC etwa 95:5 ... > wird man meist asynchrone und nicht synchrone Resets finden. Die wird man da finden, weil die Bauteile so ausgelegt sind. Auf einem FPGA sollte aber immer synchron entwickelt werden, denn nur so kann die Timing-Analyse Fehler entdecken. > Beides hat seine Berechtigung und manches geht nur auf eine Weise. Richtig, und deshalb muss man seine Zielarchitektur kennen. > Kombinatorik ist nicht getaktet, > warum sollte man es in einen getakteten Prozess schreiben? Konterfrage: warum nicht? Nur, weil es in allen Lehrbüchern aus dem letzten Jahrtausend die 2-Prozess-Schreibweise gepflegt wird? Und damit regelmässig Leute kombinatorische Schleifen/Zähler bauen? Meine (getakteten) Prozesse sehen üblicherweise so aus:
1 | process begin |
2 | wait until rising_edge(clk); |
3 | :
|
4 | end process; |
Der Vorteil: keine fehlerhafte Sensitivliste möglich. Ok, VHDL2008 gibts auch... ;-)
Lothar Miller schrieb: >> Kombinatorik ist nicht getaktet, >> warum sollte man es in einen getakteten Prozess schreiben? > Konterfrage: warum nicht? > Nur, weil es in allen Lehrbüchern aus dem letzten Jahrtausend die > 2-Prozess-Schreibweise gepflegt wird? Nein, weil es eher der Hardware entspricht. Ist wohl Geschmackssache, viele kommen auch mit einem Prozess gut zurecht, ich tu mir wesentlich leichter mit (mindestens) zwei Prozessen, weil die Leitungen, FF-In und FF-Out (present und next state) auch so in Hardware vorhanden sind. Find es einfach "natürlicher". > Und damit regelmässig Leute > kombinatorische Schleifen/Zähler bauen? Das hat nichts mit der Schreibweise sondern mit einem Denkfehler zutun. Wenn es daran scheitert, hilft auch eine andere Schreibweise nichts.
tomb schrieb: > Gerade im ASIC-Bereich tja, aber beim ASIC hast du typischerweise auch eine Komponente 'PON-Reset und Clock' drauf. Ausserdem volle Kontrolle ueber die Verdrahtung. Und die Clockverdrahtung ist beim ASIC auch was spezielles... Im Gegensatz dazu hast du beim FPGA oft einen externen Reset und dann noch die Resetleitungen ueber normale Routingresourcen. Wenn das als asynchroner Reset durchs FPGA geroutet wird gibts halt Probleme. Je nach FPGA kann es ja auch sinnvoll sein, einen externen Reset erstmal ueber FFs einzusynchronisieren und dann intern als asynchronen Reset zu verwenden. Haengt halt immer von der Zielplattform ab...
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.