mikrocontroller.net

Forum: FPGA, VHDL & Co. Clk-net verkürzen/aufteilen


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe einen ziemlich vollgepackten (99%) Spartan-3 (XC3S1000), auf
dem das clk-Netz ein Path-Delay von 13,7 ns hat. Durch die vier DCMs
und Takt-Puffer sollte es ja möglich sein, die Taktleitung in mehrere
Netze aufzuteilen. Daher meine Frage(n):

Wie teile ich das Taktnetz praktikabel auf und stelle dabei sicher,
dass
1) das gesamte Design synchron bleibt
2) die Optimierungsmöglichkeiten beim Implementieren nicht zu sehr
beschnitten werden?

Das Design besteht aus vier identischen, hochspezialisierten Cores und
einer Statemachine drumherum. Ein erste Idee ist zwei DCMs jeweils
einen Takt generieren zu lassen und die Takte über kreuz als Regelgröße
in die DCMs rückzuführen...

Danke & Gruß
Christian

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mehrere DCM ist nicht gut.

versuch mal einfach mehrere BUFGs zu benutzen, eg DCM out zu 4 BUFGs
und dann diese clk benutzen, fure jedes von 4 cores sein eigenes BUFG

antti

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, klingt einfach. Fast zu einfach ;-)
Ich werde es versuchen, danke...

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Erfolg ist leider mäßig, da die Logic Utilisation förmlich
explodiert (116%). Ich glaube nicht, dass ich da noch viel mit einem
höheren Effort Level erreichen kann. Im Moment läuft jedenfalls die
Synthese mit nur zwei (statt vier) Taktnetzen.
Hat jemand eine Idee beide Wünsche (Optimierung mit mehreren kurzen
Taktnetzen) unter einen Hut zu bekommen?

Gruß
Christian

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
muhsame arbeit fürs optimimierung, immer wieder in fpga editor
nachgucken was wirklich lost ist.

xilinx tools machen manchmal mist.

zum beispiel wenn ein SRL16 din einen daten eingangs inverter braucht
was man mit eingangs inverter in slice machbar ware, da nimmt xilinx
ISE einfach einen zusats LUT!! nur ein beispiel.

dh heisst man kann nicht voll vertrauen das ISE alles immer bestens
macht, tut es nicht :(

antti

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein globales Taktnetz hat bei Dir wirklich 13,7 ns Delay ?
Das ist ganz ordentlich...
Die andere Frage ist : ist das ein Problem ?
Es gibt ja offenbar nur 1 Takt, wie schnell ist der ?
Wieso geht die Logik auf 116 % wenn Du statt einem glob.
Clock-Buffer 4 nimmst ? Da stimmt doch was nicht .
Ein BUFG für jeden Core sollte doch OK sein.

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das SOLLTE OK SEIN stimmt bei xilix nicht so immer :)
manches was man denkt sollte ist es jedoch nicht.



antti

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Netzlänge konnte ich jetzt in einem zweigeteilten Taktnetz und mit
einigen kleinen Optimierungen auf gute 10ns reduzieren. Das ist zwar
noch nicht das, wo wir hinwollen aber immerhin erträglich.

@FPGA-User
Im Moment läuft das System nur mit 60MHz, das Mindeste wären 100MHz
(die wir nun fast erreicht haben) und das Wunschziel liegt in der
Region 150-200MHz. Die verwendeten IPs (es handelt sich um
hochoptimierte Krypto-IPs die mit verschiedenen Schlüsseln arbeiten)
arbeiten bis ca. 250MHz. Fehlfunktionen/Rechenfehler dürfen wir uns
eigentlich nicht leisten.

> Die andere Frage ist : ist das ein Problem ?

Nunja, ich fände es gewagt den Takt bei dieser Pfadlänge deutlich über
100MHz zu setzen. Zumindet sind die Ergebnisse für mich wenig
vorhersehbar. Vielleicht kann man durch einige Handarbeit im
Floorplanner die Gefahr abschätzen!?!

> Wieso geht die Logik auf 116 % wenn Du statt einem glob.
> Clock-Buffer 4 nimmst ? Da stimmt doch was nicht .

