mikrocontroller.net

Forum: FPGA, VHDL & Co. taktbedinge Verzögerung von Signalen automatisch ermitteln und setzen


Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht um das Problem, dass bei Berechnungen von Daten aus 
unterschiedlichen Modulen die richtig verzögerten Kopien miteinander 
verrechnet werden müssen.

Nun habe ich das Problem, dass einige Rechenmodule sagen wir 6 Takte 
verzögert sind, andere 13 und wieder andere über 30. Um sie richtig zu 
verrechnen, müssen die langsamen entsprechend verzögert werden.

Wenn ich in einem Modul mal was ändern muss, weil das timing nicht 
getroffen wird und FFs hinzugefügt werden müssen, muss der Rest auch 
angepasst werden.

Wie macht man das am Besten?

Kann man das Delay irgendwie rausbekommen?

Die Synthese muss es ja auch kennen, wenn sie FFs hinzufügt oder 
verschiebt und muss den Rest dazu passend ändern.

Kann man das mit generate irgendwie dynmisch halten?

Momentan zähle ich in ModelSIM die Takte und passe es per Hand an. 
Problem: Mal vertut man sich und nix stimmt!

Gesucht ist eine automatisierte Lösung!

Autor: daniel__m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

wenn sich häufig was änderst, dann würde ich vermutlich in jedem Modul 
ein begleitendes "Valid" durchleiten, welches dann am Ende ein Fifo 
bedient, welches hinter jedem Modul hängt. Diese Fifo ist so groß, dass 
der maximale Skew abgefangen werden kann. Sind alle Fifos nicht leer, 
kann ich Daten gesammelt auslesen und der weiteren Verarbeitungskette 
zuführen.

grüße

Autor: Thomas R. (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Klaus,

es soll Menschen geben, die schreiben dazu eine Dissertation

http://diglib.uni-magdeburg.de/Dissertationen/2003...

Kapitel 4 und 6


Eine einfache Lösung gibt es nicht. Der FIFO Ansatz kann viele 
Ressourcen verbrauchen, denn jedes Modul muss soviel Stufen 
bereithalten, wie dass mit der größten Latenz zu dem es parallel 
geschaltet werden kann.

Tom

Autor: Strubi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Moin,

in VHDL geht das typischerweise nur über manuelle Klimmzüge und Delays, 
in MyHDL geht's etwas eleganter. Wenn es zur Laufzeit programmierbare 
Delays sein müssen, wird es hässlich, dafür flexibel (wenn die totale 
Latenz nicht so eine Rolle spielt).
Das kann man dann mit Microcode-Slots erledigen, die gegeneinander 
verschoben werden, wenn sich in der Pipeline was ändert, bzw. genau 
solche Buffer-Register steuern, wie von daniel_m beschrieben.
Das Problem mit solch in Logik instanzierten Mini-FIFOs ist schnell mal 
die Verstopfung, und damit das Zusammenbrechen der f_max, (drum 
"hässlich").

- Strubi

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> es soll Menschen geben, die schreiben dazu eine Dissertation

Interessant. Wenigstens mal eine Dissertation mit Wert :-)

>FiFo
Ich verwende in der Tat meistens FiFos weil die RAMs bei den meisten 
Apps in ausreichender Zahl vorhanden sind. Die Steuerung erfolgt über 
variable delays. Etwas flexibler geht es mit einer halbautomatisierten 
Synthese in Excel, die die delay-Namen vergibt und die benötigten FFs 
einstellt. Heute ist das um so praktikabler, weil die Synthese unnötig 
verschwendete FFs in RAMs schieben kann.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Wenn es zur Laufzeit programmierbare
> Delays sein müssen, wird es hässlich

Ich denke, es geht um die Entwicklung und nicht um die Laufzeit. Ich 
wüsste auch kaum Fälle, wo das flexibel bleiben müsste.

Trotzdem ist das ein Thema! Wie man das automatisch verifiziert, kann 
ich auch nicht sagen, ich speise immer ein erstes markantes Datum in 
ModelSim und prüfe das korrekte Weiterschalten. Man kann auch einen 
einzigen gültigen Wert in die pipeline schieben und beobachten, ob und 
wann er versiegt. Nur wenn alle timing delays stimmen, kommt der Wert 
valide durch.

Autor: Schlumpf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vielleicht habe ich das Problem nicht ganz verstanden, aber wenn jedes 
dieser Module, welches Daten liefert, ein Valid-Signal mit ausgibt, 
welches einen Takt lang ist, dann muss das Modul, welches die Daten 
miteinander verrechnet, doch nur warten, bis das letzte der Module ein 
gültiges Datum abgeliefert hat und kann dann mit der Berechnung 
beginnen.

Sollte das schnellste der Module zwischenzeitlich schon ein neues Datum 
geliefert haben, dann muss dieses eben in ein FIFO abgelegt werden. Oder 
das Modul muss über einen Handshake-Mechanismus "ausgebremst" werden.

