Xilinx Spartan 3, "komponent" BSCAN i komunikacja przez JTAG

Sep 18, 2015 5 Replies

Witam. Mam pytanie do Kolegów rzeźbiących w FPGA Xilinxa. Próbuję wykombinować loader umożliwiający mi za pośrednictwem JTAG-a wrzucenie danych do wewnętrznej pamieci BlockRAM w FPGA. Poniżej fragment opisujący obsługę sygnałów z BSCAN



reg [31:0] JTAG_SR; reg [31:0] JTAG_OUT; BSCAN_SPARTAN3 BSCAN_SPARTAN3_inst ( .CAPTURE(BS_CAPTURE), // CAPTURE output from TAP controller .DRCK2(BS_DRCK2), // Data register output for USER2 functions .SEL2(BS_SEL2), // USER2 active output .SHIFT(BS_SHIFT), // SHIFT output from TAP controller .TDI(BS_TDI), // TDI output from TAP controller .UPDATE(BS_UPDATE), // UPDATE output from TAP controller .TDO2(JTAG_SR[0]) // Data input for USER2 function );



always @(posedge BS_DRCK2) begin if(BS_SHIFT) begin JTAG_SR <= {BS_TDI, JTAG_SR[31:1]}; end end



always @(posedge BS_UPDATE) begin if(BS_SEL2) begin JTAG_OUT <= JTAG_SR; end end



=====



Próbuję to potraktować za pośrednictwem programu iMPACT w trybie wsadowym. Wsad wygląda tak (w łańcuchu JTAG mam jeszcze pamięć konfiguracyjną)



setMode -bs setCable -port auto



bsdebug -start bsdebug -reset



# pamięć na BYPASS, FPGA na USER2 bsdebug -scanir 11111111000011 -irlength 14



# dane do przeslania, pierwszy bit to BYPASS pamieci konfiguracyjnej bsdebug -scandr 000000000000000000000111100001111 -drlength 33 bsdebug -scandr 000000000000000010000011111101100 -drlength 33 bsdebug -scandr 000000000000000100000111100001111 -drlength 33 bsdebug -scandr 000000000000000110000011001101010 -drlength 33 bsdebug -scandr 000000000000001000000111100001111 -drlength 33 bsdebug -scandr 000000000000001010000011010000001 -drlength 33 bsdebug -scandr 000000000000001100000111100001111 -drlength 33 bsdebug -scandr 000000000000001110000011010000110 -drlength 33 bsdebug -scandr 000000000000010000000111100001111 -drlength 33 bsdebug -scandr 000000000000010010000011010001011 -drlength 33 bsdebug -scandr 000000000000010100000111100001111 -drlength 33 bsdebug -scandr 000000000000010110000011010010000 -drlength 33 bsdebug -scandr 000000000000011000000111100001111 -drlength 33 bsdebug -scandr 000000000000011010000011010011000 -drlength 33 bsdebug -scandr 000000000000011100000111100001111 -drlength 33 bsdebug -scandr 000000000000011110000011011011111 -drlength 33 bsdebug -scandr 000000000000100001010000111111111 -drlength 33 bsdebug -scandr 000000000000100011101000100010000 -drlength 33 bsdebug -scandr 000000000000100100111000000110000 -drlength 33 bsdebug -scandr 000000000000100111100000100000001 -drlength 33 ... duuuuuuużo linijek z scandr bsdebug -scandr 000001111111110110000000000000000 -drlength 33 bsdebug -scandr 000001111111111000000000000000000 -drlength 33 bsdebug -scandr 000001111111111010000000000000000 -drlength 33 bsdebug -scandr 000001111111111100000000000000000 -drlength 33 bsdebug -scandr 000001111111111110000000000000000 -drlength 33



bsdebug -stop closeCable quit



=======



Programator USB DLC9G. Robię kilka prób z tym samym plikiem wsadowym. Czasem to zadziała (zwłaszcza jak jest niewiele linii bsdebug -scandr), ale najczęściej przejdzie kilkadziesiąt pierwszych słów 32-bitowych i przestają się pojawiać sygnały DRCK2 i UPDATE. Często dochodzi do resetu układu lub niekiedy nawet jego przeprogramowania.


P.S. Na tym samym sprzęcie (komputer/programator/Xilinx) układ FPGA poprawnie przyjmuje "wsad" przez JTAG-a.


W dniu piątek, 18 września 2015 23:44:32 UTC+2 użytkownik Grzegorz Kurczyk napisał:

Najupierdliwsze tematy są właśnie takie jak opisałeś. Nie wiem, czy pomogę w czymkolwiek pomóc, ale podzielę się własnymi spostrzeżeniami/doświadczeniami.

Jeżeli działa to w sposób losowy, to podejrzewam :

1) Błąd na Twoim HW, źle dobrane wartości rezystorów/kondziorów/brak terminacji TCK. Zwróć też uwagę na BUSY/CCLK/PROGRAM_B/DONE/INIT_B. Ja robię na S6 i wygląda to tak:

formatting link

2) Przetwornice vs. PCB. Jeżeli masz na iluśtam warstwowej PCB "splitted power planes'y" i sygnały konfiguracyjne przebiegają nad/pod zmianą GND/VCC, to też może robić chocki-klocki.

3) iMPACT - w najnowszej i chyba ostatniej wersji 14.7 są problemy. Nawkurwiałem się przy tym chyba z tydzień, gdzie jest "bug". Nie wiem i nie chcę wiedzieć. Po wygenerowaniu bitstreama, używam do wstrzyknięcia iMPACT'a v12.1 i jest OK.

Tyle mogę doradzić... Dej znać staremu chłopu (50+), czy coś sensownego doradziłem.

W dniu sobota, 19 września 2015 12:16:59 UTC+2 użytkownik snipped-for-privacy@gmail.com napisał:

=======================

Ooopsss... "czy pomogę w czymkolwiek pomóc" - takie "piękne zdania" wychodzą, jak mi baba gitarę zawraca w tematach kuchennych podczas odpowiedzi na tematy zdecydowania niekuchenne :)))

W dniu 19.09.2015 o 12:16, snipped-for-privacy@gmail.com pisze:

Dzięki za odzew :-) Jeśli chodzi o HW to jest to gotowy moduł

formatting link
w wersji 13.1. Nie mam żadnych problemów z "wstrzyknięciem" bitstreama. ChipScope, który wykorzystuje BSCAN/USER1 też działa poprawnie więc szukam błędu w tym co robię. Choć wcale nie wykluczone, że w trybie wsadowym iMPACT coś kaszani po JTAG-u. Trzeba będzie podłączyc analizator stanów logicznych pod JTAG-a i prześledzić bit po bicie... ale będzie rzeźnia :-/

W dniu niedziela, 20 września 2015 12:33:30 UTC+2 użytkownik Grzegorz Kurczyk napisał:

1) Sprawdzanie na analizatorze bit po bicie, clock za clock'iem, nie wyobrażam sobie tego tak do powyżej kilkunastu kliknięć zegara. Toż to jest robota dla Mnichów z Shaolin na pierdyljon lat !! 2) A weźże zaimplementuj w swoim projekcie BRAM, zainicjuj zawartość owego w CoreGen, zapuść implementację, wstrzyknij bitstreama i tyle...

Tak to widzę.. Szkoda czasu na pierdyczenie się w zerojedynki przez chujwie ile czasu. Aha..., spróbuj innej wersji iMPACT'a, też mogą być chece. v14.7 robi problemy. Po wygenerowaniu bitfajla, używam do wstrzykiwania v12.1

W dniu 25.09.2015 o 01:35, snipped-for-privacy@gmail.com pisze:

Z tej strony Mnich z Shaolin badający bit po bicie :-) Podpiąłem swego HP1661CS pod złacze JTAG plus kilka sygnałow pomocniczych wyprowadzonych z modułu BSCAN i wszystko wskazuje na to, że od czasu do czasu sieczcka idzie z programatora. Teraz muszę sprawdzić czy to robi sam programator czy wersja iMPACTa jest gów...na :-/

Sam blok, który zaimplementowałem z użyciem BSCAN zachowuje się poprawnie w stosunku do tego co dostaje z JTAG-a. Jak sekwencje sygnałów na JTAG-u są prawidłowe, to "na wyjściu" mam to co chciałem. Jak na JTAG-u sieczka no to nie dziwota, że śmieci na wyjściu.

Jeszcze jedno co zauważyłem. W pamięci PC-ta uruchomiony tylko ISE Project Navigator i analizator potrafił mi się niekiedy wyzwolić z sekwencją wręcz przypadkowych stanów na liniach JTAG-a.

Normalnie cuda-wianki :-/

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required