Hallo, ich habe zwei Fragen bezüglich der Flankenerkennung von Signalen. Die steigenden und fallenden Flanken des Systemtakts (clk) eines FPGAs kann man mit 'event oder rising_edge() auswerten... 1. Ist es auch möglich "normale" Eingangssignale der Länge 1 Bit auf diese Weise abzufragen? 2. Wie sieht es aus, wenn man Operationen in Abhängigkeit eines anderen Taktsigals durchführen will? (Das Taktsignal kommt von einem externen Baustein, der an das FPGA angeschlossen ist.) Kann man hier 'event und rising_edge() verwenden?
FPGA schrieb im Beitrag #2436888: > Die steigenden und fallenden Flanken des Systemtakts (clk) eines FPGAs > kann man mit 'event oder rising_edge() auswerten... Diese Betrachtungsweise ist grundlegend falsch. Diese Flanken werden nicht irgendwie "ausgewertet", sondern der Takt ist an Flipflops angeschlossen und taktet diese. > 1. Ist es auch möglich "normale" Eingangssignale der Länge 1 Bit auf > diese Weise abzufragen? Radio Eriwan würde antworten: Im Prinzip ja, aber... > 2. Wie sieht es aus, wenn man Operationen in Abhängigkeit eines anderen > Taktsigals durchführen will? (Das Taktsignal kommt von einem externen > Baustein, der an das FPGA angeschlossen ist.) Kann man hier 'event und > rising_edge() verwenden? Radio Eriwan würde antworten: Im Prinzip ja, aber... ... du hast dann 2 Taktdomänen (Systemtakt und der "Andere"). Und wenn du das "andere" Signal dann in deine Systemtaktdomäne übergeben willst/musst, dann mußt du dir wieder Gedanken über das Einsynchronisieren in diese Taktdomäne machen.
Ist es möglich, diese zwei Taktdomänen zu umgehen? Das heißt, ist es aureichend, wenn man sich ein Hilfssignal deklariert, das den alten Wert des ursprünglichen Signals speichert... um es schließlich mit dem aktuellen Wert vergleichen zu können? Dadurch würde man auch Flanken auswerten können. Oder kommt das auf das gleiche heraus? In meinem aktuellen Code frage ich die externen Taktsignale mit 'event ab... Wenn ich die Funktionsweise des geschriebenen Codes mit ModelSim überprüfe, kommt eigentlich das richtige Ergebnis heraus.
FPGA schrieb im Beitrag #2436912: > Wenn ich die Funktionsweise des geschriebenen Codes mit ModelSim > überprüfe, kommt eigentlich das richtige Ergebnis heraus. Ja, nur eben in der Hardware nicht. Dann hast du z.B. einmal pro Minute/Stunde/Tag/Woche einen eigenartigen Fehler, deine Statemachine hüpft blödsinnig hin- und her, Zähler zählen eigenartig usw... > Ist es möglich, diese zwei Taktdomänen zu umgehen? Ja, oder Nein. Das hängt von den Anforderungen ab. Am einfachsten: dein FPGA läuft nur auf 1 Takt, und externe Signale werden standesgemäß einsynchronisiert: Siehe dazu: http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren Und danach kommt die klassische Flankenerkennung: http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung http://www.lothar-miller.de/s9y/archives/3-Tastenentprellung-mit-Schieberegister.html Das geht, solange dein FPGA-Takt ausreichend schnell gegenüber dem Signal ist. Wenn die Frequenzen/Zeiten der beiden in ähnliche Regionen kommen, und/oder du durch das Eintakten eine nicht annehmbare Latenz bekommen würdest, dann mußt du die beiden Taktdomänen in Kauf nehmen und einen Mechanismus zur Datenübergabe (Synchronisation) zwischen beiden Taktdomänen einbauen.
Mein Systemtakt beträgt ca. 30MHz und das externe Taktsignal weist eine Frequenz von ca. 75MHz auf. Also komme ich um die beiden Taktdomänen nicht herum?
FPGA schrieb im Beitrag #2436993: > Also komme ich um die beiden Taktdomänen nicht herum? Richtig, du wirst aber zusätzlich noch einen Mechanismus überlegen müssen, die Datenrate zu reduzieren, denn wenn du 2 1/2 mal so schnell Daten hereinbekommst, wie du später verarbeiten kannst, dann gibt das langfristig ein Problem... Was kommst da mit 75MHz an?
Einen Mechanismus um die Datenrate zu reduzieren? Wie kann man das machen? Da fällt mir jetzt spontan leider keine Lösung ein. -- Pro externer Taktperiode kommen 40 RGB- und Steuerbits an, die weiterverarbeitet werden müssen.
FPGA schrieb im Beitrag #2437043: > Pro externer Taktperiode kommen 40 RGB- und Steuerbits an, die > weiterverarbeitet werden müssen. Ach, du willst mit einem Display rummachen... Wenn diese Daten so mit 75MHz /reinkommen/: was machst du dann damit und wie gehen sie wieder raus? Was willst du mit diesen Daten auf der 30MHz Seite? Meine Vorgehensweise wäre hier, das Design zum größten Teil auf dem Display-Takt laufen zu lassen. Und nur irgendwelche unkritischen Steuersignale über die Domänengrenze weg zu führen.
An meinem FPGA sind verschiedene Taster, ein IIC-Bus und LVDS-Receiver angeschlossen. Pro Receiver werden 40 RGB- und Steuerbits geliefert. Mit Hilfe der Taster und dem IIC-Bus (Datenwort) kann angegeben werden, welche RGB- und Steuerbits weiterverarbeitet und weitergeleitet werden sollen... Bisher wurden die RGB- und Steuerbits mit dem Systemtakt (30 MHz)eingelesen und anhand der Einstellungen (durch Taster, IIC-Bus) weiterverarbeitet. Auch das hat laut ModelSim funktioniert. Das heißt, je nach Einstellung wurden die richtigen RGB- und Steuerbits angesprochen und auch richtig weiterverarbeitet. Nun habe ich die Aufgabe bekommen, die Daten mit dem Receiver-Takt (75 MHz)einzulesen und zu verarbeiten. Eigentlich habe ich hier schon eine Frage. Warum ist die Umstellung auf den 75MHz Receiver-Takt überhaupt nötig? Das "Steuerwort", das durch die Taster und den IIC-Bus erzeugt wird, ändert sich sowieso nur mit dem Systemtakt. Wie schon erwähnt, vorher hat alles funktioniert. Die RGB- und Steuerbits wurden lediglich zum Systemtakt übernommen.
FPGA schrieb im Beitrag #2437122: > wurden die RGB- und Steuerbits mit dem Systemtakt (30 MHz)eingelesen Ein 75MHz Signal wurde mit 30MHz eingelesen? Das funktioniert aber bestenfalls, wenn ein Signal auf der 50MHz Seite mindestens 3 Takte lang stabil ist... > Warum ist die Umstellung auf den 75MHz Receiver-Takt überhaupt nötig? > Das "Steuerwort", das durch die Taster und den IIC-Bus erzeugt wird, > ändert sich sowieso nur mit dem Systemtakt. Das heißt, dich interessiert eigentlich nur die Richtung von "langsam" nach "schnell"? > Das "Steuerwort", das durch die Taster und den IIC-Bus erzeugt wird, > ändert sich sowieso nur mit dem Systemtakt. Dein Vorteil ist, dass vermutlich ein einzelner Fehler nicht so kritisch ist, weil sowieso ständig "frische" Daten nachkommen. Ein kurzer Aussetzer beim Bild ist sowieso kaum zu sehen oder störend...
Ich bin jetzt mittlerweile leider ziemlich verwirrt und weiß überhaupt nicht mehr, wie ich an die Sache heran gehen soll. Ich möchte die Datenbits eigentlich nur mit dem 75 MHz Takt einlesen und weiß nicht genau wie, da mein Systemtakt 30 MHz beträgt.
FPGA schrieb im Beitrag #2437178: > Ich möchte die Datenbits eigentlich nur mit dem 75 MHz Takt einlesen und > weiß nicht genau wie, da mein Systemtakt 30 MHz beträgt. einlesen koenntest du sie mit einem 40bit breiten FIFO (75MHz), auslesen dann halt am 2. Port mit 30MHz. Damit du dabei den FIFO nicht ueberrennst, musst du halt in der 30MHz Domain 3 entries pro Takt auslesen (also den FIFO auf dieser Seite 3*40bit breit machen)
FPGA schrieb im Beitrag #2437178: > Ich möchte die Datenbits eigentlich nur mit dem 75 MHz Takt einlesen und > weiß nicht genau wie, da mein Systemtakt 30 MHz beträgt. Ja, das geht nun mal nicht. Aber du hast doch geschrieben, dass das bisher auch schon (irgendwie) gemacht wurde und funktioniert hat. Was ist jetzt also NEU oder ANDERS? > Ich möchte die Datenbits eigentlich nur mit dem 75 MHz Takt einlesen Und was willst du danach damit machen? Ab in die Tonne? Oder speichern und verarbeiten? Lothar Miller schrieb: > ein Signal auf der 50MHz Seite mindestens 3 Takte lang stabil... Sollte heißen "auf der 75MHz Seite"...
Und warum benutzt du nicht der Einfachheit halber für alles den 75Mhz Takt ?
Ich konnte meinen entwickelten Code bisher nur mit ModelSim testen... nicht an der realen Schaltung! Deshalb habe ich noch einige Probleme und konnte das entstandene Bild nicht beurteilen. Mitterweile glaub ich, dass ich einen Denkfehler mache. 1. Neu ist, dass die RGB- und Steuerbits mit dem 75 MHz Receiver-Takt eingelesen werden sollen. Vorher wurden sie mit dem 30 MHz Takt eingelesen. Das heißt, ich habe wirklich immer drei Bit unterschlagen - bzw. sie sind garanitert nicht 3 Bit lang stabil. 2. Ich möchte die RGB- und Steuerbits zur steigenden Flanke des Receiver-Takts einlesen (und verarbeiten)
Meine Überlegung war, die RGB- und Steuerbits immer mit der steigenden Flanke des Receiver-Takts einzulesen. Dadurch würde ich keine Bits unterschlagen.
FPGA schrieb im Beitrag #2437237: > Neu ist, dass die RGB- und Steuerbits mit dem 75 MHz Receiver-Takt > eingelesen werden sollen. Vorher wurden sie mit dem 30 MHz Takt > eingelesen. Das heißt, ich habe wirklich immer drei Bit unterschlagen - Heißt "vorher" = "in einem real funktionierenden Design"? Und dieses Design soll jetzt von dir geändert werden? Oder heißt "vorher" = "in einer funktionalen Testbench"? Wie reell/gut sind deine Stimuli-Signale in deiner Testbench? FPGA schrieb im Beitrag #2437242: > Meine Überlegung war, die RGB- und Steuerbits immer mit der steigenden > Flanke des Receiver-Takts einzulesen. Dadurch würde ich keine Bits > unterschlagen. Richtig, und dann war noch unbeantwortet: Lothar Miller schrieb: > Und was willst du danach damit machen? Ab in die Tonne? Oder speichern > und verarbeiten?
- "Vorher" heißt in einer funktionalen Testbench! - Die letzte Frage versteh ich nicht - "ab in die Tonne". Es handelt sich um ein Projekt...
FPGA schrieb im Beitrag #2438181: > - Die letzte Frage versteh ich nicht - "ab in die Tonne". Ja nun, du liest die Daten in der 75MHz Domäne irgendwie ein. Und gibst sie dann (teilweise oder komplett) auf die 30MHz Domäne. Und dann? Was machst du dort damit? Werden dort dann Berechnungen mit den Displaydaten gemacht? Und wieder irgendwo ausgegeben? > - "Vorher" heißt in einer funktionalen Testbench! Das bedeutet also in keinster Weise, dass das Design auf realer Hardware auch nur 1 Minute fehlerfrei gelaufen wäre... Denn so wie du es beschreibst (Einlesen eines 75MHz-Signals mit 30MHz), da muss das fast schon zwingend Probleme geben.
Nachdem die Daten mit dem höheren Takt eingelesen und verarbeitet wurden, sollen sie an einen Framegrabber weitergereicht werden. Leider verstehe ich nicht, wie du das meinst, Daten auf der 75MHz Domäne einlesen und dann an die 30MHz Domäne geben.
FPGA schrieb im Beitrag #2438232: > Leider verstehe ich nicht, wie du das meinst, Daten auf der 75MHz Domäne > einlesen und dann an die 30MHz Domäne geben. nachdem es getrennte clock signale sind, müssen die signale ja über eine "clock-Grenze" weitergegeben werden. Zumindest in deinem alten Entwurf. Wenn der neue Entwurf nur mehr am 75MHz clock rennt, arbeite einfach mit den Signalen.
FPGA schrieb im Beitrag #2438232: > sollen sie an einen Framegrabber weitergereicht werden. Der dann auch mit 30MHz arbeitet? FPGA schrieb im Beitrag #2437242: > Meine Überlegung war, die RGB- und Steuerbits immer mit der steigenden > Flanke des Receiver-Takts einzulesen. Dadurch würde ich keine Bits > unterschlagen. Richtig, und dann mußt du diese schnell anfallenden Daten ohne "Pufferüberläufe" in deine langsame Domäne übergeben. FPGA schrieb im Beitrag #2438232: > Leider verstehe ich nicht, wie du das meinst, Daten auf der 75MHz Domäne > einlesen und dann an die 30MHz Domäne geben. Mal angenommen, die Daten kommen mit 75MHz 24Bit (3x8) breit herein, dann hast du da 1800MBit/s (75MHz * 24Bit). Um diese Daten mit 30 MHz verarbeiten zu können, muß dein Datenkanal bei diesem Takt mindestens 60Bit breit sein (1800MBit/s / 30Mhz). Sinnvoller sind natürlich 72 Bit, dann passen 3 von den 24Bit-Paketen rein. Die Übergabe von 75MHz nach 30MHz erfolgt also im einfachsten Fall mit einem Zwischenpuffer (Fifo), der 3*24 Bit speichern kann. Das wurde schon mal im Beitrag "Re: Flankenerkennung von Signalen" angesprochen..
Lautete die Frage nicht einfach, wie man die Datenbits der LVDS-Receiver mit dem zugehörigen (höheren) Takt einliest und nicht mit dem Systemtakt? Warum ist es dann nicht zulässig, sein Programm so aufzubauen: process(reset, clk) begin ... -- Aktionen in Abhängigkeit des Systemtakts end process; process(reset, Receiver_Takt) begin ... -- Aktionen in Abhängigkeit des Receiver-Takts ... -- Einlesen der Datenbits end process; Lothar Miller schrieb: > Die Übergabe von 75MHz nach 30MHz erfolgt also im einfachsten Fall mit > einem Zwischenpuffer (Fifo), der 3*24 Bit speichern kann. Bei der Lösung von Lothar Miller müssen die 72 Bits doch auch erst mit 75MHz eingelesen werden.
Anfänger schrieb: > Bei der Lösung von Lothar Miller müssen die 72 Bits doch auch erst mit > 75MHz eingelesen werden. Ja, klar, denn nur dieser Takt ist schnell genug. Aber dann, wenn die 72 Bit da sind, hat die 30MHz-Domäne die Chance, die Daten rechtzeitig zu übernehmen...
Ich glaube, dass war gar nicht die Frage! "FPGA" wollte lediglich wissen, ob man die Daten auf die nachfolgende Weise einlesen kann. process(reset, clk) begin ... -- Aktionen in Abhängigkeit des Systemtakts end process; process(reset, Receiver_Takt) begin ... -- Aktionen in Abhängigkeit des Receiver-Takts ... -- Einlesen der Datenbits end process; Und das dürfte machbar sein! Oder darf ein Desin nicht wie oben gezeigt, aufgebaut sein, oder?! Anschließend kann er seine Daten normal an den Ausgang weiterleiten.
Wozu sollte das gut sein? Dann geht doch dauern was verloren. Stell dir eine 2-spurige Autobahn vor, auf der mit konstantem Abstand ohne Unterbrechung Autos mit 72 km/h angefahren kommen. Wenn du jetzt auf beiden Spuren 30 km/h ab einer bestimmten Stelle machst, was passiert dann wohl? Genau, Unfall und im betsen Fall stau. Entweder machst du 5 Spuren für 30 auf, oder du musst die Autos gleich schnell weiterfahren lassen. Alles andere gibt Blechschaden.
Christian R. schrieb: > Wozu sollte das gut sein? Wozu sollte WAS gut sein? Ergibt das überhaupt Sinn? Wenn alle Autos ab einer bestimmten Stelle konstant mit 30 km/h fahren, dann passiert auch kein Unfall, genauso wie bei 72 km/h.
Der Vorschlag von "Anfänger" macht keinen Sinn. Man kann Daten die kontinuierlich mit 72 MHz reinkommen, nicht mit 30 MHz weiterverarbeiten, wenn man nicht die Breite des Datenpfades ändert. Solche "Lösungsvorschläge" wie hier Beitrag "Re: Flankenerkennung von Signalen" sind dann einfach völlig daneben... Von daher: Anfänger schrieb: > Und das dürfte machbar sein! Oder darf ein Desin nicht wie oben gezeigt, > aufgebaut sein, oder?! Darf schon, aber nur wenn man Datenverlust in Kauf nimmer.
Micha schrieb: > dann passiert auch kein Unfall, Es geht nicht um den Unfall, sondern um den Stau! > Wenn alle Autos ab einer bestimmten Stelle konstant mit 30 km/h fahren Tun sie aber nicht. Sie fahren zuerst (ab Display-Hafen) mit 75km/h. Und dann kommen sie in einen Bereich (in FPGA-Hausen), wo sie nur 30km/h fahren dürfen. Was müssen die Stadtplaner also tun, damit es nicht zum Stau kommt? Richtig: sie müssen alle Straßen so breit bauen, dass der Auto-Durchsatz ausreichend hoch ist, und immer hübsch 3 nebeneinander fahren können...
Hehe, langsam wirds lustig hier, aber vielleicht hilfts ja endlich mal zur Einsicht :)
Nun gut, aber man kann die Datenbits in diesem Prozess "process(clk, Receiver_Takt) begin" einlesen, gleichzeitig wie gewünscht umcodieren und an die entsprechenden Ausgänge des FPGAs weiterleiten. (also alles in diesem Prozess) Wo spielt da dann der Systemtakt (30 MHz) rein?!
Anfänger schrieb: > Nun gut, aber man kann die Datenbits in diesem Prozess > "process(clk, Receiver_Takt) begin" > einlesen, gleichzeitig wie gewünscht umcodieren und an die > entsprechenden Ausgänge des FPGAs weiterleiten. (also alles in diesem > Prozess) Ja, klar. Du hast ja mehrere Taktnetze in deinem FPGA, da kannst du ohne weitere Synchronisation einige unabhängige Designs in dem ding unterbringen. Nur, wenn du zwischen diese Teilen (Taktdomänen) Daten austauschen willst, dann brauchst du passende Mechanismen.
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.