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:
1
NET "CLK" TNM_NET = "CLK";
2
TIMESPEC "TS_CLK" = PERIOD "CLK" 4 ns HIGH 50%;
3
OFFSET = IN 1 ns VALID 2 ns BEFORE "CLK" RISING;
4
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:
input[6:0] DDR_Data_In; // dual data rate data input
3
input Clock_In; // dual data rate clock input
4
output reg[13:0] SDR_Data_Out; // single data rate data output
5
output Clock_Out; // clock output for further synchronous circuits
6
7
integer i; // for indexing
8
reg[13:0] SDR_Data_Out_Buffer; // output buffer for synchronization
9
10
always@(posedge Clock_In) // read the even bits and set them to the output buffer
11
begin
12
for(i = 0; i <= 6; i = i + 1)
13
begin
14
SDR_Data_Out_Buffer[i * 2] <= DDR_Data_In[i];
15
end
16
SDR_Data_Out = SDR_Data_Out_Buffer; // set output with signal of output buffer
17
end
18
19
always@(negedge Clock_In) // read the odd bits and set them to the output buffer
20
begin
21
for(i = 0; i <= 6; i = i + 1)
22
begin
23
SDR_Data_Out_Buffer[i * 2 + 1] <= DDR_Data_In[i];
24
end
25
end
26
27
assign Clock_Out = !Clock_In; // output clock
28
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)
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.
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
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.
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...
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:
1
NET"CLK_P"TNM_NET=CLK_P;
2
TIMESPECTS_CLK_P=PERIOD"CLK_P"250MHzHIGH50%;
3
4
NET"CLK_N"TNM_NET=CLK_N;
5
TIMESPECTS_CLK_N=PERIOD"CLK_N"250MHzHIGH50%;
# Gruppieren von Netzen
1
INST"Data0_P"TNM=ADC;
2
INST"Data0_N"TNM=ADC;
3
INST"Data1_P"TNM=ADC;
4
INST"Data1_N"TNM=ADC;
# Definition der DDR-Zeitdaten der voher gruppierten Netze
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??
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.
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.
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.
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?
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
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?
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...
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
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-Constraints-Part-2-of-5/ba-p/59595)
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_spr2003/synchronization_pres.pdf
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!
Thread beobachten
Seitenaufteilung abschalten