Hallo! Gleich vorweg: Ich bin leider erst seit Kurzem in Kontakt mit FPGAs, deshalb kenne ich mich noch nicht gut mit der Bedienung und Anforderungen der Tools aus. Dennoch habe ich von Anfang an eine relativ komplizierte Aufgabe ausgefasst, über die ich schon seit Wochen brüte: Prizipiell muss ich für eine Frequenz von ca 330MHz einen PRNG programmieren, der 32Bit parallel aus dem FPGA ausgibt. Laut Simulation (im Quartus) und Timequest sollte der Chip die Frequenz definitiv schaffen und die Daten schaufeln können. Nach dem 32Bit-PRNG sitzt ein MUX, durch den die Daten weiter zu den Output Pins verfrachtet werden. Als ich das erste Mal die Simulation gestartet habe, ist mir aufgefallen, dass die Datenflanken vollkommen unsyncron sind. Nach längerem Suchen hab ich die Option gefunden, um die "Fast Output Registers" zu aktivieren. Dies hat etwa 28Bit meines Datenwortes syncronisiert, bis auf 4, die nicht bei der steigenden sondern bei der fallenden Flanke des CLK ausgegeben werden (also um 180° verschoben sind, also schätze ich, dass die Output Registers DDR-Typen sind). Kann ich die Delays vielleicht über das SDC-File ausbügeln? Oder kann ich irgendwie den CLK-Eingang des Fast Output Registers ändern (ich versteh noch immer nicht genau, wie man diesen einstellt)? Prinzipiell ist die Frequenz, mit der das Signal generiert wird, nicht konstant (0-300MHz). Deshalb habe ich bedenken, Delays per SDC zu ändern. Was meit ihr? Ich habe ebenfalls versucht, die Daten per SDC-File ohne Output Registers zu syncronisieren: set_output_delay -add_delay -max -clock [get_clocks {parallel_clk}] 2.750 [get_ports {Parallel_data_out*}] set_output_delay -add_delay -min -clock [get_clocks {parallel_clk}] 0.250 [get_ports {Parallel_data_out*}] Dies schafft etwa denselben Effekt wie mit den Fast output Registern, wobei ich jedoch bei allen 32 Leitungen Setup Slack Violations habe (obwohl laut Chip-Planner genau die LUTs neben den Pins verwendet werden -> wieso gibt es da fast 3ns Delay?). Diese Slack Violatons belaufen sich bei fast allen auf -6.8ns (Required Time = .25ns; Clk Delay = 2.5ns, Data Delay = 4.535ns; Wie kommt Quartus auf so wahnsinnig große Delay-werte, wenn Pin und LUT direkt nebeneinander liegen?!). Ich bin echt mit meinem Latein am Ende. Könnt ihr mir vielleicht weiterhelfen? LG Johannes
>Nach dem 32Bit-PRNG sitzt ein MUX, durch den die Daten weiter zu den Output >Pins
verfrachtet werden.
Output-Register können nur dann implementiert werden, wenn hinter der
letzten Registerstufe keine kombinatorische Logik folgt. In deinem Fall
hast du aber einen (kombinatorischen) Mux, dessen Ausgang auf die
Ausgangspads geroutet wird. Abhilfe könnte eine Registerstufe hinter dem
Mux schaffen.
Gruß,
SuperWilly
Ich sehe gerade, dass der Mux getaktet ist. Aber nichtsdestotrotz kann du das Experiment mal wagen und am Mux-Ausgang noch eine Registerstufe spendieren. Gruß, SuperWilly
Danke für deine Antwort! An sich ist der Mux selber in VHDL als Process geschrieben. Insofern sollte schon Flipflops folgen... Jedenfalls zeigt der Resource Property Editor schon an, dass das Output-Fifo im Einsatz ist... LG
Dafür, dass Du erst seit kurzem mit FPGA zu tun hast, hast Du eine hübsch komplexe Aufgabenstellung. Und auch schon einige gute Ansätze, Respekt! Trotzdem: Die Signale sind nicht unsyncron. Sie haben nur unterschiedlich lange Verzögerungszeiten vom Takt zum Ausgang. Den Unterschied kann man minimieren, entweder durch konstruktive Maßnahmen wie die Nutzung von Registern in den IO-Zellen oder durch Vorgaben an das zeitliche Verhalten in der SDC-Datei. Beides hast Du bereits versucht, mit teilweisem Erfolg. Jetzt muss man noch herausfinden, warum der Erfolg nur teilweise ist. Ich würde zuerst mal an den vier falschen Bits ansetzen. Ich kann mir nicht vorstellen, dass Quartus da aus Versehen die falsche Flanke verwendet. Eher wahrscheinlich ist, dass die Verzögerungszeit bei diesen vier Bits aus irgendwelchen Gründen größer als eine halbe Taktperiode ist. Da solltest Du mal genau nachschauen. Zu guter Letzt: Ich hege Zweifel, ob das Design in der Realität funkionieren wird. Ich habe das jetzt gerade nicht greifbar, aber ich schätze, dass "normale" I/O Pins bei 330 MHz nicht mehr richtig tun. Das ist dann doch etwas fix. Oder hast Du einen anderen IO-Standard eingestellt, z.B. LVDS?
Hey hallo! Danke für die weitere Rückmeldung... Prizipiell ist der Port mit den 330MHz serienterminiert. Ich habe mit Hyperlinx die Leitungen simuliert - es sollte passen. Aber ich habe soeben herausgefunden, warum diese Pins mehr Delay aufweisen: Alle diese haben als zweite Funktion VREFBxN0 -> anscheinend weist die interne Schaltung der IOs ein größeres Delay auf. Das einfachste wird wohl sein, die Pins am Layout zu ändern - gerne mache ich es nicht, da das Layout an sich schon fertig ist, aber es ist wohl die einfachste Varinte... Vielen Dank und liebe Grüße Johannes
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.