Wykorzystanie niededykowanego JTAGa do FPGA

Feb 22, 2011 8 Replies

Witam



Czy próbował ktoś już ożenić jakikolwiej JTAG na USB, który *nie* jest dedykowany do układów FPGA do współpracy z takimi układami? Wiadomo, podstawową sprawą jest oprogramowanie... Osobiście byłbym zainteresowany wykorzystaniem klonu Turtelizera 2 (albo bezpośrednio, albo przez OpenOCD) do układów Xilinx, jednak jestem ciekawy, czy może jakieś inne JTAGi się do tego nadają? Może jakieś dedykowane do AVRów?? Słyszał ktoś kiedyś o czymś takim?? Próbował??



Pozdrawiam Konop


urjtsg obsługuje wiele różnych interfejsów, w tym także na usb, być może z twoim też będzie potrafił się dogadać. W poprzednim wcieleniu (jako jtag-tools) obsługiwał cpld xilinxa, więc może dorobił się także obsługi fpga.

pzdr. j.

W dniu 2011-02-22 09:09, Konop pisze:

Co do sprzętu to ci nie podpowiem, ale używałem biblioteki podmieniającej obsługę jtaga w ISE:

formatting link
Na liście obsługiwanych układów jest FTDI, ale demon prędkości to to nie będzie.

W dniu 2011-02-22 09:34 Zbych napisał(a):

O, a to niby dlaczego? FTDI ma przecież w swojej ofercie sprzętowe [de]serializery FT2232, produkowane też w wersji USB 2.0 HighSpeed. Taka maszynka MPSSE odpowiednio oprogramowana bezproblemowo robi SPI albo JTAG z zegarem kilkudziesięciu MHz.

W dniu 2011-02-22 21:34, Adam Dybkowski pisze:

Ano dlatego, że nie przeczytałeś tego co jest napisane na stronie:

Experimental support for FTDI 2232 based devices has been added. They are seen by Impact as a Parallel Cable III. These devices are currently significantly slower than every other supported cable.

FTDI udaje w tym rozwiązaniu jtaga na lpt, więc tak naprawdę dostaje instrukcje typu wyślij/odbierz x bitów. Jak x jest małe i uwzględni się częstotliwość nadawania/odbierania ramek USB to wychodzi nędza.

W dniu 2011-02-23 08:25 Zbych napisał(a):

No to dość słabo wymyślili. Czy protokoły programowania współczesnych układów CPLD i FPGA są ściśle strzeżone? I nikt jeszcze nie zrobił otwartego sterownika/biblioteki do tego, np. pod Linuxa? Stąd już byłaby krótka droga do normalnego wykorzystania pełnych możliwości scalaków pokroju FT2232.

W końcu gdy protokół jest ogólnie znany (np. JTAG dla ARMów) to taki OpenOCD sobie świetnie radzi, m.in. z kabelkami opartymi o FT2232.

Altera na wielu devkitach ma FTDI + malego MaxII jako Jtag. Schemat dostepny, wsad do MaxII dostepny, wiec wynika ze nikomu nie chce sie robic.

Xilinx zazdrośnie strzeże informacji o programatorze na USB. AFAIK protokół nie jest nigdzie opisany, a jak są jakieś implementacje to opierają się na RE. We wszystkich publicznie dostępnych dokumentacjach do płyt mających wbudowany programator zgodny z xilinxowym, ta część schematu jest wykasowana. Komunikacja sterownika kabla z IMPACTem też została zaimplementowana na podstawie tego co się dało wydedukować z fabrycznych sterowników. O ile sterownik kabla do lpt jest dość prosty (masz tylko machanie stanami linii), to sterownik kabla USB wygląda na bardziej skomplikowany. Sterownik o którym pisze Zbych powstał na bazie sterownika do kabla lpt, więc od strony aplikacji xilinxa ciągle jest widziany jako kłębek drutów. To nie jest kwestia protokołu którym się gada do kostki. Problem jest z protokołem którym gada IMPACT.

pzdr. j.

W dniu 23.02.2011 21:48, Adam Dybkowski pisze:

Ja bym tego nie określił "świetnie", OpenOCD to straszny muł. Wykonanie samego kroku w programie zajmuje 1/3 sekundy, a ze ściągnięciem danych jest to ponad 1/2 sekundy. I to wszystko na oryginalnych sterownikach do FTDI. Po przesiadce na libusb, OpenOCD jeszcze bardziej zwolnił (pojedynczy krok zajmował mu 0,7s).

A co do otwartości ARMów, to zależy co masz na myśli. Dokumentacja do komunikacji z rdzeniem jest, ale producenci nie kwapią się do publikacji komend jtag dla kontrolera flash (np. NXP), więc flash jest programowany przez program, który jest wrzucany do RAMu JTAGiem.

Join the Discussion

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

Didn't find your answer?

Ask the community — no account required