Hallo,
Bei einem Design habe ich folgende Situation:
Es werden synchron zum Takt 4 Ausgangssignale erzeugt. Diese Signale
werden in einer externen Elektronik verzögert und manipuliert. Die
Signale werden dann wieder zum FPGA geführt wo die Signale entweder
direkt wieder ausgegeben werden oder zusammengefasst werden (rein
kombinatorisch).
1
Spartan 6 |
2
|
3
| 4 +----------+
4
OUTPUT +----/---->| |
5
| | |
6
| | SOMETHING|
7
INPUT | 4 | |
8
+---------+<----/----| |
9
| | +----------+
10
| |
11
| |
12
v |
13
+---- --+ |
14
| | |
15
| comb. | OUT | 2
16
| logic +---->+---/----> EVALUATION
17
| | |
18
| | |
19
+-------+ |
Jetzt ist es so, dass nach der Erzeugung der Signale der ganze Pfad
asynchron zum Takt verläuft, da die Verzögerungen der externen
Elektronik später von Interesse sind. Deshalb würde ich gerne per
Constrains erreichen, dass die Pfade im FPGA auch ca. die selben Delays
aufweisen. Wie macht man das?
Danke,
Stefan
>dass die Pfade im FPGA
1. Welche Pfade meinst Du?
2. Arbeitet Dein "Something"-Kasten mit einem Takt? Dem FPGA-Takt?
Was genau hast Du eigentlich vor? Nur der Vorstellung wegen ...
Hallo,
Die Signale OUTPUT werden synchron mit dem FPGA Takt über 4 Zähler
erzeugt und an die Ausgangspins gelegt. Hier wäre das erste mal ein min.
Delay zwischen den Signalen gewünscht (wenn alle Zähler den selben Wert
haben).
Der "Something" kasten arbeitet komplett ohne Takt. Besteht aus einem
Grab aus Transistoren, FETs, ... Dabei erhalten die Signale
unterschiedliche Delays, in Abhängigkeit der Messgröße, es bleibt aber
die Ordnung erhalten also immer Signal 1 vor Signal 2 vor Signal 3 vor
Signal 4.
Diese Signale füttere ich dann wieder dem FPGA der z.B.: im einfachsten
Fall nur z.B.: Signal 1 und Signal 3 wieder an die Auswertelektronik
ausgibt. Das Delay der beiden Signale zueinander sollte aber so gut wie
möglich erhalten bleiben. Je nach Anwendung wären dann aber auch z.B.:
kombinationen der Signale wie XOR oder AND denkbar.
Es ist so, dass wenn ich die das Delay der Signale von OUTPUT zu
EVALUATION momentan messe sind es ca. 24ns wobei der Durchlauf durch
Something (OUTPUT bis INPUT) ca. 8ns benötigt. Elso gehen mir bei dem
kombinatorischen Teil grob geschätzt die fehlenden 16ns verlohren. Was
mich für eine IN -> XOR -> OUT Konfiguration sehr wundert. Und denke mir
mit Constrains kann ich diesen Teil optimieren.
Danke
Du könntest den Teil, der im FPGA getaktet ist, bei der Ausgabe mit
Ausgansgsregistern in den IO-Zellen versehen.
(Wie schnell ist der Takt?)
Du könntest die kombinatorische Logik nahe an den FPGA-IOs platzieren,
dafür gibt es Constraints (muss Du mal suchen, Stichwort "placement").
Natürlich gibt es eine Mindest-Verzögerungszeit von Pin-nach-Pin im
FPGA, sollte im FPGA-Datenblatt stehen. Diese ist fest. Hinzu kommt das
Logik-Routing. Durch die Rand-Platzierung sollte es kürzer und
deterministischer ausfallen.
Stefan S. schrieb:
Deshalb würde ich gerne per
> Constrains erreichen, dass die Pfade im FPGA auch ca. die selben Delays> aufweisen. Wie macht man das?
Garnicht. Falls du wirklich sowas sucht wie, "verzögere signal a um 2,34
ns (externe Verzögerung)", dann vergiß es. Was realisierbar ist sind
constraint wie
das Signal a darf höchsten 5 ns von A nach B benötigen.
Vielleicht ist board level deskewing das was du suchst, da braucht es
aber mehr als nur constraints:
http://www.xilinx.com/support/documentation/application_notes/xapp132.pdf
Stefan S. schrieb:> Jetzt ist es so, dass nach der Erzeugung der Signale der ganze Pfad> asynchron zum Takt verläuft,
Wieso? Die Signale werden doch synchron erzeugt, also sind auch deren
Reaktionen synchron zum Takt, nur eben mit Delay behaftet.
> da die Verzögerungen der externen> Elektronik später von Interesse sind.
Kapiere ich nicht. Wieso sind die Signale deshalb (a)synchron, weil sie
"später von Interesse sind"?
Ich denke, Du meinst etwas komplett anderes, als Du geschrieben hast.
> Deshalb würde ich gerne per> Constrains erreichen, dass die Pfade im FPGA auch ca. die selben Delays> aufweisen. Wie macht man das?
Welche "Delays" sollen so gross sein, wie welche?
Grundsätzlich kannst Du erstmal nur in der Raster arbeiten, dass der
FPGA-Takt vorgibt. Alles andere ist unbestimmt und kann nicht direkt
vermessen werden.
Hallo,
Danke für die Antworten. Der Takt mit dem die Signale generiert werden
ist irgendwo im Bereich von 40-80MHz und kommt von einer externen
Quelle. Mit diesem Takt werden 5 Zähler getaktet. Wenn der erste Zähler
einen einstellbaren Stand erreicht werden die anderen 4 Zähler gestartet
und erzeugen dann, nach erreichen eines einstellbaren Zählstandes, ein
high an ihren Ausgängen welches die 4 Ausgangssignale sind, welche zu
der externen Schaltung gehen. Dort ergibt sich dann in Abhängigkeit der
Messgröße ein Delay von ca. 1ns bis 70ns jedoch für alle 4 Signale
unterschiedlich. Dieses Delay der einzelnen Signale ist dann ein Teil
der zu bestimmenden Information.
Man könnte jetzt direkt diese Delays auswerten, aber je nach Meßeinsatz
wäre die Information die z.B.: Signal1 XOR Signal2 enthält von Interesse
und nicht direkt die einzelnen Signale. Da sich diese Verknüpfung ändern
kann, dachte ich mir es macht Sinn diese Signale wieder dem eh schon
vorhandenen FPGA zurückzuführen, welcher dann die Verknüpfung
durchführt. Hätte mir halt erwartet, dass die I/O Delays and Routing
Delays für die Signalpfade vergleichbar sind und absolut gesehen kürzer
(sowas um 8ns und nicht 16ns).
Werde mal weiter mit dem Timing Analyzer und PlanAhead spielen.
Also wenn du einfach nur willst das die 4 Signale + Takt in etwa
zeitgleich ohne wirklich messbaren Delay zueinander nach außen gehen,
also die FPGA-Pins verlassen, dann folgendes machen (für Xilinx): 1.vor
die Registerdefiniton von den 4 Signalen schreibst du (* IOB="TRUE" *)(
zumindest in Verilog)
2. Du legst alle 4 Signale (und Takt) in die gleiche Region im ucf-File.
So erreichst du das deine 4 Signale so gut wie zeitgleich den FPGA
verlassen. Verzögerung sind irgendwo in ps-Bereich. Also für 40-80 Mhz
irrelevant.
Ps. der Krams ist nicht auf meinem Mist gewachsenen, sondern von nem
schlauen Kerl ausm Xilinx-Forum, hier der Originalbeitrag:
http://forums.xilinx.com/t5/Implementation/Cannot-constraint-the-OUTPUT-clock-vs-data-the-GUI-says-the/td-p/245310
>2. Du legst alle 4 Signale (und Takt) in die gleiche Region im ucf-File.
Wie ist das gemeint? Sicher sollen die Signale nicht im UCF file nahe
beieinnander sein, sondern bei den IOS? Das kann man sich aber doch
nicht aussuchen. (??)
HTI schrieb:> Stefan S. schrieb:> Alles andere ist unbestimmt und kann nicht direkt vermessen werden.
Nun ja, man könnte das schon durchaus hindrehen, bis auf einige
Bruchteile von Nanosekunden, es erfordert aber ein Eintrainieren der
Ausgänge und der Eingänge mittels der programmierbaren IOs und damit zum
Einen eine Schaltung, die eine Referenz und die Eingänge gibt und zum
Anderen auch die Ausgänge auf justierte Eingänge gibt, damit man das
komplett in Software im FPGA machen kann. Ist aber ein bissl
"oversized".
Wenn es Messungen mit reproduzierbaren Ergebnissen sind kann man die
Ausgänge des FPGAs auf parallele Eingänge legen, die selber noch von
einem Ausgäng gespeist werden. Damit sind die Eingänge und später die
Ausgänge trainierbar. Ab dann kann die Messung statistisch erfolgen,
indem man die Augänge kontinuierlich schiebt. Das ergibt relative
Ergebnisse zum Takt, die man aber mit einer durch diesen Takt
gesteuerten Filterung beaufschlagen und damit glätten kann. Die Maxima
ergeben dann Zeitpunkte, die eine relative Lage zum Messtakt und damit
wieder einen absoluten Zeitpunkt haben.
Solcherlei Spielchen führen aber am Ende zu einer doch sehr begrenzten
Genaugikeit, weil die FPGA-Ausgänge nicht die analoge Güte haben, um
präzise genug zu schalten. Mehr als 1/10 Takt + Taktjitter = ca. 100 ps
Auflösung bekommt man auch durch noch so viele redundante Messungen
nicht hin. Um zeitgenaue Messungen weit unterhalb des Taktrasters zu
machen, müssen die Ausgänge der FPGAs einen schnellen Schalter hinten
drauf bekommen (GaAs-Transitortypen) dem ein Bandpass-Filter
vorgeschaltet ist, dass auf die Taktflanke eingestellt ist. Das
verrinngert zwar die Schaltgeschwindigkeit, präzisiert sie aber
genügend, um sie reproduzierbar zu machen, weil dann
NF/Bias-Einstreuungen und HF-EMV weniger wirken. Damit sind
Schaltgenauigkeiten um den Faktor 10-20 zu verbessern.
Dasselbe macht man nun an den Eingängen: Filter und Schmitt-Trigger.
Damit wird das Delay insgesamt deutlich grösser, als bei der direkten
Schaltung, aber erheblich genauer. Wenn man es ordentlich baut, sind
Schaltvorgänge für grössere Gruppen von Ausgängen bis unter 10ps auf den
Takt reproduzierbar. Die absolute Genauigkeit, also die Lage des
Zeitpunktes realtiv zur theoretischen Zeit, hängt dann nur noch am
FPGA-Takt.
Thread beobachten
Seitenaufteilung abschalten