Hallo, Ich möchte ein digitales Signal zeitlich möglichst genau abtasten. Dazu habe ich vor ein DDR-FF am Eingang eines Sparten 3 zu verwenden. (Eigentlich soll es ein möglichst genauer Pulse-Clipper werden.) Leider ist es ein Spartan 3 und nicht 3A oder 3E. Im Gegensatz zu diesen beiden ist es bei den DDR FFs im Spartan 3 immer der Ausgang zu Takt 1 zu Takt 1 synchron, der Ausgang zu Takt 2 immer zu Takt 2. (im S3A und S3E kann man die DDR-FFs so einstellen dass beide Ausgänge zu nur einem Takt synchron sind). Meine Frage ist jetzt: Wie kann ich beide Signale auf einen Takt sychnronisieren? Einfach so beide Signale mit dem gleichen Takt verarbeiten funktioniert nicht. Bzw. die maximal Mögliche Frequenz wird zu klein. Eine Lösung habe ich gefunden: http://www.xilinx.com/support/documentation/application_notes/xapp692.pdf (Seite 4) Nur ist an dieser Lösung nicht schön, dass durch die vielen FFs hintereinander viel Latenz entsteht. Gibt es vielleicht eine bessere Lösung? Viele Grüße, Christian
Hm...steht nicht im Datenblatt des Spartan 3, dass diese Align-Funkion eh wieder aus den Design-Tools genommen wurde? Es geht beim Spartan meines Wissens nur über ein 2. FlipFlop, allerdings muss dann eben die Setup-Zeit ausreichend sein. Was anderes macht das Aligning ja auch nicht, da hättest du das gleiche Problem. Schau dir im User Guide mal das Kapitel zu den IDDR2 an.
> Bzw. die maximal Mögliche Frequenz wird zu klein.
Wie schnell willst du das externe Signal eigentlich abtasten?
@ Christian R.: Im Datenblatt vom S3E von April 2008 ist die aligning Funktion noch drin. In ISE 9.2i steht sie auch zur Verfügung, wenn man sich die Templates ansieht. Das Kapitel über den IDDR2 kenne ich grob. Ich hätte nur vermutet, dass das Aligning nicht über normale FFs im FPGA gemacht wird, sondern ein FF ist, das im IOB mit eingebaut ist. Ich kenne mich mit chipdesign nicht wirklich aus, aber ich vermute mal, dass vom Timing her mehr zu erreichen ist, wenn man ein für diese Aufgabe dezidiertes FF einsetzt. @ Lothar: 200MHz ist das Ziel. 150MHz wären noch akzeptabel. Falls mehr geht, dann so viel wie geht. Aber ich denke auch schon bei 200MHz stoße ich deutlich an die Grenzen meiner Fähigkeiten, schnelle Designs zu basteln. Dieser Clipper läuft auf Speedgrade 4 laut implement mit 258MHz.
1 | entity DDR_CL is |
2 | Port ( CLK : in STD_LOGIC; |
3 | CLK180 : in STD_LOGIC; |
4 | Signal_IN : in STD_LOGIC; |
5 | Clip1 : out STD_LOGIC; |
6 | Clip2 : out STD_LOGIC); |
7 | end DDR_CL; |
8 | |
9 | architecture Behavioral of DDR_CL is |
10 | |
11 | signal Q0,Q1,old_G1,F0,F1,G0,G1: STD_LOGIC; |
12 | |
13 | |
14 | begin
|
15 | IFDDRRSE_inst : IFDDRRSE |
16 | port map ( |
17 | Q0 => Q0, -- Posedge data output |
18 | Q1 => Q1, -- Negedge data output |
19 | C0 => CLK, -- 0 degree clock input |
20 | C1 => not CLK, -- 180 degree clock input |
21 | CE => '1', -- Clock enable input |
22 | D => Signal_IN, -- Data input (connect directly to top-level port) |
23 | R => '0', -- Synchronous reset input |
24 | S => '0' -- Synchronous preset input |
25 | );
|
26 | |
27 | |
28 | process (CLK) is |
29 | |
30 | begin
|
31 | if falling_edge(CLK) then |
32 | F1<=Q1; |
33 | end if; |
34 | |
35 | if rising_edge(CLK) then |
36 | F0<=Q0; |
37 | G1<=F1; |
38 | G0<=F0; |
39 | |
40 | if (G0='1' AND old_G1='0') then |
41 | Clip1<='1'; |
42 | else
|
43 | Clip1<='0'; |
44 | end if; |
45 | |
46 | if ( G0='0' AND G1='1') then |
47 | Clip2<='1'; |
48 | else
|
49 | Clip2<='0'; |
50 | end if; |
51 | |
52 | old_G1<=G1; |
53 | end if; |
54 | end process; |
55 | |
56 | end Behavioral; |
mal sehen ob ich noch ein paar FFs "rauskürzen" kann und die Latenz reduziert bekomme. Viele Grüße, Christian
Hm, stimmt, bezieht sich wohl nur auf die ODDR2 des Spartan 3e. Hab nochmal nachgelesen. Ich wollte das nämlich auch mal nutzen, aber das ging dann nicht. 200MHz sollte eigentlich drin sein, ich meine mal was von 311MHz Maximum gelesen zu haben, da gibts doch diese Appnote, die 622MBit/s zum Spartan 3 überträgt, aber da steht auch dabei, dass es ganz schön haarig wird, und nur mit viel Optimierung zu schaffen ist. Gibts beim Spartan 3 nicht die IDDR2? Oder sind das die gleichen wie IFDDRRSE? Intern solltest du nur mit einer Flanke arbeiten. Außerdem arbeiten die IOB-FF schneller, wenn sie vom DCM getaktet werden, erst recht die DDR-IOB. Probier das mal aus.
Christian R. schrieb: > Hm, stimmt, bezieht sich wohl nur auf die ODDR2 des Spartan 3e. Hab Habe ich auch grade festgestellt. > Gibts beim Spartan 3 nicht die IDDR2? Oder sind das die gleichen wie Nein, IDDR gibts nur bei 3E und 3A. Das sind die die aligning machen können. Die IFDDRRSE aus dem S3 können es nicht. > IFDDRRSE? Intern solltest du nur mit einer Flanke arbeiten. Außerdem Meinst du das falling_edge(CLK) das ich verwendet habe? Ich wollte damit beschreiben was in dem PDF vom Anfang steht. Ich dachte der macht daraus einen Inverter und ein normales FF. > arbeiten die IOB-FF schneller, wenn sie vom DCM getaktet werden, erst > recht die DDR-IOB. Probier das mal aus. OK.
So, Ich habe jetzt das Design geändert. Weniger FFs und ein DCM ist jetzt drin. Nur traue ich der Timinganalyse nicht. Zuerst, als ich ein constraint eingestellt hatte, dass der Eingangstakt 200MHz sein soll (vom DCM nutze ich nur CLK0 und CLK180), war das Ergebnis, dass ich sogar 311MHz Eingangstakt verwenden könnte. Also wären sogar die 622MBits schon erreicht. Im Timingreport steht folgendes:
1 | TS_Inst_dcm180_CLK0_BUF = PERIOD TIMEGRP |
2 | "Inst_dcm180_CLK0_BUF" TS_CLK HIGH 50% |
3 | |
4 | TS_CLK = PERIOD TIMEGRP "CLK_IN" 200 MHz |
5 | HIGH 50% |
6 | |
7 | TS_Inst_dcm180_CLK180_BUF = PERIOD TIMEGR |
8 | P "Inst_dcm180_CLK180_BUF" TS_CLK |
9 | PHASE 2.5 ns HIGH 50% |
Die unteren beiden Constraints würde ich als die automatisch generierten identifizieren. Da steht bei allen Eigenschaften N/A. Ist das korrekt? Mir ist das etwas suspekt. (Nebenbei: 311MHz kann der DCM im Eingang nicht mal verarbeiten) Um das anders zu Prüfen habe ich das Constraint auf 100MHz runter gesetzt und die CLK2X und CLK2X180 Ausgänge verwendet, in der Hoffnung jetzt eine Angabe wie 155MHz zu bekommen. Laut Analyse kann ich jetzt angeblich bis 270MHz gehen. Da die noch *2 genommen werden würde ich mal sagen ich bediene hier irgendwas falsch. Aber was? Viele Grüße, Christian
Naja, das stimmt schon, was der generiert hat. Und 311 MHz ist maximale Arbeitsfrequenz. Wenn sonst nix im FPGA ist, kann das schon hinkommen. Dass der DCM keine 300MHz am Eingang verkraftet macht ja nix, die kannst du ja auch aus dem 100Mhz erzeugen. Wenn du den Takt-Eingang direkt auf den DCM gibst, errechnet er die maximale Taktfrequenz des Designs, das heißt Ausgangstakt des DCM. Wo kommt das raus? Nach der PAR? Oder schon bei der Sythese?
Christian R. schrieb: > Naja, das stimmt schon, was der generiert hat. Und 311 MHz ist maximale > Arbeitsfrequenz. Wenn sonst nix im FPGA ist, kann das schon hinkommen. > Dass der DCM keine 300MHz am Eingang verkraftet macht ja nix, die kannst > du ja auch aus dem 100Mhz erzeugen. OK, aber das ist ja nicht eingestellt. Aber möglich, dass das bei der Timinganalyse einfach nicht geprüft wird. > Wenn du den Takt-Eingang direkt auf > den DCM gibst, errechnet er die maximale Taktfrequenz des Designs, das > heißt Ausgangstakt des DCM. Ah, Ok. Ich dachte es wird immer der Maximale Takt ausgerechnet, der auf den DCM gegeben werden kann. Dann finde ich es aber immer noch eigenartig, dass das Design bis 311MHz läuft, wenn man an CLK0 und CLK180 geht. Allerdings nur bis 270 wenn man an CLK2X und CLK2X180 geht. Sonst habe ich nichts geändert. > Wo kommt das raus? Nach der PAR? Oder schon > bei der Sythese? Wenn mich nicht alles täuscht nach PAR. Ich habe mir angewöhnt den Wert nach der Synthese zu ignorieren, sofern er nicht <100MHz ist. Habe eben nochmal nachgeguckt: Synthese sagt für CLK_IN (der Takt der auf den DCM geht) max 130MHz. Im Static Timing Report Steht folgendes (Das ist doch der nach P&R, oder?):
1 | Clock to Setup on destination clock CLK_IN |
2 | ---------------+---------+---------+---------+---------+ |
3 | | Src:Rise| Src:Fall| Src:Rise| Src:Fall| |
4 | Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall| |
5 | ---------------+---------+---------+---------+---------+ |
6 | CLK_IN | 3.665| | | | |
7 | ---------------+---------+---------+---------+---------+ |
8 | Timing summary: |
9 | --------------- |
10 | Timing errors: 0 Score: 0 |
11 | Constraints cover 6 paths, 0 nets, and 18 connections |
12 | Design statistics: |
13 | Minimum period: 3.665ns (Maximum frequency: 272.851MHz) |
Das würde ich so interpretieren als ob es um den Eingangstakt geht. Oder was übersehe ich? Viele Grüße, Christian
Sollte so sein, ja. Aber so der Crack bin ich da auch nicht. Wollt schon immer mal den Timing Constraint Kurs bei PLC2 machen. Irgendwann....
Die 200 MHz kann man aber ganz konventionell mit Doppelabtastung erreichen und 100 Mzh kriegt man mit einem Spartandesign jederzeit hin.
@ Christian R.: Die PLC2 kannte ich noch gar nicht. Klingt interessant. @Bader: Ich will aber zu 400MHz Abtastrate. Klar ist auch zu schaffen. Allerdings habe ich es schon oft genug hin bekommen, dass ich so lange an einem Design rum gedoktort habe dass es nicht mal mehr mit 100MHz lief. Ich will mich nachher auf die Timinganalyse verlassen können. Wenn die aber jetzt schon Sachen macht, die ich nicht verstehe kann ich das nicht. Kann man eigentlich den Temperaturbereich einschränken? Mich würde interessieren wie viel da noch raus zu holen ist.
Du kannst zwar die DDR-Eingänge bei den Spartan 3 A/E-Serien auf einem Takt laufen lassen (einfach ein Inverter am FF-Eingang) aber das kann ich dir nicht empfehlen. Das funktioniert solange, wie dein Takt ein Tastverhältnis von 50% hat. Sollten sich die Anstiegs- und Abfallzeiten des einzelnen Clocksignals sowie die Ansprechschwellen (mit Hysterese) über den Temperaturbereich ändern, wandern die Abtastzeitpunkte für rising- und falling edge auseinander. Besser (und meiner Meinung nach von Xilinx empfohlen) ist die Verwendung von zwei Taktsignalen selber Frequenz mit 180° Phasenverschiebung. Ich benötige das für ein aktuelles Projekt (FPGA RAM -> DAC) mit > 400MHz Abtastrate. Die RAM-Zellen im Spartan3AN können nur 285MHz mitmachen, daher arbeite ich mit 2x200MHz und lese ein Dual-Ported RAM mit den beiden Takten aus. Habe ich bis knapp 250MHz (-> 500MHz in Summe) erfolgreich auf dem 700AN Evakit getestet. Brauchst aber ein gutes Scope um da noch etwas zu sehen :). Gruß Michael
Michael schrieb: > Du kannst zwar die DDR-Eingänge bei den Spartan 3 A/E-Serien auf einem > Takt laufen lassen (einfach ein Inverter am FF-Eingang) aber das kann > ich dir nicht empfehlen. D Werde ich tun. Ist ja kein ding. Resourcen sind ja da. > Habe ich bis knapp 250MHz (-> 500MHz in Summe) erfolgreich auf dem 700AN Nicht schlecht! ich wäre ja schon mit 2x200 zufrieden. > Evakit getestet. Brauchst aber ein gutes Scope um da noch etwas zu sehen > :). Gute Scopes stehen mir zur Verfügung. Was sagt die Timinganalyse bei dir? Diese knapp 250MHz oder sind die ein Erfahrungswert?
> Was sagt die Timinganalyse bei dir? Diese knapp 250MHz oder sind die ein > Erfahrungswert? Nö, Messung mit 'nem MSO4104 - das hat 1GHz Analogbandbreite (5GS/s) bzw. 62,5ps Zeitauflösung im MagniView Modus mit den Digitaleingängen. Allerdings ist das nur ein Test gewesen, ich denke im fertigen Gerät werde ich irgenwo unterhalb bleiben. Gruß Michael
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.