www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Timing Probleme DDR- SDR Wandler: Wie lautet die Timing-Constraint-Anweisung


Autor: Simon D. (simon86)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich muss für meine Master Thesis Daten von einem Ti ADC (ADS62P49) mit 
250 MSPS in den FIFO eines Xilinx Virtex FPGAs laden.

Da die Daten des ADCs im DDR Format kommen (bei positiver Flanke werden 
die geraden Bits übertragen und bei negativer die ungeraden) und der 
FIFO die Daten nur bei positiver Flanke speichert, habe ich ein Modul 
geschrieben, das die Daten vom DDR ins SDR, synchron mit dem 
ADC-DDR-Clock, Format umwandelt -> es werden die ungeraden und geraden 
Bits entsprechend zusammengesetzt und dann an den FIFO übergeben (mit 
einem extra Clock Signal).

Das ganze funktioniert auch bei geringen ADC-Taktfrequenzen... bei 250 
MHz jedoch geschehen Abtastungsfehler die auf das DDR-SDR Interface 
zurückzuführen sind.

Ich habe bisher keine Timing Constraints gesetzt, außer 
CLOCK_DEDICATED_ROUTE = FALSE für das Einlesen des ADC-DDR-Taktes - was 
sicherlich nicht gut ist, aber vom ISE gefordert wurde...

Um diese Timing-Probleme zu lösen muss ich ja Timing-Constraints 
setzen...

Ich habe auch im "Xilinx Timing Constraints User Guide" Seite 12 (Source 
Synchronous Inputs) bereits das richtige Beispiel gefunden aber wenn ich 
dieses in mein ucf File übernehme gibt es immer Fehlermeldungen... 
(keine Timing Fehlermeldung - sondern Syntax)...

Mein Vorschlag für das Timing-Constraint-File entsprechend der 
beigefügten Zeichung wäre:
NET "CLK" TNM_NET = "CLK";
TIMESPEC "TS_CLK" = PERIOD "CLK" 4 ns HIGH 50%;
OFFSET = IN 1 ns VALID 2 ns BEFORE "CLK" RISING;
OFFSET = IN 1 ns VALID 2 ns BEFORE "CLK" FALLING; 

Ich habe diese Textzeilen in das UCF File eingefügt -es kommt immer ein 
Error weil angeblich ein ; fehlt oder ähnliches...

Meine Fragen:

1) Stimmt die Aussage: Im Timing-Constraint File werden nur Leitungen 
nach dem Input-Buffer definiert und nicht davor.

2) Ist mein Timing-Constraint richtig für das, was ich vorhabe - warum 
kommt dann eine Fehlermeldung?

3) Kann man die Timing-Constraints in das normale handgeschriebene ucf 
File packen?

4) Ist das CLOCK_DEDICATED_ROUTE = FALSE nach Einfügen der Timing 
Constraints noch nötig?

5) Ich habe das DDR-SDR Modul so wie folgt programmiert:

module DDR_to_SDR_Interface(DDR_Data_In, Clock_In, SDR_Data_Out, Clock_Out);
  input[6:0]      DDR_Data_In;      // dual data rate data input
  input         Clock_In;        // dual data rate clock input  
  output reg[13:0]  SDR_Data_Out;      // single data rate data output  
  output         Clock_Out;        // clock output for further synchronous circuits

  integer       i;                // for indexing
  reg[13:0]    SDR_Data_Out_Buffer;    // output buffer for synchronization
  
  always@(posedge Clock_In)          // read the even bits and set them to the output buffer
  begin
    for(i = 0; i <= 6; i = i + 1)
    begin
      SDR_Data_Out_Buffer[i * 2]  <= DDR_Data_In[i];
    end
    SDR_Data_Out = SDR_Data_Out_Buffer;  // set output with signal of output buffer
  end
  
  always@(negedge Clock_In)          // read the odd bits and set them to the output buffer
  begin
    for(i = 0; i <= 6; i = i + 1)
    begin
      SDR_Data_Out_Buffer[i * 2 + 1] <= DDR_Data_In[i];
    end      
  end
  
  assign Clock_Out = !Clock_In;        // output clock
