Constraint Problem?

#1977526
Lesenswert?

Hallo Leute,
mir ist etwas merkwürdiges bei der Post-PAR-Simulation aufgefallen. Der 
Sineout Ausgang ist erst ca. 7ns nach der steigenden CLOCK Flanke 
stabil. Fehlt da etwa eine Constraint?

Von OFFSET OUT/IN habe ich schon gehört. Später soll der Takt für denn 
DDS Core aber von einer DCM kommen und dann funktioniert diese 
Constraint nicht, falls ich es richtig verstanden habe.

Was nun?

Mfg,
Kurt
Angehängte Dateien:
Gast #1977556
Lesenswert?

Was passiert denn in DDS_CORE? Ist das eine RAM-Tabelle? Wann erwartest 
du denn die Daten? Sollten die Daten nicht mit der zweiten Taktflanke 
gültig sein?
1
CLK ___|---|___|---|___|---|___|---|
2
FTW            <Adresse        >
3
SIN                    <Daten  >

So sollte es doch sein ... aber ein paar zusätzliche Informationen 
deinerseits könnten nicht schaden.
Gast #1977595
Lesenswert?

Also ich habe mir jetzt fix das Timing angschaut. Laut Blockschaltbild 
werden die Daten einerseits gepuffert (Phase Accu) und dann per BlockRAM 
an den Ausgang gelegt. Also 1 Takt plus x ns Latenz. Der BlockRAM ist 
definitiv nicht synchron. Von daher erscheinen die Daten auch nicht mit 
der steigenden Taktflanke, sondern sind "irgendwann" gültig. Die 
Zugriffszeit ist allerdings definiert und somit kannst du dir die Latenz 
bis zum gültigen Signal entsprechend der Taktfrequenz ausrechnen.

Ich hoffe, ich erzähle gerade keinen Unsinn :D
#1977704
Lesenswert?

Ist doch ganz klar, die Post PAR Simulation bildet die Wirklichkeit mit 
den Ausgangsverzögerungen besser ab. In der Verhaltenssimulation 
erscheint das natürlich zur Flanke, in der Realität brauchts aber einige 
Zeit vom Register zum Pin. DU kannst das letzte Register ja mal in den 
IOB packen lassen, dann sollte es etwas schneller gehen, aber je nach 
Chip sind 7ns durchaus normal. Wenn du den CLK auch ausgeben 
willst/musst, dann am besten mit einem ODDR Register, dann hat er 
annähernd die gleiche Verzögerung wie die Daten.
Gast #1977788
Lesenswert?

@Kurt
Wenn du die IO-s schnell schalten willst solltest du die
IO-Timings deines Bausteins kennen, im Falle eines Xilinx-FPGAs
hier am Beispiel des spartan-3 im "ds099.pdf" auf
Seite 67 (Kapitel IO-timing):
http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf
Zitat:
"When reading from OFF, the time
from the active transition on the
Global Clock pin to data appearing
at the Output pin. The DCM is not
in use."
Dann steht in Tabelle das bei einem 12mA lvcmos25 FAST Ausgang der
die "clock-to-output" time je nach Typ 3.9..5.0 nanosekunden
betragen kann.
Bei anderen Treiberstärken muss man dann die Zahlen von Tabelle 46
addieren.
In deinem UCF-File fehlt die Angabe "DRIVE=" und "SLEW=", dann nimmt
der ISE (v10) 12mA und "SLEW=SLOW" als default., was nach Tabelle 46 
zusätzlich einen Delay von ca 3. nanosec. bedeuten kann.
Die Bedingungen für welche diese Zeiten gelten, sind dann auf den
folgenden Seiten erklärt.
Den delay kannst du nur durch stärkere Ausgänge veringern.
Am schnellsten schalten LVCMOS(xx) IOS dann bei 24mA SLEW=Fast.

Und dann aber auch noch  die "Simultaneously Switching Output 
Guidelines"
beachten (Seite 79ff).

Zugegeben alles eine trockene Lektüre.
Gast #1977917
Lesenswert?

Da sieht man was passiert wenn man nur mit Altera rumspielt :)
Das SINEOUT ein IOB ist und nicht irgendein interenes Signal hab ich 
komplett übersehen. Das erklärt natürlich so einiges und die richtigen 
Antworten kamen ja bereits. And dieser Stelle unterscheiden sich die 
Schematics doch etwas mehr voneinander.

Sorry für die unqualifizierten Einträge meinerseits :)

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren