guten Morgen! Daß man zum fpga Takt asynchrone Signale eintakten sollte, ist mir inzwischen bewusst. Beim Gedanken schweifen lassen bin ich aber noch über einige Verständnisschwierigkeiten gestolpert. Ich stelle mir einen asynchronen Trigger vor, der wird durch 2 FF eingetaktet. Das bedeutet doch aber, daß das fpga auf das interne Signal entsprechend später reagiert, also der Systemtakt 3 mal so hoch sein muss? Bei kurzen Latenzzeiten stelle ich mir das schwierig vor. Bei meinen mini-Spartan3 Designs wird selten mehr als um die 200 MHz maximalen Takt genannt. Bei 130 MHz Ram o.ä. nicht so viel. Hängt das fpga am Bus eines Mikrocontrollers stelle ich mir 2 Fragen: Takte ich diesen Bus auch ein? Also im Grunde alle Signale. Oder ist das unnötig. Wirkt es sich aus, wenn das fpga den Takt des uc bereitstellt (der sollte doch dann nicht asynchron sein) oder der uc eine eigene Taktquelle hat? Wenn ich ein asynchrones Signal habe, welches eingetaktet wird. Und wenn dieses Signal mit synchronen Signalen in Interaktion tritt, haben die ja wieder einen Latenzunterschied von x-Takten. Da muss ich dann die Synchronen ebensosalnge eintakten, oder wie komme ich damit klar? Also was weiß ich ein asynchrones Write Signal und einen synchronen, nciht eingetakteten Datenbus. schönen Tag. Vielleicht stellt ja der eine oder andere Fortgeschrittene fest, daß er ähnliche Kopfknoten hatte und hat weitere Erläuterungen.
> Ich stelle mir einen asynchronen Trigger vor, der wird durch 2 FF > eingetaktet. Das bedeutet doch aber, daß das fpga auf das interne Signal > entsprechend später reagiert, also der Systemtakt 3 mal so hoch sein > muss? Die Frage ist, was Du erreichen willst. Das reine eintakten bedeutet erstmal, dass ein Signal mit Flankenwechseln zu beliebigen Zeiten auf den Abttasttakt gezwungen wird. Somit geht auch der zeitliche Bezug einer Flanke des Signals vor dem Abtasten verloren und stellt sich synchron zum internen Takt dar. Bezogen auf ein Triggersignal: Die erste Abtastung erzeugt einen Jitter (zeitlich nicht korrellierte Latenz), jede weitere Abtastung danach erzeugt eine feste Latenz. Soll das Triggersignal schnell ein Ereignis auslösen, dann gibt es nur die Möglichkeiten die Abtastfrequenz zu erhöhen und die Pufferlänge zu reduzieren. Eine Erhöhung der Abtastfrequenz reduziert auch den zeitlichen Jitter. Bezogen auf einen Eingangsdatenstrom: Ist die Abtatstrate ein ganzzahliges Vielfaches der Datenrate, dann wird der zeitliche Bezug des Eingangsdatenstroms auf den internen Takt gebogen. In den meisten Fällen ist die Latenz nicht von entscheidender Bedeutung. > Hängt das fpga am Bus eines Mikrocontrollers stelle ich mir 2 Fragen: > Takte ich diesen Bus auch ein? Also im Grunde alle Signale. Oder ist > das unnötig. Wirkt es sich aus, wenn das fpga den Takt des uc > bereitstellt (der sollte doch dann nicht asynchron sein) oder der uc > eine eigene Taktquelle hat? Ich nehme mal an, dass Du im FPGA einige Register implementieren möchtest, die per uC geschrieben und gelesen werden sollen. Physikalische Grenzegeschwindigkeit für ein asynchrones System ist die Gesamtlatenz von Quelle zur Senke. Das merkt man insbesondere beim Lesen aus einem externen Baustein: Zunächst muss ein uC/DSP/whatsoever die Adresse der Speicherstelle sowie ein Lesesignal (plus Chip Select) erzeugen. Der angesprochene Baustein benötigt Zeit bis er sich angesprochen fühlt, intern die Adresse korrekt dekodiert hat und die Daten über eine Datenleitung an den Ausgangsport anlegt. Diese Daten müssen dann noch korrekt in den Eingangspuffern des uC anliegen bevor sie dort festgehalten werden können. Zudem kommen noch Signallaufzeiten aufgrund der Abstände, Delays durch kapazitive Lasten und die begrenzte Stromfähigkeiten der Ausgangstreiber. Da dies schon vor Jahren im PC-Bereich zu einem Flashcenhals führte, gibt es neben asynchronen RAMs noch BurstRAMs (synchron) sowie jede Form von SDRAM (SDR, DDR, etc) Speicher. Du hast eigentlich keine Wahl! Bis zu einer bestimmten Geschwindigkeit wird es mit einem asynchronen Baustein klappen, danach leider nicht mehr.
Clemens M. schrieb: > Das bedeutet doch aber, daß das fpga auf das interne Signal > entsprechend später reagiert, Richtig. Das nennt man Jitter und Latency... > Hängt das fpga am Bus eines Mikrocontrollers stelle ich mir 2 Fragen: > Takte ich diesen Bus auch ein? Nein, du taktest hier nur die nötigen Steuersignale ein. Und jetzt wird es interessant: wenn du z.B. ein WR# Signal hast, dann kannst du direkt mit dessen Flanke die Daten ins FPGA übernehmen. Dann das WR#-Signal einsynchronisieren und wenn das stabil ist, die (logischerweise auch stabilen) Daten und Adressen ins FPGA übernehmen. Etwa so:
1 | d <= uCdata when rising_edge(wr); |
2 | |
3 | process begin |
4 | wait until rising_edge(clk); |
5 | wrA <= wr; |
6 | wrB <= wrA; |
7 | if (wrB='0' and wrA='1') then -- steigende Flanke |
8 | data_in <= d; |
9 | end if; |
10 | end process; |
Interessant wird das dann evtl. beim Lesen vom FPGA, wenn keine Wait-States eingefügt werden können. Aber auch da kommt man idR. ohne "Übertakten" zum Ziel. Hier schaltet aber auf jeden Fall das OE# (oder RD#) Signal die Richtung der Ausgangstreiber direkt ohne Eintakten um:
1 | uCdata <= data_out when oe='0' else 'Z'; |
Und dann müssen schnellstmöglich gültige data_out im FPGA beschafft werden. Auf jeden Fall noch bevor der uC seinen buszyklus fertig hat...
Klingt logisch was ihr so sagt :-) Nun muss ich das natürlich in den nächsten Tagen erst mal praktisch ausprobieren und am besten auch auf einem Board ans laufen bringen. Ich habe ja noch kein konkretes Problem; ist alles nur einem Gedankenspiel entsprungen. P.S. Ich komme so langsam zu dem Schluss, daß ab einem gewissen Punkt in der fpga Welt der Erfahrungsschatz (noch) wichtiger wird, als in der Controller Welt. Das ist natürlich ne echte Herausforderung als Privatmann. Aber zum Glück gibts ja das Forum hier.
Du kannst Dir ein Teil des Problems sparen, wenn Du direkt einen Softcore im FPGA nutzt :) Dann muss der Zugriff nicht über die langsamen externen Leitungen mit den dicken Kapazitäten.
> Du kannst Dir ein Teil des Problems sparen, wenn Du direkt einen > Softcore im FPGA nutzt Es gibt, wenn man sich mal selber nichts vorlügt, nichts ineffizienteres als einen Softcore in einem FPGA. Das ist ein schönes Spielzeug für Entwickler, aber jeder billige uC kann bei gleichen Systemkosten mehr und braucht dafür weniger Energie. Das ist leider so, mir wäre es auch lieber, wenn sich das mit den Softcores (incl. Entwicklungsumgebung, Royalties und irgendwelchen Lizenzen für Hardwareerweiterungen) richtig realistisch rechnen würde... Ich nehme hier ausdrücklich solche Beispiele aus, in denen das passend hingerechnet wurde: Ein FPGA ist eh' schon da und es ist sowieso zu groß, usw, usf,...
Holla Lothar, Du hast sicher in 95% der Fällen Recht. Ich möchte auch keine Diskussion um Sinn / Unsinn von Softcores starten. Da die Summe allen Übels stets konstant ist hängt es auch stark von der konkreten Aufgabe ab, welche Lösung das Optimum darstellt. Für Feld-Wald-Wiesen Applikationen bei denen der Preis wichtiger als die Performance ist wird man sicher keinen Softcore einsetzen. Wenn die Geschwindigkeit jedoch der entscheidende Faktor ist (wie bei Clemens zumindest angedeutet) dann wird ein externes Businterface sicher den Bottleneck darstellen - und dann kann ein Softcore hilfreich sein :).
Nein, nein, war rein akadamisches Interesse um das Drumherum um Eintakten besser zu verstehen. Ein Softcore ist mit Sicherheit in der Praxis mal eine Option. Mal auch nicht. Für mich im Speziellen derzeit auf keinen Fall. Zum einen mache ich ja nur mini bis kleine Projekte als Hobby und zum anderen fühle ich mich zu 100% ausgelastet mit vhdl an sich. Da wäre eine unbekannte Softcore Technik mit unbekannten Entwicklungswerkzeugen und neuen Problemen der GAU ;-)
Das Problem ist doch, dass eine Softcore-Implementierung mit weinger als 30% des im FPGA genutzten Referenztakts läuft. Klar, der Softcore kann dann mit einem kleinen ARM7 oder ARM9 mithalten. Beim vergleich zu einem Cortex-A9 oder Supers. PowerPC stinkt er aber gnadenlos ab. Meistens fehlt für sowas aber dann die Applikation dies wirklich bräuchte :-)
Tobi schrieb: > Das Problem ist doch, dass eine Softcore-Implementierung > mit weinger als 30% des im FPGA genutzten Referenztakts läuft. Mir tut es immer um das unnötige Silizium leid, das da in Form von ungenutzten Schaltern, Routingressourcen und LUTs auf dem FPGA ein tristes Dasein fristet und aus Frust nur Leckströme produziert... ;-) OT: Jetzt sind wir aber wieder mal ganz hübsch von der eigentlichen Frage abgekommen...
>Mir tut es immer um das unnötige Silizium leid
:-)
Es gibt aber Apps, die die abgespeckten SC-Resourcen überwiegend 80%
nutzen.
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.