endmodule


gibt es Verbesserungsvorschläge was das Timing betrifft? Müssen auch die 
Signale innerhalb dieses Moduls über Timing-Constraint spezifiziert 
werden?


Vielen Dank für die Antwort im Voraus!

(Bei den Leuten, die sich richtig gut auskennen und nur "Gast" sind 
würde ich mich freuen, wenn diese mir ihre Mail Adresse zusenden könnten 
für weitergehende Diskussionen)

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon D. schrieb:
> 250 MHz
...
> Ich habe bisher keine Timing Constraints

Mutig, mutig...

Was hast Du denn für einen Virtex?

Mindestens ab Virtex 4 gibt es IDDR. Die Dokumentation dazu 
(virtex4_hdl.pdf) ist m.E. gar nicht so schlecht.

Ich glaube nicht, das XST schon soweit ist, aus Deiner Beschreibung 
einen IDDR zu generieren. (Oder sagt der Synthesereport was anderes 
dazu?)

Duke

P.S.:
> ihre Mail Adresse zusenden könnten für weitergehende Diskussionen
Diskutiert wird im Forum, da haben alle was davon.

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Was hast Du denn für einen Virtex?

ich habe einen XC4VLX25 - Speedgrade ist nicht auf dem FPGA aufgedruckt 
(sollte ja nach der Nummer folgen), deshalb nehme ich den niedrigsten 
an.

Duke Scarring schrieb:
> Mindestens ab Virtex 4 gibt es IDDR.

das hört sich schonmal sehr gut an... ich werde am montag an dem design 
weiterarbeiten und versuchen ein solches modul einzubinden...

hast du noch einen tipp wegen dem timing constraint?

Simon

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IDDR muss instanziiert werden, es wird nicht inferriert. Und die Timing 
Contraints kann man auch über PlanAhead generieren lassen, da gibts 
sogar eine GUI dafür.

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> die Timing
> Contraints kann man auch über PlanAhead generieren lassen

das weiß ich. Ich habe mein ucf File aber selber geschrieben und würde 
deswegen auch ungern mit dem PlanAhead weiter machen, da es da immer 
Kompliaktionen gibt...

Desewegen auch meine noch unbeantwortete Fragen 1 - 4 (siehe oben)

Werde morgen mal versuchen einen IDDR einzubinden und euch dann 
berichten ob es funktioniert hat...

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die IDDR gefunden, habe aber leider Probleme beim Einbinden, da 
sich diese Teile nicht mit isim simulieren lassen - bzw. die Simulation 
zeigt null Ausgangssignaländerungen an.... weshalb weiß ich auch nicht 
... werde in den nächsten Tagen weiter ausprobieren.

die Fragen 1 - 3 kann ich nun selbst beanworten:

Timing Constraint Anweisungen kommen alle ins ucf File.

Definition des Eingangstaktes:
NET "CLK_P" TNM_NET = CLK_P;
TIMESPEC TS_CLK_P = PERIOD "CLK_P" 250 MHz HIGH 50%;

NET "CLK_N" TNM_NET = CLK_N;
TIMESPEC TS_CLK_N = PERIOD "CLK_N" 250 MHz HIGH 50%;

# Gruppieren von Netzen
INST "Data0_P"   TNM = ADC;
INST "Data0_N"   TNM = ADC;
INST "Data1_P"   TNM = ADC;
INST "Data1_N"   TNM = ADC;
# Definition der DDR-Zeitdaten der voher gruppierten Netze
TIMEGRP "ADC" OFFSET = IN 1 ns VALID 2 ns BEFORE "CLK_P" RISING;
TIMEGRP "ADC" OFFSET = IN 1 ns VALID 2 ns BEFORE "CLK_P" FALLING;


Eine noch ungeklärte Frage ist:

Der DDR-Takt mit 250 MHz wird auf einen xxx_CC_LC Pin gegeben - also ein 
Pin mit extra geringer Kapazität und Anbindung zu einem Clock Netzwerk. 
Warum aber verlangt dann ISE, dass "CLOCK_DEDICATED_ROUTE = FALSE" in 
das Constraint File aufgenommen werden soll?? Es sollte doch ohne 
Probleme möglich sein, diesen Takt auf eine Clock Netzwerk zu geben?? 
Ich habe auch eine entsprechendes Timing Anweisung geschrieben, aber 
ohne "CLOCK_DEDICATED_ROUTE = FALSE" läuft nichts....

Kennt sich damit jemand aus?? Tipps??

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die _LC Pins erreichen nur bestimmte Bereiche des FPGA über die 
CLK-Netzwerke. Wahrscheinlich liegen die IDDR nicht im gleichen Bereich 
wie der CLK Eingang. Die GCLK Eingänge kommen überall hin.
Du kannst auch einen DCM direkt hinter den CLK Eingang setzen und dessen 
Ausgangssignale für die restliche Logik. Das ist meist besser und 
schneller. Die Ausgänge des DCM wiederum können dann auf die internen 
Clock Lanes aufgeschaltet werden.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist es einfacher auf einen Virtex 5 zu setzen. Die gibt es so 
zwischen 200€ und 300€ ich denke mal der Virtex4 ist da auch nicht viel 
günstiger.

Der Virtex 5 hat dann IDDR Register. Damit geht das dann wie von allein.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Virtex4 hat genauso IDDR, ebenso die Spartan 3e usw. also das ist ja 
keine Hexerei. 250MHz sollten mit dem V4 locker gehen, die IOs gehen bis 
etwa 1Gb/s laut Datenblatt.
Allerdings würde ich, wenn´s nicht auf den Euro ankommt, auch den V5 
nehmen. Hat u.A. den Vorteil, dass er von SPI/BPI Flash booten kann, 
lässt sich leicht im Design updaten.

Autor: Simon D. (simon86)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Der Virtex4 hat genauso IDDR, ebenso die Spartan 3e usw. also das ist ja
> keine Hexerei.

ja, kann ich nur bestätigen. Außerdem MUSS ich den Virtex 4 FPGA nutzen.

Ich habe nun ein neues Projekt angelegt, indem ich nur das 
DDR-SDR-Interface testen möchte. In diesem Projekt habe ich die IDDRs 
implementiert und zusätzlich die ADC-FPGA-Eingänge mit Timing 
Constraints versehen.


ISE hat mir nun auch erlaubt, das "CLOCK_DEDICATED_ROUTE = FALSE" des 
ADC-FPGA-Clock-Eingangs wegzulassen.

Ich bekomme nun 4 Timing Constraints Errors, derren Bedeutung ich jedoch 
nicht so richtig verstehe.

Meine Fragen (--> siehe Bild):

1. Best Case Achievable -> also der beste zu erreichende Fall von der 
Zeit - warum negative Zeiten??

2. Worst Case Slack -> was bedeutet das auf deutsch - schlechteste Zeit? 
Und warum gibt es hier zwei Zeiten?? Was bedeutet das Hold und das 
Setup?? (Hold für die Daten zu halten und Setup für die Daten 
aufzubauen)??

3. Was bedeutet Timing Score?

4. gibt es irgendwo noch mehr Details zu den Zeiten?

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Simon!

Da ich vor kurzer Zeit ein 250 MHz DDR Interface AD-Wandler -> Virtex5 
implementiert habe, kann ich dir ein paar dezente Hinweise geben:

1. Wenn mich nicht alles täuscht, dann sind die IDDR Primitives nur bis 
200 MHz spezifiziert ... Schau dir lieber mal die ISERDES module an.

2. Bei 500 MHz Datenrate (250MHz DDR) ist das timing nicht mehr ganz so 
einfach. Das PCB Layout sollte also direkt die entsprechneden 
Taktressourcen (Lokale Taktnetze e.g.) berücksichtigen. Also wenn du 
CLOCK_DEDICATED_ROUTE auf TRUE setzen musst, dann läuft so einiges 
schief.

3. Eventuell musst du dein Timing dynamisch einstellen. Wenn du Glück 
hast gehts aber auch gerade noch so. Schau dir dazu mal die IDELAY 
Primitives an

