Hallo, ich bespaße ein CMOD S7 board von Digilent mit einem dort verbauten Spartan XC7S25-1CSGA225C. Dem möchte ich gerne ODELAY aus der Xilinx IP beibringen, damit kann man outputs (0..31)*(39ps oder 52ps oder 78ps) verzögern. (das ist nicht viel Zeit, in 39ps schafft es die elektromagnetische Welle gerade mal 11mm weit). In der Xilinx doku ug471_7Series_SelectIO.pdf lese ich 'Output Delay Resources (ODELAY)—Not Available in HR Banks'. HR sind 'High-range' I/O. In ds180_7Series_Overview.pdf finde ich für meinen XC7S25 150 HR I/O, sonst nix. Ein Vivado design mit ODELAY für den XC7S25 läuft durch die Synthese, bei der Implmentierung beschwert es sich, dass es nicht den richtigen I/O finden kann. Heißt das, dass mein XC7S25 zu ODELAY nicht in der Lage ist oder habe ich da was falsch verstanden oder übersehen? THX Cheers Detlef
Detlef _. schrieb: > 39ps schafft es die elektromagnetische Welle gerade mal > 11mm weit). 8mm in Kupfer, 6mm in Silizium Wenn der FPGA nur HR-Ausgänge haben sollte, wird das wohl so sein. Du kannst alternativ einen anderen FPGA einstellen und es bauen lassen. Dann schaust du ob es überhaupt geht. Eigentlich sollte das Werkzeug aber nur die IPs anbieten, die im gewählten FPGA auch existieren. Hast du die Delays händisch eingesetzt?
wird wohl so sein: - du hast die entsprechende Stelle im Datenblatt gefunden - das Synthesetool hat das Datenblatt bestätigt
ODELAYs gibt es in der 7 Serie erst ab den Kintex/Virtex, Spartan und Artix haben keine HP Bänke und damit auch keine ODELAYs.
Wie genau sind denn die Zellen in diesen niederklassigen FPGAs, d.h. wie schnell lässt sich da einen Bus takten? Kann die Synthese das Routing ausreichend gut manipulieren, um die Randbedingungen einzuhalten?
Oder noch ganz anders gefragt: Kann man / muss man sich die Verzögerungszellen selbst bauen?
Was willst du eigentlich genau machen? Welche Anwendung steckt dahinter? Mit deiner Salamitaktik an Informationen kann man das zum jetzigen Zeitpunkt nicht mit ja oder nein beantworten.
Wenn's odelay vermisst werden, kann man ja dieses auch mit einem dedizierten clock für die Outflipflops in Grenzen nachbauen. Dieser dedizierte clock ist natürlichvon dem Referenzierten clock mit einem phase shift zu generieren. Bspw. https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf S.84
Horst schrieb: > Wie genau sind denn die Zellen in diesen niederklassigen FPGAs, Hängt von der Verteilung der Ausgänge ab. Einige 50 bis 100ps sind das schon. Das Routing kann das teilweise ausgleichen. Problematisch wird es bei wenigen Pins und wenn selbige schon festgelegt sind. Dann gibt es wenig Spielraum. Besonders problematisch sind Busse, die über mehrere Bänke gehen. Bei einem Spartan 6 Design hatte ich das Problem, dass der halbe Bus 200ns mehr Offset hatte, als der andere teil und das bei 148.5 MHz Videotakt. Das schränkt das Budget schon ganz schön wein. Horst schrieb: > Oder noch ganz anders gefragt: Kann man / muss man sich die > Verzögerungszellen selbst bauen? Kann man und tut man auch. Die Schwierigkeit bei solchen Designs ist ja auch durch das PCB-routing gegeben und Produktionsschankungen, sowie thermische Aspekte. Daher kann man sich eine Verzögerungszelle bauen und sie mit Logik umschalten umd das Routing zu erhöhen. Das in VHDL zu bauen ist aber nicht ausreichend. Man muss dann mit der Platzierung und den FGPA Editor arbeiten. In einer Anwendung wo es um die synchroniserte Schaltung von Hochleistungsbauelementen ging, habe ich das so eingebaut. Das war letztlich genauer, als das 50ps Raster, das der Hersteller in den Delays snbot. Meine Schaltung misst und balanciert - sozusagen eine Art permanentes Eintrainieren. Damit bekommt man Werte besser als 20 ps hin. Man muss aber wirklich die Technologie simulieren und z.B. zusehen, dass man den MUX nicht im Bereich des Taktvorgangs verändert. Sonst kriegt man diesen Effekt: http://96khz.org/htm/noisegenerator2.htm
Hi, ja, denn werde ich die Verzögerungszellen mal selbst probieren zu bauen. Ich benötige nur 2 gegeneinander verschiebbare Flanken, also keinen Bus. Ich nehme also eine Inverterkette und zapfe die über einen Muxer an. Die output pins müssen auch direkt an der kombinatorischen Logik hängen und dürfen nicht 'registered' sein, bin ich zufällig drüber gestolpert. Ist das ein Plan, der funktionieren könnte, bin FPGA newbie? THX Cheers Detlef
Kommt auf den Anwendungsfall an. Das ist super unstabil was du vorhast. Ich wuerde wie oben beschrieben ne PLL nehmen und da einen Takt nehmen den du in der Phase sehr praezise und stabil regulieren kannst. Je nach Anwendung kannst du das sogar dynamisch anpassen und mit Trainingsdaten kalibrieren (sofern du die Moeglichkeit in der Datensenke hast).
Ok, dann probier ich das so. Dazu werde ich mir zwei phasenverschobene clocks basteln. Mit denen treibe ich zwei verschiedene I/O banks ( ich glaube es gibt jeweils nur eine clock für eine bank, richtig ?! ) . Ich schicke dasselbe Signal dann zweimal registered auf den beiden banks raus und kriege die damit ebenfalls phasenverschoben. Hoffe, ich habe das so richtig verstanden. THX Cheers Detlef
Wie die Clocking Architektur beim Spartan 7 im Detail aussieht, weiss ich gerade garnicht. Wahrscheinlich gibts da auch wieder zig Alternativen, auch abhaengig von der Taktrate die du hast. Ich wuerde im Zweifel erstmal mit einer Global Clock arbeiten und das dann falls noetig anpassen. Dann hast fuer den Anfang am wenigsten Aerger. :-)
Wie verhindert man eigentlich, dass der VHDL2gate-compiler "unnütze" LUTs zur Signalverzögerung einfach wegspart? Sonst sparen die Compiler nämlich noch ziemlich gut alles weg, was nicht gebraucht wird, aber im Code steht.
:
Bearbeitet durch User
Tobias B. schrieb: > Wie die Clocking Architektur beim Spartan 7 im Detail aussieht, weiss > ich gerade garnicht. Wahrscheinlich gibts da auch wieder zig > Alternativen, auch abhaengig von der Taktrate die du hast. Ich wuerde im > Zweifel erstmal mit einer Global Clock arbeiten und das dann falls > noetig anpassen. Dann hast fuer den Anfang am wenigsten Aerger. :-) https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf 114 Seiten. Verstehe nicht allzuviel. Muss mal sehen, dass ich die PLLs in Betrieb nehme. Ist wie mit frischem Führerschein in einem F1 Boliden. Wird schon, THX. Cheers Detlef
Rote T. schrieb: > Wie verhindert man eigentlich, dass der VHDL2gate-compiler "unnütze" > LUTs zur Signalverzögerung einfach wegspart? Compiler abhängig, bei Xilinx XST das VHDL attribute dont_touch und keep https://www.xilinx.com/support/answers/54699.html und eventuell noch ein paar compile-Schalter (Optimierung ausschalten) https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug901-vivado-synthesis.pdf .S44 - ATTRIBUTE DONT_TOUCH S.50 ATTRIBUTE KEEP Wobei das in manchen Fällen nicht ausreicht, weil nicht die Lgik sondern das Routing die Signallaufzeit bestimmt. Dann muß man sich das 'dedicated Routing' anschauen. Und natürlich mit den timing constraints und timing_driven routing die Toolchain in die richtige Richtung schicken. https://www.xilinx.com/publications/prod_mktg/club_vivado/presentation-2015/paris/Xilinx-TimingClosure.pdf > Ist wie mit frischem Führerschein in einem F1 Boliden. Schlechter Vergleich, es ist nicht zu erkennen, das du überhaupt einen Führerschein nach Bestehen einer Prüfung und nach 'Fahrschule' hast. IMHO ist es eher so, das du einen Bausatz für ein Flugzeugmodell vor dir hast und jetzt versuchst, ohne Durcharbeiten der Montageanleitung, allein vom Werbe-foto auf dem Pappkarton das Ganze korrekt zusammenzusetzen und anschliessend zum Fliegen zu bringen.
Fpgakuechle K. schrieb: >> Ist wie mit frischem Führerschein in einem F1 Boliden. > Schlechter Vergleich, es ist nicht zu erkennen, das du überhaupt einen > Führerschein nach Bestehen einer Prüfung und nach 'Fahrschule' hast. Dieser Vergleich hat auch etwas dran, das ich passend finde: Es ist klar, dass man so nicht auf die Strecke geht, sondern in den Simulator :-)
Fpgakuechle K. schrieb: >> Ist wie mit frischem Führerschein in einem F1 Boliden. > Schlechter Vergleich, es ist nicht zu erkennen, das du überhaupt einen > Führerschein nach Bestehen einer Prüfung und nach 'Fahrschule' hast. > IMHO ist es eher so, das du einen Bausatz für ein Flugzeugmodell vor dir > hast und jetzt versuchst, ohne Durcharbeiten der Montageanleitung, > allein vom Werbe-foto auf dem Pappkarton das Ganze korrekt > zusammenzusetzen und anschliessend zum Fliegen zu bringen. Wie ich Dinge lerne kannst Du getrost mir überlassen, Kommentar dazu wird auch schnell übergriffig. Das Lernen gelingt mir seit vielen Jahren eigentlich ganz gut. Cheers Detlef
:
Bearbeitet durch User
Rote T. schrieb: > VHDL2gate Detlef _. schrieb: > 114 Seiten. Verstehe nicht allzuviel. Muss mal sehen, dass ich die PLLs > in Betrieb nehme. Ist wie mit frischem Führerschein in einem F1 Boliden. > Wird schon, THX. Ok, dann wuerde ich wirklich ne Global Clock nehmen, das ist erstmal relativ easy. Und die PLL hat ein funktionierendes Simulationsmodell. Da kannst du die Phasenverschiebung garantiert sehen. :-)
Detlef _. schrieb: > Das Lernen gelingt mir seit vielen Jahren > eigentlich ganz gut. Ja, das sagen alle mit Dunning-Kruger. https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
HomukoVodeFa schrieb: > Detlef _. schrieb: >> Das Lernen gelingt mir seit vielen Jahren >> eigentlich ganz gut. > > Ja, das sagen alle mit Dunning-Kruger. > https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt Denkfehler. Bei Dunning-Kruger ( danke für den Hinweis ) geht es um Kompetenz oder Inkompetenz. Ich sprach von 'Lernen', das ist die Änderung der Kompetenz, sozusagen die erste Ableitung, wenn Dir das was sagt. Cheers Detlef
Detlef _. schrieb: > Denkfehler. Bei Dunning-Kruger ( danke für den Hinweis ) geht es um > Kompetenz oder Inkompetenz. Nein es geht um die realistische Selbstwahrnehmung. Ein Inkompetenter Mensch der sich seiner Inkompetenz bewußt ist, fällt nicht unter Dunning Kruger. > Ich sprach von 'Lernen', das ist die > Änderung der Kompetenz, sozusagen die erste Ableitung, wenn Dir das was > sagt. Erster Ableitung ist jedem Schulkind aus dem Mathematikunterricht der Sekundarstufe II bekannt und ist als Mathematisches Methode bei der Beschreibung psychischer Leistungsfähigkeit eher fehl am Platz. Und Lernen schließt allgemein betrachtet auch den Erwerb/Perfektionierung von Inkompetenz ein, siehe 'Erlernte Hilfslosigkeit', aber auch Hochstapelei wie bei Narzissten. https://de.wikipedia.org/wiki/Erlernte_Hilflosigkeit https://de.wikipedia.org/wiki/Narzissmus https://de.wikipedia.org/wiki/Gert_Postel Auch die Fähigkeit sich und Andere über den tatsächlichen Stand seiner Kompetenz zu täuschen ("Mehr Schein als Sein") ist selbst eine Kompetenz. Eine Form dieser Täuschung ist, mit der Kenntnis eher grundlegender mathematischer Begrifflichkeiten zu prahlen und damit der versuch das Gegenüber einzuschüchtern, insbesonders wenn diese 'mathematische Platitüde' nichts zur eigentlichen Problemlösung beiträgt.
HomukoVodeFa schrieb: > Eine Form dieser Täuschung ist, mit der Kenntnis eher grundlegender > mathematischer Begrifflichkeiten zu prahlen und damit der versuch das > Gegenüber einzuschüchtern, insbesonders wenn diese 'mathematische > Platitüde' nichts zur eigentlichen Problemlösung beiträgt. Ja stimmt, die 'Kunst der subtilen und geistreichen Beleidigung' (Anton Kuh) muss ich noch nen bißchen üben. Aber ich hab's probiert, es war ein Anfang. 'You'll be better next time baby' Cheers Detlef PS. : 'Plattitüde' muss es heißen, 'Platitüde' ist alte Rechtschreibung. PPS.: Rechtschreibung, Aussehen oder Sprache zu kritisieren ist zwar weder besonders geistreich noch subtil, wirkt aber oft erstaunlich gut.
:
Bearbeitet durch User
Detlef _. schrieb: > Ja stimmt, die 'Kunst der subtilen und geistreichen Beleidigung' (Anton > Kuh) muss ich noch nen bißchen üben. Na dann wird das aber ein beschwerlicher Weg hin zur erfolgreichen FPGA-Entwicklung. Weil, dazu braucht es messerscharfe Logik und realitätsgetreues Verständnis des Datenblattes. Da ist eine Erwartungshaltung wie "subtile Beleidigung" eher hinderlich. Und ein Synthesizer versteht auch nur was im Code hingeschrieben ist und nicht was der Coder eigentlich gemeint haben könnte ....
HomukoVodeFa schrieb: > Detlef _. schrieb: > Na dann wird das aber ein beschwerlicher Weg hin zur erfolgreichen > FPGA-Entwicklung. Da hast Du vermutlich Recht. > > Weil, dazu braucht es messerscharfe Logik und realitätsgetreues > Verständnis des Datenblattes. Da ist eine Erwartungshaltung wie "subtile > Beleidigung" eher hinderlich. Und ein Synthesizer versteht auch nur was > im Code hingeschrieben ist und nicht was der Coder eigentlich gemeint > haben könnte .... Verstehe ich nicht. Wie beleidigt man denn Synthesizer? Aber paßt ja wieder, meine Logik ist noch nicht scharf genug. Kommt vllt. noch Cheers Detlef
Detlef _. schrieb: > ich > glaube es gibt jeweils nur eine clock für eine bank, richtig ?! ) Nicht glauben, ins Datenblatt schauen! Oder ausprobieren. Das wäre mal ein Fall, wo man eine Post-implementation Simulation (auch VITAL-Simulation oder timing-simulation genannt) aufsetzt und sich im Simulator anschaut wie die unterschiedlichen Gatter und rout-laufzeiten sich auswirken. https://www.xilinx.com/support/answers/63988.html Sobald diese Simu steht (oder eine andere Möglichkeit das Design zu überprüfen) kann man sich an das Ausprobieren (neudeutsch: exploring design space) machen: Falls tatsächlich nur ein clock routing channel zu den IOB-FF einer Bank besteht, dann nimmt man eben ein FF aus der logic fabric und 'nagelt' das mit LOCATION-CONSTRAINT fest. Das signal wird dann im Ologic_block über D1 (Combinatorial Output Data) und nicht über D2 zum IOB-FF geführt (siehe Anhang (aus UG471)). In der UG471 S. 127 findet sich dann auch der Hinweis das die 'Pack io register into io pads bei map während des built-processes auf OFF zu setzen ist. Natürlich muss man dann die Phasenverschiebung des Taktes entsprechend anpassen.
HomukoVodeFa schrieb: > https://de.wikipedia.org/wiki/Gert_Postel Der Typ ist ja Spitze! Macht dauernd auf Arzt und wird nicht nachhaltig verurteilt, weil er mit den Staatsanwältinnen und Richterinnen was anfängt. Man möchte gar nicht wissen, wieviele Ärzte gar keine sind. Und man möchte auch nicht wissen, wieviele "Ingenieure" gar keine sind.
Liebe Freunde der programmierbaren Logik, mit angehängtem Code gelingt es mir, zwei Flanken für ein CMOD S7 ultrafein und reproduzierbar in ganzzahligen Vielfachen von 11ps (3.3 Lichtmillimeter) gegeneinander zu verschieben. Damit steuere ich eine LED an, die ultrakurze Lichtimpulse erzeugt. Das gelingt mit dem 'mixed mode clock manager', der hat sowas eingebaut. Das ganze wird zur 'runtime' über eine serielle Schnittstelle konfiguriert, die als statemachine im FPGA residiert. Wie gesagt bin ich FPGA newbie (naja, bisschen fortgeschritten vllt.) und über Kommentare und Anmerkungen zum Code freue ich mich. Cheers Detlef
Der Code allein reicht aber sicher nicht aus, um die FPGA-Logik entspechend zu erzeugen. Ich vermisse placement-Anweisungen. Darüber hinaus tue ich mich schwer, die theoretischen 11ps in der Hardware zu sehen, denn FPGA-Ausgänge neigen zum jittern, sie lassen sich durch Nachbarn beeinflussen und trotz hoher Dämpfung macht die Spannungsversorgung am Eingang ihren Einfluss und verschiebt das Signal im Pegal (und damit die Schaltschwelle). Wie wird das überhaupt gemessen, dass die LED reagiert?
Der Nick schrieb: > Der Code allein reicht aber sicher nicht aus, um die FPGA-Logik > entspechend zu erzeugen. Genau, was nachgereicht werden sollte, ist auch ein Nachweis, das der FPGA das tut was sollte. Also ein Test-ergebnis oder wenigstens eine timing (post Plae&Route) Simulation. Und der Trick scheint hier nicht die FSM zu sein, sondern die settings der PLL/Taktaufbereitung. Und da stolpere ich über Zeile 186
1 | CLKFBOUT_USE_FINE_PS => FALSE, |
PS bedeutet hier Phase - shift, was hier wohl offensichtlich in der 'feinen' Variante ausgeschaltet ist. Wie sollen da eine Genauigkeit von 11 picosekunden ermöglicht werden solange die PLL/MMCM nur im 'groben Modus' arbeitet?!
Der Nick schrieb: > Der Code allein reicht aber sicher nicht aus, um die FPGA-Logik > entspechend zu erzeugen. Ich vermisse placement-Anweisungen. Was ist denn das? >Darüber > hinaus tue ich mich schwer, die theoretischen 11ps in der Hardware zu > sehen, denn FPGA-Ausgänge neigen zum jittern, sie lassen sich durch > Nachbarn beeinflussen und trotz hoher Dämpfung macht die > Spannungsversorgung am Eingang ihren Einfluss und verschiebt das Signal > im Pegal (und damit die Schaltschwelle). Ja klar. was kann man tun? > Wie wird das überhaupt gemessen, dass die LED reagiert? Mit einer PMT photomultipliertube. Sobald das erste Photon da rauskommt wirds' gezählt. >>>>> CLKFBOUT_USE_FINE_PS => FALSE, Das ist die zweite Uhr. Ich dachte ich brauche zwei. Bei der benutzten ersten Uhr ist das true. >> timing (post Plae&Route) Simulation. Er macht bei dem placement eine Warnung, dass er die timings nicht einhält. Wie ich das ändern kann weiß ich nicht. Ich bastel aus einem 'mixed mode clock manager' zwei clocks, die gegeneinander fein verschoben sind. Die gehen durch einen BUFG (warum eigentlich, ist nur abgeschrieben?) Mit diesen beiden clocks bespaße ich Flipflops, deren Ausgänge ich direkt rausbringe. Das funktioniert super. Auf einem 2.5Gs/s scope kann ich keinen jitter sehen, 1 tick verschiebung sehe ich nicht, ab 10 oder so kann man was ahnen. Für meine Zwecke reicht das so erstmal. Cheers Detlef
Bitte 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.