DDR-Input in Spartan 3 nutzen

[Christian H. (cavorca)]

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

[Christian R. (supachris)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Bzw. die maximal Mögliche Frequenz wird zu klein.
Wie schnell willst du das externe Signal eigentlich abtasten?

[Christian H. (cavorca)]

@ 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.

entity DDR_CL is
    Port ( CLK : in  STD_LOGIC;
           CLK180 : in  STD_LOGIC;
           Signal_IN : in  STD_LOGIC;
           Clip1 : out  STD_LOGIC;
           Clip2 : out  STD_LOGIC);
end DDR_CL;

architecture Behavioral of DDR_CL is
  
  signal Q0,Q1,old_G1,F0,F1,G0,G1: STD_LOGIC;


begin
   IFDDRRSE_inst : IFDDRRSE
   port map (
      Q0 => Q0,    -- Posedge data output
      Q1 => Q1,    -- Negedge data output
      C0 => CLK,    -- 0 degree clock input
      C1 => not CLK,    -- 180 degree clock input
      CE => '1',    -- Clock enable input
      D => Signal_IN,      -- Data input (connect directly to top-level port)
      R => '0',      -- Synchronous reset input
      S => '0'       -- Synchronous preset input
   );


  process (CLK) is
  
  begin
    if falling_edge(CLK) then
      F1<=Q1;
    end if;
  
    if rising_edge(CLK) then
      F0<=Q0;
      G1<=F1;
      G0<=F0;
      
      if (G0='1' AND  old_G1='0') then
        Clip1<='1';
      else
        Clip1<='0';
      end if;
      
      if ( G0='0' AND G1='1') then
        Clip2<='1';
      else
        Clip2<='0';
      end if;
  
      old_G1<=G1;
    end if;
  end process;

end Behavioral;

mal sehen ob ich noch ein paar FFs "rauskürzen" kann und die Latenz 
reduziert bekomme.

Viele Grüße,
Christian

[Christian R. (supachris)]

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 H. (cavorca)]

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.

[Christian H. (cavorca)]

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:

TS_Inst_dcm180_CLK0_BUF = PERIOD TIMEGRP  
"Inst_dcm180_CLK0_BUF" TS_CLK HIGH   50%  

TS_CLK = PERIOD TIMEGRP "CLK_IN" 200 MHz 
HIGH 50%  

TS_Inst_dcm180_CLK180_BUF = PERIOD TIMEGR
P "Inst_dcm180_CLK180_BUF" TS_CLK   
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

[Christian R. (supachris)]

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 H. (cavorca)]

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?):

Clock to Setup on destination clock CLK_IN
---------------+---------+---------+---------+---------+
               | Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock   |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
CLK_IN         |    3.665|         |         |         |
---------------+---------+---------+---------+---------+
Timing summary:
---------------
Timing errors: 0  Score: 0
Constraints cover 6 paths, 0 nets, and 18 connections
Design statistics:
   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

[Christian R. (supachris)]

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....

[Bader (Gast)]

Die 200 MHz kann man aber ganz konventionell mit Doppelabtastung 
erreichen und 100 Mzh kriegt man mit einem Spartandesign jederzeit hin.

[Christian H. (cavorca)]

@ 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.

[Michael (Gast)]

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

[Christian H. (cavorca)]

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?

[Michael (Gast)]

> 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