Sorry habe gerade keine Zeit das ausführlicher zu beschreiben.

Viele Grüße!

Cpt

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cpt schrieb:
> IDDR Primitives nur bis
> 200 MHz spezifiziert ...

ich habe keine Spezifizierung in den Datenblätter gefunden - es kann 
aber gut sein...

Cpt schrieb:
> Also wenn du
> CLOCK_DEDICATED_ROUTE auf TRUE setzen musst, dann läuft so einiges
> schief.

habe ich ja jetzt hinbekommen, dass es nicht mehr nötig ist - das PCB 
funktioniert mit der zugehörigen TI Konfiguration -> es ist also möglich 
einen AD Wandler mit 250 MSPS mit einem Virtex 4 zu betreiben -> ich 
habe das Evaluation Board TSW1200 und das zugehörige ADC Board 
ADS62P49EVM...

Cpt schrieb:
> Sorry habe gerade keine Zeit das ausführlicher zu beschreiben.

hast du jedes Bit einzeln mit einem ISERDES Modul abgetastet und dann 
zum Beispiel anstatt im FPGA Design mit 250 MHz 14 Bit zu transportieren 
mit 125 MHZ 28 Bit oder 62,5 MHz 56 Bit??? Oder benutzt du es wirklich 
nur als Empfangsmodul und erhältst danach deinen 14 Bit Bus mit 250 
MHz....???


Meine Fragen zur Bedeutung der Timing Constraint Meldung ist aber immer 
noch nicht beantworet:

1. Best Case Achievable -> also der beste zu erreichende Fall von der
Zeit - warum negative Zeiten??

2. Worst Case Slack -> was bedeutet das auf deutsch - schlechteste Zeit?
Und warum gibt es hier zwei Zeiten?? Was bedeutet das Hold und das
Setup?? (Hold für die Daten zu halten und Setup für die Daten
aufzubauen)??

3. Was bedeutet Timing Score?

4. gibt es irgendwo noch mehr Details zu den Zeiten?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon D. schrieb:

> 1. Best Case Achievable -> also der beste zu erreichende Fall von der
> Zeit - warum negative Zeiten??

Negativ bedeutet, die Daten haben weniger als gar keine Zeit mehr, 
stabil vor der Flanke anzuliegen (Setup) bzw. sind schneller wieder weg, 
als die nachfolgende Stufe braucht, sie zu übernehmen (Hold).

> 2. Worst Case Slack -> was bedeutet das auf deutsch - schlechteste Zeit?
> Und warum gibt es hier zwei Zeiten?? Was bedeutet das Hold und das
> Setup?? (Hold für die Daten zu halten und Setup für die Daten
> aufzubauen)??

So in etwa. Negativ wieder so wie oben.

> 3. Was bedeutet Timing Score?

Je höher der Wert, desto länger/öfter hat der Router versucht, das 
Timing zurecht zu zerren.

> 4. gibt es irgendwo noch mehr Details zu den Zeiten?

Klick doch mal auf die Constraints da in dem Report...

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
>> 3. Was bedeutet Timing Score?
> Je höher der Wert, desto länger/öfter hat der Router versucht, das
> Timing zurecht zu zerren.

M.E. ist das die Summe der timing-Verletzungen in Picosekunden.

Duke

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon D. schrieb:
> 2. Worst Case Slack -> was bedeutet das auf deutsch - schlechteste Zeit?
> Und warum gibt es hier zwei Zeiten?? Was bedeutet das Hold und das
> Setup?? (Hold für die Daten zu halten und Setup für die Daten
> aufzubauen)??

