www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Eintakten - Konsequenz ?


Autor: Clemens M. (panko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael O. (mischu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  d  <= uCdata when rising_edge(wr);

  process begin
     wait until rising_edge(clk);
     wrA <= wr;
     wrB <= wrA;
     if (wrB='0' and wrA='1') then -- steigende Flanke
        data_in <= d;
     end if;
  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:
  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...

Autor: Clemens M. (panko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael O. (mischu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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,...

Autor: Michael O. (mischu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:).

Autor: Clemens M. (panko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dienstleistererfahrener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mir tut es immer um das unnötige Silizium leid
:-)

Es gibt aber Apps, die die abgespeckten SC-Resourcen überwiegend 80% 
nutzen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.