Hi,
wollte mit dem ILA Debugger in Vivado meine Transceiver-Outputs
anzeigen lassen.
Aber der Debugger zeigt jedoch an: "Non-debuggable Nets" .. it is not
accessible from the fabric routing.
* Wie würdet ihr prüfen, ob da wirklich die richten Signal rauskommen?
* Eigentlich könnte ich auch mit einem Oszilloskop versuchen das zu
messen. * Aber die Frequenz ist wahrscheinlich zu hoch.
stochastik schrieb:> * Wie würdet ihr prüfen, ob da wirklich die richten Signal rauskommen?> * Eigentlich könnte ich auch mit einem Oszilloskop versuchen das zu> messen. * Aber die Frequenz ist wahrscheinlich zu hoch.
Willkommen im HF-Design!
Richtig, du kommst mit den normalen ILA-Pins nicht an die seriellen
Leitungen.
Wie im Post zuvor ist der IBERT eine gute Variante um isoliert den GT in
seinen Einstellungen auf der Hardware zu prüfen.
Auch ein schnelles Oszi ist hilfreich. Für die grobe Prüfung kann man im
IBERT auch ein low-speed pattern einstellen.
Nutzt du ein kommerzielles Eval-Board oder selber gebaute Hardware? Beim
Evalboard musst du eigentlich nur sicherstellen, dass deine Leitungen
richtigrum verbunden sind. P und N vertauscht, passiert richtig oft :)
Man kann auch viele Fehler abfangen, indem man das GT-Design simuliert.
Klakx -. schrieb:> ? Beim> Evalboard musst du eigentlich nur sicherstellen, dass deine Leitungen> richtigrum verbunden sind. P und N vertauscht, passiert richtig oft :)
Eigenes Board. Aber trotzdem muss ich die Eingänge noch etwas ändern lt.
Schaltplan.
GT Daten haben mich interessiert, weil ich nicht wusste ob der FPGA
letzten Endes wirklich die Signale ausgibt die haben möchte.
Vielleicht klappts aber nur die richtige Pin Zuweisung bei der FPGA
seitigen Konfig. besser und ich bekomme bei meinem Empfänger Chip ein
paar sinnvolle Signale.
IBERT
Klakx -. schrieb:> ie im Post zuvor ist der IBERT eine gute Variante um isoliert den GT in> seinen Einstellungen auf der Hardware zu prüfen.>> Auch ein schnelles Oszi ist hilfreich.
* Schnelles Oszi ok
* Mit IBERT die einzelnen Bits prüfen? PatternGen-> GT ->
PatternChecker?
du scheinst kaum Erfahrung mit GT und high-speed Signale zu haben.
Ehrlicherweise ist das mitunter bei den FPGAs mitlerweile das
komplexeste Thema.
Daher rate ich dir dringend dich ausgiebig in die Transceivertechnologie
einzuarbeiten (UG von Xilinx durchakern), und am besten erstmal an einem
Eval-Board Tests machen, von dem du ausgehen kannst, dass zumindest die
Hardware passt (Spannungsversorgung, entsprechend sauberes Clock-Signal,
etc.).
Selbst mit einem langsameren Scope (1 GHz), kann man z.B. wie obens
schon erwähnt ein low-frequency Testsignal ausgeben, um die Funktion
prinzipiell zu testen.
Viel Glück ;-)
tja schrieb:> Selbst mit einem langsameren Scope (1 GHz), kann man z.B. wie obens> schon erwähnt ein low-frequency Testsignal ausgeben, um die Funktion> prinzipiell zu testen.
Habe hier eins rusmtehen. Es kann aber nur 200 MHz.
Wollte gerade meine Ports im FPGA ändern.
Aber da kommt direkt ein critical warning:
Also das kommt beim implementation schritt .
Aber ok Bitstream generieren geht wohl.
Aber was bedeuten denn diese critical warnings?
Ist das weil Vivado durcheinander kommt?
Die MGT Pins sind fix und lassen sich nicht einfach ändern. Wenn du
einen anderen Transceiver nutzen willst, musst du das im IP Core direkt
einstellen. Jeder Transceiver hat genau eine einzige Möglichkeit der
elektrischen Verbindung. Beim REFCLOCK hat man pro Block in der Regel
zwei Eingänge, die man wahlweise nehmen kann...
Christian R. schrieb:> Die MGT Pins sind fix und lassen sich nicht einfach ändern. Wenn du> einen anderen Transceiver nutzen willst, musst du das im IP Core direkt> einstellen.
Vielleicht sollte man mal dem TO erklären, wie weit
Multigigabit-transceiver und 'normaler' transceiver - auseinander
liegen. So ein MGT macht eben nicht nur SerDes, CRC und 8/10 wie ein
'dummer LVDS-pin'. da steckt einiges an 'Black magic' drin:
Trainingspattern, pre-emphasis, ... da tut er sich reichlich schwer das
alles am scope zu erkennen und zu bewerten. Desholb sollte er mit dem
Integrated Bit Error Rate Estimator (IBERT) intensiv experimentieren und
den Parameterraum nach den idealen settings durchsuchen ...
Der TO wird wohl nicht umhinkommen die Grundlagen-dok wie
https://www.xilinx.com/support/documentation/user_guides/ug482_7Series_GTP_Transceivers.pdf
durchzuarbeiten.
Bei den Transceivern reicht es (glaub ich), wenn man nur den P Pin
constraint. Du musst auf jeden Fall aufpassen, dass ein P-Pin vom
Transceiver auch wirklich auf einen P-Pin am Gehäuse constraint ist. In
deinem Fall liegt sogar ein P auf einen N Pin. Das mögen die Transceiver
nicht. Falls du "Pin-Swapping" machen musst, dann kannst du das "invert"
Feature von den Transceivern nutzen. Damit wirt das Signal negiert und
du musst nicht im Schaltplan einen Pin-Swap machen.
tja schrieb:> Bei den Transceivern reicht es (glaub ich), wenn man nur den P Pin> constraint.
Wenn man den IO Pin Editor im geöffneten synthetisierten Design nutzt,
und dann in der Tabelle da beim MGT rein klick, wird meiner Erinnerung
nach automatisch der einzig mögliche Ball des Chips eingetragen. Bei den
XADC Pins ist das auch so. Das muss man nicht von Hand machen.
Christian R. schrieb:> Wenn man den IO Pin Editor im geöffneten synthetisierten Design nutzt,> und dann in der Tabelle da beim MGT rein klick, wird meiner Erinnerung> nach automatisch der einzig mögliche Ball des Chips eingetragen. Bei den> XADC Pins ist das auch so. Das muss man nicht von Hand machen.
nein, es gibt schon mehr Möglichkeiten. Wenn ich ein GT mit 4 Ports
implementieren, dann kann man die auch ziemlich frei in einem QUAD
nutzen. Vorausgesetzt, dass di zugehörigen TX und RX Pin am selben
Transceiver sind.
Bisher habe ich wegen der Vollständigkeitshalber die GT IOs auch immer
im Constraint File mit angegeben. Man sieht halt an einer Stelle welche
Pins wie verdrahtet sind, oder dass man sich der Toolchain behelfen
muss.
tja schrieb:> nein, es gibt schon mehr Möglichkeiten. Wenn ich ein GT mit 4 Ports> implementieren, dann kann man die auch ziemlich frei in einem QUAD> nutzen. Vorausgesetzt, dass di zugehörigen TX und RX Pin am selben> Transceiver sind.
Achso? Ich muss doch aber schon im IP Core Wizzard angeben, welchen GT
ich nutzen will/muss.
Christian R. schrieb:> Achso? Ich muss doch aber schon im IP Core Wizzard angeben, welchen GT> ich nutzen will/muss.
Da wird glaube ich aber nicht mehr gemacht, als einfach nur die
entsprechenden Constraints im XDC File generiert. Wenn du die einfach
ueberschreibst, solltest du trotzdem noch den Transceiver frei waehlen
koennen.
Vor allem wenn du die Refclocks des Transceivers nutzt und nciht eines
Nachbar. Von einem Nachbar wird er entsprechend den Common Block
beschalten um sie die benachbarte Clock zu holen. Fuer den Common Block
bietet es sich so oder so an, den nicht im Core sondern im Example
Design generieren zu lassen und selbst zu instanzieren - zumindest wenn
du die Freiheit beibehalten moechtest den Transceiver moeglichst frei zu
waehlen.
Wobei sich das evtl. auch nicht lohnt, weil du den Common Block
aufwendig umbauen musst. Da bleibt dann nur die goldene Loesung:
Transceiver IP via Tcl generieren lassen. Dann musst du nur die
Locations im Tcl Script aendern wenn du den Transceiver verschieben
willst. :-)
Tobias B. schrieb:> Transceiver IP via Tcl generieren lassen. Dann musst du nur die> Locations im Tcl Script aendern wenn du den Transceiver verschieben> willst. :-)
das klingt für mich neu. Kannst du ein paar Details dazu nennen wie man
da ran geht?
Das ist wirklich nur ein ganz simples Beispiel, das ich gerade ausm IP
Katalog rausgelassen hab. Ganz oben beim CHANNEL_ENABLE Property kannst
du die Location angeben (in dem Fall sind es 2 Transceiver, einer auf
X0Y1 und der andere auf X0Y0).
Ich wuerde einfach mal mit dem IP Wizard rumspielen, in der Console
siehst du dann die entsprechenden Tcl Befehle die benoetigt werden um
den IP Core zu generieren.
Stimmt, innerhalb des Quads geht das, ich hab ein Design was alle 16 GT
eines Artix 200 nutzt, da konnte ich die Belegung in einem Quad
anpassen, hatte das aber dann über Makros für die Vektor Indizes gemacht
und die 16 GT dann auf die 16 Anschlüsse der internen Logik gemapt. Das
war ja dann eh nochmal getrennt in Top und Bottom. Auf jeden Fall ist
die Verwendung der GT alles andere als mal eben schnell ohne Erfahrung
gemacht. Und die Hardware sollte von Anfang an drauf ausgelegt sein,
gerade wegen der REFCLK ...
Tobias B. schrieb:> Hier hab ich dir mal ein kleines Beispiel:
danke. Also die IP Generierung per Befehl kenne ich im Allgemeinen. Gibt
es hier etwas, dass man im Wizard nicht einstellen kann? Manchmal gibt
es Hidden Parameter.
btw: wie ich sehe, Ultra-Scale und Aurora8b10b. Der
fehlende/abgekündigte Support ist echt nervig. Bis jetzt habe ich mich
noch gescheut den Core am Tool vorbei zum Laufen zu bringen.
Christian R. schrieb:> Auf jeden Fall ist> die Verwendung der GT alles andere als mal eben schnell ohne Erfahrung> gemacht. Und die Hardware sollte von Anfang an drauf ausgelegt sein,> gerade wegen der REFCLK ...
Beides kann man nur zu 100% zustimmen! :-)
Klakx -. schrieb:> Gibt> es hier etwas, dass man im Wizard nicht einstellen kann? Manchmal gibt> es Hidden Parameter.
Mit einem "list_property [get_ips $ip_name]" kannst du dir die Liste
geben lassen. Bei obgigem Beispiel kommt heraus:
Inwieweit das vom GUI Wizard divergiert, kann ich aber leider nicht
sagen. :-(
Kleiner Nachtrag:
Mit report_property kann man sich das etwas angenehmer anzeigen lassen.
Habs mal zur besseren darstellung als Text File angehaengt.
setupDebug.png
(747 Bytes)
transceiverout0.png
(2,1 KB)
notdebuggable.png
(5,5 KB)