So muss also nur einmal die Schnittstelle auf ihr korrektes Timing 
überprüft werden. Wird ein Modul verlangsamt oder beschleunigt, dann 
funktioniert es ganz automatisch trotzdem noch.

Oder habe ich hier das Problem nicht richtig erfasst?

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternativvorschlag:
Die ermittlung der latentz würde ich in der Simulation mit den 
"passenden pattern machen. Beispielsweise, wenn 2 streams elementeweise 
multipliziert und anschliessend akkumuliert werden, dann würde ich einen 
Stream mit ab 1 steigenden Werten starten (1,2,3,4,5,...) und den 
anderen mit alles 0 außer einer '1' an einer einzelnen Position bspw 5. 
(0,0,0,0,1,0,0,...)

erscheint bei der Simulation eine 5 ist alles i.o. bei 4 muss eine 
Latenz eingefügt werde etc..

Das latenz wurde ich mit einem extra modul machen dem ich diese latenz 
per generic mitteile. dann hat es keinen großen aufwand. Man kann das 
generic auch in einem package festhalten, das macht spätere Änderungen 
einfacher. Dieses Modul kann man aus SRL16E macros (bei Xilinx Spartan) 
oder ähnlichen aufbauen, das sind schieberegister die bereits ein 
generic für die Länge des schieberegister haben (siehe 
http://www.xilinx.com/support/documentation/white_...)


Also nicht "automatisch" sondern gezielt nach Ermittlung der notwendigen 
Verzögerung durch Simulation.

Wenn automatisch dann könnte man mit tcl scripten die netzliste (nach 
Synthese/mapping) durchparsen und so die FF im jeweiligen Pfad zählen. 
Das ging zumindest mit dem Cadance synthesetool. Bei xilinx könnte es 
sein das man die backannotierte EDIFF-Netzliste mit perl o.ä. bearbeiten 
muß.

Aber wie bereits betont, den Verzug gebe ich einer Ermittlung der 
Verzögerung in der Simulation.

MfG,

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlumpf schrieb:
> Vielleicht habe ich das Problem nicht ganz verstanden, aber wenn jedes
> dieser Module, welches Daten liefert, ein Valid-Signal mit ausgibt,
> welches einen Takt lang ist, dann muss das Modul, welches die Daten
> miteinander verrechnet, doch nur warten, bis das letzte der Module ein
> gültiges Datum abgeliefert hat und kann dann mit der Berechnung
> beginnen.
Genau so mache ich das auch.
Ich habe mir dafür entsprechende Datentypen erstellt:
    type uint8_t is
    record
        value  : unsigned( 7 downto 0);
        enable : std_ulogic;
    end record;
    constant default_uint8_c : uint8_t := (
        value  => (others => '-'),
        enable => '0'
    );
    ....
Wenn ein Modul auf mehrere Werte warten muss, werden die mit ihrem 
enable gelatcht und wenn alle da sind, geht es los.
Das Ergebnis hat wieder ein enable, was für einen Takt lang '1' ist.

Ob die Latenzen passen, sehe ich in der Testbench. Ggf. kann man eine 
Assertion werfen, wenn die neuen Werte zu schnell kommen sollten.

Duke

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Schlumpf schrieb:
> dann muss das Modul, welches die Daten
> miteinander verrechnet, doch nur warten, bis das letzte der Module ein
> gültiges Datum abgeliefert hat

Damit ist aber kein kontinuierlicher Betrieb möglich, weil das 
langsamtes Modul die anderen ausbremst.

Bei Bildverarbeitung z.B. wird ja mit jedem Takt ein Datum eingeworfen 
und soll hinten aus der Schlange rausfallen. Wenn irgendwo in der Kette 
eine Verzeigung und später eine Konjuktion auftritt, müssen die Pfade 
gleich langs sein. Da führt kein Weg dran vorbei.

Kurze Verzögerungen realisiert man daher mit FFs - lange mit RAMs, so 
verfügbar.

Nimm mal z.B. die Situation, dass der Betrag eines Vektors mit seinem 
Grundwert verrechnet werden soll, dann hast Du f(x,y) = g(x,y) o Wurzel 
(x*x,y*y). Die Wurzel dauert aber eine Weile in VHDL und es müssen 
später die dazugehörigen x,y verrechnet werden und nicht etwa die 
aktuellen. Bei einer VHDL-Wurzel mit hoher Auflösung gehen da schon mal 
30 Takte dahin. In dem Fall kann man es auch nicht automatisch machen 
lassen, weil die Verzögerung nicht konstant ist. Selbst beim 
System-Generator, der die Verzögerung ja kennt, musste man das noch per 
Hand einstellen. (!!!)

In anderen Fällen ohne Core ginge auch die rabiate Methode, nämlich 
alles in Variablen oder als Kombinatorik zu formulieren und dann ein 
FF-Grab hinten dran zu hängen, die der Synthesizer dann bitte passend 
hinbalanciert. Das geht aber nur für kurze Pfade, wie ich feststellen 
musste, weil sich die Synthese da gerne mal verrennt! Ich habe sogar 
Fälle, wo das vorsorgliche Hinzufügen von FFs zu schlechteren Ergebnisse 
führt, weil es nicht gebacken bekommt.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Duke Scarring schrieb:

> Wenn ein Modul auf mehrere Werte warten muss, werden die mit ihrem
> enable gelatcht und wenn alle da sind, geht es los.
Das heisst aber doch auch wieder, daß das Modul entweder warten muss, 
oder die pipe so getrimmt ist, dass es immer stimmt!

Und: Die Problematik tritt ja nicht nur über Module hinweg auf, sondern 
auch innerhalb jedes VHDL-Moduls. Die Rechenlängen müssen stimmen - 
siehe das Wurzelbeispiel hier drüber.

> Ob die Latenzen passen, sehe ich in der Testbench.
D.h. es kommt eben doch wieder auf händisches Beobachten an, ob die 
richtigen enables zusammenarbeiten. Wenn es eine kontinuierliche pipe 
ist, hätte man zudem ein Dauer-enable.

Mir fällt aber gerade eine Methode ein, wie man es automatisieren 
könnte, damit die Synthese immer die richtigen Werte verrechnet. Es 
würde sogar zur Laufzeit funktionieren, wenn sich die Rechnung verändert 
und eine andere Latenz bräuchte:

Man erzeugt zum Startzeitpunkt für jeden Datenpfad einen Zähler in einem 
solchen record, der mit hochgezählt wird. Verarbeitet werden nur Daten 
mit gleichem Zählerstand. Nun hat man zwei Möglichkeiten:

1) Man formuliert die Bedingung in die Rechnung mit rein, was dazu 
führt, dass die Rechnung ausfällt, solange man einen Fehler hat. Das 
Design arbeitet also wenn, dann richtig oder garnicht.