Das Problem, das ich sehe ist, dass die vier Cores identisch sind . Im
Fall eines gemeinsamen Taktnetzes dürften sich große Teile der internen
Kontrolllogik "wegoptimieren" lassen, da die Zustände der IPs synchron
sind. Ich vermute, dass bei getrennten Taktnetzen - die zwar synchron
laufen, aber durch die Namen getrennt sind - diese Optimierung nicht
mehr durchgeführt wird.

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

na das sind ja schon erste Fortschritte. Hinter meiner Frage
"ist das ein Problem" steckt folgendes:
Angenommen, Du hast nur 1 globalen Takt im FPGA, was ideal wäre,
und Du setzt ein Clock-Constraint auf diesen Takt, dann gibt es
aus meiner Sicht erstmal 2 Möglichkeiten
a) Timing-Analyzer(TAN) meldet Fehler
b) TAN meldet keine Fehler/Timing-Verletzungen

Was sagt der TAN bei Dir, wenn Du 100 MHz vorgibst ? Geht das durch?

Im Fall b) sollte Dir das Delay auf dem Clocknetz doch egal sein
können, Hauptsache die Timing-Analyse sagt:
"All constraints were met"
oder ?

Autor: Tobias O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr mal andere synthese tools ausprobiert, precision und synplify
erzeugen in der regel bessere ergebnisse als xst.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FPGA-User
Im Design gibt es zwei Takte, einen Bustakt von 33MHz und den möglichst
hohen Core-Takt der per DCM aus dem Bustakt generiert wird. Der Bustakt
treibt ansonsten nur eine kleine Kommunikationsschicht am Bus und ist
unproblematisch.
Auf die naheliegende Lösung den Takt versuchsweise mit einer
Clock-Constraint zu belegen bin ich natürlich noch nicht gekommen. :-/
Das werde ich gleich nächste Woche ausprobieren, ich habe das aktuelle
Design übers Wochenende leider nicht zur Hand.

@Tobias
In der Lösung mit nur einem Taktnetz war der Unterschied zwischen
Synplify Pro und XST marginal, ich werde aber auch das in der nächsten
Woche noch einmal ausprobieren.

Außerdem werden wir den größten Teil der Toplevel-Statemachine nun in
den externen Buscontroller auslagern. Ich bin fast sicher, dass sich
dadurch ein großer Sprung in der Geschwindigkeit erreichen lässt.
Vielen Dank bereits jetzt für die Tips, ich werde mich wieder melden,
sobald ich neue Ergebnisse habe. Aber jetzt ist erstmal Wochenende :-)

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

das hast Du doch nicht ernst gemeint, dass Du kein Clock-Constraint
gesetzt hattest ;-)
Einen randvollen 3s1000 und die Synthese ohne Constraints gestartet,
bei 2 Taktnetzen und DCMs mit dem Ziel 150 - 200 MHz , nee das
kann nich sein ....

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peinlich genug ist es ja... in den Tools ist zwar überall die
Optimierung hochgedreht, aber in den Constraints haben wir es wirklich
nicht gesetzt. Man, man, man, Sachen gibt es duckundweg

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

späte Antwort, aber die Priorität liegt im Moment auf anderen Teilen
des Projekts.
Die Constraints und einige kleine Optimierungen haben scheinbar
geholfen, das Design lässt sich nun ohne Fehlermeldung auch mit 150 MHz
synthetisieren und läuft auch - in den meisten Fällen. Bei niedrigerem
Takt in allen Fällen. Dem ist noch auf den Grund zu gehen :-(

Noch eine andere (blöde?) Frage: wenn ich bei der Synthese den DCM
weglasse und auf einem Dev-Board direkt den Takt einstellen will
liefert mir der Timing-Report bis zu halb so lange (!) Pfadlängen für
das interne Taktnetz wie mit vorgeschaltetem DCM. Ist das ein Phänomen
auf das ich keine Hinweise in den Xilinx-Docs finde oder liegt das
wirklich an der Pfadverlängerung durch einschleifen des DCMs?

Gruß
Christian

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.