artix 7 transceiver debuggen?

[stochastik (Gast)]

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.

[Früher beim Diplom (Gast)]

versuch mal IBERT statt ILA ...

[Klakx -. (klakx)]

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.

[stochastik (Gast)]

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?

[tja (Gast)]

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 ;-)

[stochastik (Gast)]

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:

[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 :

set_property PACKAGE_PIN D14            [ get_ports a7_mgt216_rx_p_i[0]  ]



set_property PACKAGE_PIN C12            [ get_ports a7_mgt216_rx_n_i[2]  ]

[stochastik (Gast)]

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?

[Christian R. (supachris)]

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...

[Fremdschämender Ingenieur (Gast)]

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.

[tja (Gast)]

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.

[Christian R. (supachris)]

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.

[tja (Gast)]

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.

[Christian R. (supachris)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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. :-)

[Klakx -. (klakx)]

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?

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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:

create_ip -name gtwizard_ultrascale -vendor xilinx.com -library ip -version 1.7 -module_name ucnet_gth_example
set_property -dict [list CONFIG.preset {GTH-Aurora_8B10B}] [get_ips ucnet_gth_example]
set_property -dict [list \
  CONFIG.CHANNEL_ENABLE {X0Y1 X0Y0} \
  CONFIG.LOCATE_COMMON {EXAMPLE_DESIGN} \
  CONFIG.TX_LINE_RATE {15.625} \
  CONFIG.TX_PLL_TYPE {QPLL0} \
  CONFIG.TX_REFCLK_FREQUENCY {156.25} \
  CONFIG.TX_USER_DATA_WIDTH {32} \
  CONFIG.TX_INT_DATA_WIDTH {40} \
  CONFIG.RX_LINE_RATE {15.625} \
  CONFIG.RX_PLL_TYPE {QPLL0} \
  CONFIG.RX_REFCLK_FREQUENCY {156.25} \
  CONFIG.RX_USER_DATA_WIDTH {32} \
  CONFIG.RX_INT_DATA_WIDTH {40} \
  CONFIG.RX_JTOL_FC {9.3731254} \
  CONFIG.RX_REFCLK_SOURCE {} \
  CONFIG.TX_REFCLK_SOURCE {} \
  CONFIG.TXPROGDIV_FREQ_SOURCE {QPLL0} \
  CONFIG.TXPROGDIV_FREQ_VAL {390.625} \
  CONFIG.FREERUN_FREQUENCY {250} \
] [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.

[Christian R. (supachris)]

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 ...

[Klakx -. (klakx)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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:

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.