eine sehr schöne Erklärung für Setup, Hold und Slack Time und warum und 
wann diese Zeiten negativ sind / sein können kommt von Xilinx Ingenieur 
Austin 
Lesea(http://forums.xilinx.com/t5/PLD-Blog/Timing-Constr...) 
den ich hier zitieren möchte:

Setup and Hold


In a practical synchronous digital system, the data must arrive before 
the clock edge that samples it.  The minimum amount of time in which the 
data must arrive before the clock edge is called the setup time.

As well as arriving before the clock edge, the data must persist for 
some finite amount of time at the clock edge.  This is called hold time. 
Hold time may be negative, zero, or positive.  When it is negative, the 
data goes away before the clock edge. When it is zero, the data persists 
until the clock edge.  When it is positive, the data persists for some 
time after the clock edge.

By design, in the FPGA fabric, for all speed grades, all hold times are 
either negative or zero.  This simplifies the placement and routing, as 
the data only needs to arrive before the clock edge, and is allowed to 
change immediately following a clock edge.

The value that the data exceeds the minimum setup time is known as 
slack.  Slack should always be positive.  If a report shows a negative 
slack, then the setup timing will be inadequate (data will arrive too 
late).

The clock path itself has delay, or skew.  Thus, to analyze the timing, 
the tools will calculate the arrival time of the data and the clock at 
the flip-flop of interest.



Constraints

If you recall from last time, the period constraint defines the clock 
period for the synchronous elements of interest (the flip-flops).  The 
timing analyzer verifies that all paths between synchronous elements 
meet the setup and hold timing for your design.  A violation of a period 
constraint will appear in the timing report, and have a negative slack 
value. It will either be identified as violating a setup requirement or 
a hold requirement.

If a setup requirement has been violated, then the data needs to arrive 
at the flip-flop sooner.  To do so may require a faster path.  If the 
place and route software cannot find a faster path, you do have the 
option of placing the path manually in the FPGA_Editor tool, but this is 
a tool of last resort. It is better to try to re-architect the circuit 
to meet the requirement.  One way to do this is to place a flip-flop 
earlier in the path.  This is known as pipe-lining, and will add latency 
to the signal, but it will also allow the value to be captured properly.

If a hold requirement has been violated (the data went away before the 
clock edge arrived), then this is often an indication that you have a 
design problem (bad architecture).  Values should only change on the 
clock edge, and not before.  If an external value is changing before the 
clock edge, one needs to delay the clock edge (using a DCM or PLL) so 
that the data is now registered properly by the new delayed clock.

An alternative is to use the Idelay element in the IOB to move the data 
to where the clock is valid.



Data Valid Window

The time from before the clock edge (setup) plus the time after the edge 
(hold) is known as the data valid window, or the time the data must be 
stable to be properly registered.  If the data is not valid for at least 
this amount of time, then the results are indeterminate, or unknown.



Metastability

Just because the data was not valid for as long as required does not 
mean that the output of the flip-flop is metastable--metastable is 
different from indeterminate!  An output could be 0 or 1, seemingly at 
random, if the timing is not met.  Metastability means the edge was 
“almost” capable of capturing the state and the flip-flop output is in 
some intermediate state (not 1, not 0) for some time after the clock 
edge.  Metastability cannot be prevented, as it is a fact of the physics 
of the circuits, if the clock edge and the data are almost perfectly 
“missed.”

In a properly designed synchronous system there are no problems with 
metastability.  Metastability is a problem when something is 
asynchronous, like pressing a key on a keyboard, or when two synchronous 
clocks are asynchronous to each other.  When something is asynchronous, 
it needs to be synchronized.

For how to deal with metastability, please consult:

http://www.stanford.edu/class/ee183/handouts_spr20...

Next time:  Tprop, or offsets.

Austin Lesea



Duke Scarring schrieb:
> 4) Ist das CLOCK_DEDICATED_ROUTE = FALSE nach Einfügen der Timing
> Constraints noch nötig?

Bedeudet einfach, dass nicht das interne Clock Netzwerk benutzt wird und 
wirkt sich dementsprechend auch negativ auf das Design aus. Timing 
Constraints helfen nichts, es müssen entsprechende Buffer oder ein DCM 
gesetzt werden -> Virtex User Guide ab Seite 25 gibt es Infos dazu...

Simon D. schrieb:
> 3) Kann man die Timing-Constraints in das normale handgeschriebene ucf
> File packen?

Ja, die werden in das ganz normale ucf file geschrieben



Meine Fragen sind nun weitestgehend beantwortet worden (bzw. habe ich 
teilweise selber beanwortet)...

Danke bei allen Beteiligten!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.