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:
1 | [Vivado 12-1411] Cannot set LOC property of ports, Cannot set PACKAGE_PIN property of ports, port a7_mgt216_rx_p_i[0] can not be placed on PACKAGE_PIN D14 because the PACKAGE_PIN is occupied by port a7_mgt216_rx_n_i[2] [../myconstraints.xdc":34] |
Aber die sind doch unterschiedlich im xdc file :
1 | set_property PACKAGE_PIN D14 [ get_ports a7_mgt216_rx_p_i[0] ] |
2 | |
3 | |
4 | |
5 | set_property PACKAGE_PIN C12 [ get_ports a7_mgt216_rx_n_i[2] ] |
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?
Klakx -. schrieb: > das klingt für mich neu. Kannst du ein paar Details dazu nennen wie man > da ran geht? Hier hab ich dir mal ein kleines Beispiel:
1 | create_ip -name gtwizard_ultrascale -vendor xilinx.com -library ip -version 1.7 -module_name ucnet_gth_example |
2 | set_property -dict [list CONFIG.preset {GTH-Aurora_8B10B}] [get_ips ucnet_gth_example] |
3 | set_property -dict [list \ |
4 | CONFIG.CHANNEL_ENABLE {X0Y1 X0Y0} \ |
5 | CONFIG.LOCATE_COMMON {EXAMPLE_DESIGN} \ |
6 | CONFIG.TX_LINE_RATE {15.625} \ |
7 | CONFIG.TX_PLL_TYPE {QPLL0} \ |
8 | CONFIG.TX_REFCLK_FREQUENCY {156.25} \ |
9 | CONFIG.TX_USER_DATA_WIDTH {32} \ |
10 | CONFIG.TX_INT_DATA_WIDTH {40} \ |
11 | CONFIG.RX_LINE_RATE {15.625} \ |
12 | CONFIG.RX_PLL_TYPE {QPLL0} \ |
13 | CONFIG.RX_REFCLK_FREQUENCY {156.25} \ |
14 | CONFIG.RX_USER_DATA_WIDTH {32} \ |
15 | CONFIG.RX_INT_DATA_WIDTH {40} \ |
16 | CONFIG.RX_JTOL_FC {9.3731254} \ |
17 | CONFIG.RX_REFCLK_SOURCE {} \ |
18 | CONFIG.TX_REFCLK_SOURCE {} \ |
19 | CONFIG.TXPROGDIV_FREQ_SOURCE {QPLL0} \ |
20 | CONFIG.TXPROGDIV_FREQ_VAL {390.625} \ |
21 | CONFIG.FREERUN_FREQUENCY {250} \ |
22 | ] [get_ips ucnet_gth_example] |
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:
1 | ALLOWED_SIM_MODELS ALLOWED_SIM_TYPES BASE_BOARD_PART BOARD BOARD_CONNECTIONS CAN_IP_GENERATE CLASS COMBINED_SIM_MODEL CONFIG.CHANNEL_ENABLE CONFIG.Component_Name CONFIG.DISABLE_LOC_XDC CONFIG.ENABLE_COMMON_USRCLK CONFIG.ENABLE_OPTIONAL_PORTS CONFIG.FREERUN_FREQUENCY CONFIG.GT_DIRECTION CONFIG.GT_REV CONFIG.GT_TYPE CONFIG.INCLUDE_CPLL_CAL CONFIG.INS_LOSS_NYQ CONFIG.INTERNAL_PRESET CONFIG.LOCATE_COMMON CONFIG.LOCATE_IN_SYSTEM_IBERT_CORE CONFIG.LOCATE_RESET_CONTROLLER CONFIG.LOCATE_RX_BUFFER_BYPASS_CONTROLLER CONFIG.LOCATE_RX_USER_CLOCKING CONFIG.LOCATE_TX_BUFFER_BYPASS_CONTROLLER CONFIG.LOCATE_TX_USER_CLOCKING CONFIG.LOCATE_USER_DATA_WIDTH_SIZING CONFIG.OOB_ENABLE CONFIG.ORGANIZE_PORTS_BY CONFIG.PCIE_64BIT CONFIG.PCIE_CORECLK_FREQ CONFIG.PCIE_ENABLE CONFIG.PCIE_GEN4_EIOS CONFIG.PCIE_USERCLK_FREQ CONFIG.PRESET CONFIG.RESET_SEQUENCE_INTERVAL CONFIG.RX_BUFFER_BYPASS_MODE CONFIG.RX_BUFFER_MODE CONFIG.RX_BUFFER_RESET_ON_CB_CHANGE CONFIG.RX_BUFFER_RESET_ON_COMMAALIGN CONFIG.RX_BUFFER_RESET_ON_RATE_CHANGE CONFIG.RX_CB_DISP_0_0 CONFIG.RX_CB_DISP_0_1 CONFIG.RX_CB_DISP_0_2 CONFIG.RX_CB_DISP_0_3 CONFIG.RX_CB_DISP_1_0 CONFIG.RX_CB_DISP_1_1 CONFIG.RX_CB_DISP_1_2 CONFIG.RX_CB_DISP_1_3 CONFIG.RX_CB_K_0_0 CONFIG.RX_CB_K_0_1 CONFIG.RX_CB_K_0_2 CONFIG.RX_CB_K_0_3 CONFIG.RX_CB_K_1_0 CONFIG.RX_CB_K_1_1 CONFIG.RX_CB_K_1_2 CONFIG.RX_CB_K_1_3 CONFIG.RX_CB_LEN_SEQ CONFIG.RX_CB_MASK_0_0 CONFIG.RX_CB_MASK_0_1 CONFIG.RX_CB_MASK_0_2 CONFIG.RX_CB_MASK_0_3 CONFIG.RX_CB_MASK_1_0 CONFIG.RX_CB_MASK_1_1 CONFIG.RX_CB_MASK_1_2 CONFIG.RX_CB_MASK_1_3 CONFIG.RX_CB_MAX_LEVEL CONFIG.RX_CB_MAX_SKEW CONFIG.RX_CB_NUM_SEQ CONFIG.RX_CB_VAL_0_0 CONFIG.RX_CB_VAL_0_1 CONFIG.RX_CB_VAL_0_2 CONFIG.RX_CB_VAL_0_3 CONFIG.RX_CB_VAL_1_0 CONFIG.RX_CB_VAL_1_1 CONFIG.RX_CB_VAL_1_2 CONFIG.RX_CB_VAL_1_3 CONFIG.RX_CC_DISP_0_0 CONFIG.RX_CC_DISP_0_1 CONFIG.RX_CC_DISP_0_2 CONFIG.RX_CC_DISP_0_3 CONFIG.RX_CC_DISP_1_0 CONFIG.RX_CC_DISP_1_1 CONFIG.RX_CC_DISP_1_2 CONFIG.RX_CC_DISP_1_3 CONFIG.RX_CC_KEEP_IDLE CONFIG.RX_CC_K_0_0 CONFIG.RX_CC_K_0_1 CONFIG.RX_CC_K_0_2 CONFIG.RX_CC_K_0_3 CONFIG.RX_CC_K_1_0 CONFIG.RX_CC_K_1_1 CONFIG.RX_CC_K_1_2 CONFIG.RX_CC_K_1_3 CONFIG.RX_CC_LEN_SEQ CONFIG.RX_CC_MASK_0_0 CONFIG.RX_CC_MASK_0_1 CONFIG.RX_CC_MASK_0_2 CONFIG.RX_CC_MASK_0_3 CONFIG.RX_CC_MASK_1_0 CONFIG.RX_CC_MASK_1_1 CONFIG.RX_CC_MASK_1_2 CONFIG.RX_CC_MASK_1_3 CONFIG.RX_CC_NUM_SEQ CONFIG.RX_CC_PERIODICITY CONFIG.RX_CC_PRECEDENCE CONFIG.RX_CC_REPEAT_WAIT CONFIG.RX_CC_VAL CONFIG.RX_CC_VAL_0_0 CONFIG.RX_CC_VAL_0_1 CONFIG.RX_CC_VAL_0_2 CONFIG.RX_CC_VAL_0_3 CONFIG.RX_CC_VAL_1_0 CONFIG.RX_CC_VAL_1_1 CONFIG.RX_CC_VAL_1_2 CONFIG.RX_CC_VAL_1_3 CONFIG.RX_COMMA_ALIGN_WORD CONFIG.RX_COMMA_DOUBLE_ENABLE CONFIG.RX_COMMA_MASK CONFIG.RX_COMMA_M_ENABLE CONFIG.RX_COMMA_M_VAL CONFIG.RX_COMMA_PRESET CONFIG.RX_COMMA_P_ENABLE CONFIG.RX_COMMA_P_VAL CONFIG.RX_COMMA_SHOW_REALIGN_ENABLE CONFIG.RX_COMMA_VALID_ONLY CONFIG.RX_COUPLING CONFIG.RX_DATA_DECODING CONFIG.RX_EQ_MODE CONFIG.RX_INT_DATA_WIDTH CONFIG.RX_JTOL_FC CONFIG.RX_JTOL_LF_SLOPE CONFIG.RX_LINE_RATE CONFIG.RX_MASTER_CHANNEL CONFIG.RX_OUTCLK_SOURCE CONFIG.RX_PLL_TYPE CONFIG.RX_PPM_OFFSET CONFIG.RX_QPLL_FRACN_NUMERATOR CONFIG.RX_RECCLK_OUTPUT CONFIG.RX_REFCLK_FREQUENCY CONFIG.RX_REFCLK_SOURCE CONFIG.RX_SLIDE_MODE CONFIG.RX_SSC_PPM CONFIG.RX_TERMINATION CONFIG.RX_TERMINATION_PROG_VALUE CONFIG.RX_USER_DATA_WIDTH CONFIG.SATA_TX_BURST_LEN CONFIG.SECONDARY_QPLL_ENABLE CONFIG.SECONDARY_QPLL_FRACN_NUMERATOR CONFIG.SECONDARY_QPLL_LINE_RATE CONFIG.SECONDARY_QPLL_REFCLK_FREQUENCY CONFIG.SIM_CPLL_CAL_BYPASS CONFIG.TXPROGDIV_FREQ_ENABLE CONFIG.TXPROGDIV_FREQ_SOURCE CONFIG.TXPROGDIV_FREQ_VAL CONFIG.TX_BUFFER_MODE CONFIG.TX_BUFFER_RESET_ON_RATE_CHANGE CONFIG.TX_DATA_ENCODING CONFIG.TX_DIFF_SWING_EMPH_MODE CONFIG.TX_INT_DATA_WIDTH CONFIG.TX_LINE_RATE CONFIG.TX_MASTER_CHANNEL CONFIG.TX_OUTCLK_SOURCE CONFIG.TX_PLL_TYPE CONFIG.TX_QPLL_FRACN_NUMERATOR CONFIG.TX_REFCLK_FREQUENCY CONFIG.TX_REFCLK_SOURCE CONFIG.TX_USER_DATA_WIDTH CONFIG.USB_ENABLE CONFIG.USER_GTPOWERGOOD_DELAY_EN CORE_REVISION DCP_RESOURCE_DATA DEFINITION_SOURCE DELIVERED_TARGETS DESIGN_TOOL_CONTEXTS FAMILY INTERNAL_MEMORY_ADDRESS IPDEF IP_CORE_CONTAINER IP_DIR IP_FILE IP_OUTPUT_DIR IP_SHARED_DIR IS_BD_CONTEXT IS_LOCKED IS_NATIVE KNOWN_TARGETS LOCK_DETAILS NAME PART REQUIRES_VIP SCOPE SELECTED_SIM_MODEL STALE_TARGETS SUPPORTED_TARGETS SUPPORTS_MODREF SW_VERSION UNSUPPORTED_SIMULATORS UPGRADE_RESULT UPGRADE_VERSIONS USED_LICENSE_KEYS USER_LOCKED USE_IP_SHARED_DIR |
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.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.