Forum: FPGA, VHDL & Co. Output Bus bei Altera Cyclone III nicht syncron


von Johannes (Gast)


Angehängte Dateien:

Lesenswert?

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

von SuperWilly (Gast)


Lesenswert?

>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

von SuperWilly (Gast)


Lesenswert?

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

von Johannes (Gast)


Lesenswert?

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

von Harald F. (hfl)


Lesenswert?

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?

von Johannes (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.