2) Man führt die Pfade auf FIFO-RAMs und verwendet die Zähler als 
Schreib-Adressen. Damit steuern sich die Delays selber und am Ausgang 
kommen immer die richtigen zu einander passenden Daten an. Das würde 
auch zur Laufzeit stimmen. Wenn man die Laufzeitumschaltung nicht 
benötigt, ermittelt man im ModelSIM aus der Differenz zwischen Lese und 
Schreibadresse das sich ergebende Delay und trägt es als statischen 
Vorlauf für jedes RAM ein. Dann werden die Zähler wegsynthetisiert.

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich habe da eine "Ebene" abstrakter gedacht.

Ich ging davon aus, dass die Daten langsamer kommen (nicht zu jedem 
Takt) und die Berechnungsfunktion eben für n Takte beschäftigt ist, bis 
sie überhaupt wieder ein neues Datum annehmen kann. Dann wäre das mit 
dem Valid-Signal eine Lösung.

So wie ich es jetzt aber verstanden habe, dauert eine Berechnung n 
Takte, aber mit jedem Takt wird schon ein neues Datum in die Berechnung 
nachgeschoben und hinten purzeln mit n Takten verzögerung, aber mit 
JEDEM Takt ein neues Ergebnis raus.
Dann ist das mit dem Valid-Signal natürlich nicht anwendbar.

Autor: Tom W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Mir fällt aber gerade eine Methode ein, wie man es automatisieren
> könnte, damit die Synthese immer die richtigen Werte verrechnet. Es
> würde sogar zur Laufzeit funktionieren, wenn sich die Rechnung verändert
> und eine andere Latenz bräuchte:

Welchen Anwendungsfall siehst Du da und wozu muss der 
Synthesemechanismus das zur "Compilezeit" (wenn man das so nennen kann) 
"wissen"?

Es würde doch einfach eine Verzögerungskette aus Delay-Gliedern reichen, 
die man zur Not umschalten kann! Bei uns entwickeln sie das mit 
MATLAB-Simulink und der hat ein solches Delay drin. Es ist rein virtuell 
und wird vom Synthesizer ausgefüllt.

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> Eine einfache Lösung gibt es nicht. Der FIFO Ansatz kann viele
> Ressourcen verbrauchen, denn jedes Modul muss soviel Stufen
> bereithalten, wie dass mit der größten Latenz zu dem es parallel
> geschaltet werden kann.

Hallo Thomas, das sieht sich sehr interessant aus, komme aber irgendwie 
auch nicht auf den Punkt, wo in der Arbeit dargelegt wird, wie sich das 
automatisieren liesse.

Ich denke, man müsste VHDL irgendwie dazu befähigen, eine Art von 
Zeitpunkten einzuführen, auf die sich der Entwickler bei der 
Formulierung des Zugriffs beziehen kann. Der Synthesizer müsste dann in 
der Lage sein, ausreichend viele Takte einzusetzen, wenn nötig.

Keine Ahnung, ob es sowas gibt.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer mag: Hier ist ein Ansatz für die Lösung des Problems in Python:

http://opencores.org/project,lateq

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.