Problemy z konfiguracj? FPGA

No takich checów to jeszcze nie miałem... Temat jest kontynuacją wcześniejszego problemu dot. FTDI/FPGA, na chłopski rozum, guzik jedno z drugim ma coś wspólnego (w temacie konfiguracji logiki FPGA) , tymczasem łapy mnie opadają..

Podpinam się do JTAG'a (iMpact), odpalam Dziada i zgodnie z oczekiwaniem dostaję z automatu rozpoznany łańcuch połączeń:

TDI=>[FPGA(XC6SLX45)]=>[PROM(XCF16p)]=TDO

No i teraz mam 3 możliwości..

1) wstrzyknąć bitfajla od razu do FPGA 2) wygenerować fajla StachuChebel.mcs i zapisać dziada na dysku 3) Zaprogramować dziada Impactem (PROM)

No to zaczynamy teraz opis problemu. punkt po punkcie:

1) po zaprogramowaniu jest OK całość działa tak jak zaprojektowałem 2) Też nie ma problemu. 3) Też się programuje bez komunikatów o błędach i takich tam...

No i teraz zaczyna się jajco. Czegoś takiego jeszcze w życiu nie miałem. Bywało, że układ się nie chciał zaprogramować z PROM'a i wtedy totalna kicha, ale zawsze było to spowodowane jakimś tam bablokiem na PCB. Tymczasem teraz mam jajco takie, że FPGA zasysa dane z PROMA, jak gdyby z błędami. Po zaprogramowaniu FPGA JTAG'iem, całość działa perfekcyjnie, a po zaprogramowaniu z PROM'a tak nie do końca wszystkie funkcje działają. Sprawdzałem zgodność pliku *.mcs z zawartością PROM'a - jest OK.

POMOCY Koledzy, bo brak mi jakiejkolwiek koncepcji !!

Reply to
stchebel
Loading thread data ...

W dniu 26.07.2014 22:21, snipped-for-privacy@gmail.com pisze:

  1. Wrzuć gdzieś schemat połączeń między XFC a XC6.
  2. Spróbuj stworzyć plik mcs komendą z mojego sąsiedniego posta.
Reply to
Mario

W dniu 26.07.2014 22:21, snipped-for-privacy@gmail.com pisze:

  1. Wrzuć gdzieś schemat połączeń między XFC a XC6. Jeśli połączenia są zgodne z zaleceniami to:
  2. Spróbuj stworzyć plik mcs komendą z mojego sąsiedniego posta.
  3. Utwórz nową konfigurację w graficznym Impact prze skanowanie łańcucha itd. Ewentualnie zaprogramuj w trybie konsolowym.
  4. Musiałbyś ustalić czy "funkcje nie do końca działają" oznacza jakąś poprzednią wersję, czy też nieobliczalne działanie wersji przed chwilą skompilowanej. Może być, że do XC6 ładujesz nową wersję StachuChebel.bit, a do XCF wrzucasz StachuChebel.mcs, który nie jest zrobiony z tej wersji pliku bit. NA przykład z innego foldera. Sprawdź sobie na przykład psując celowo projekt i plik bit i patrząc jaki efekt po zaprogramowaniu PROMa.
Reply to
Mario

W dniu sobota, 26 lipca 2014 22:41:57 UTC+2 użytkownik Mario napisał:

formatting link
Połączenia CDAT[0..7] i wszelakie inne pierdulamenty idą tam gdzie trza.

Jutro.

To co piszesz ma sens. Też yak sobie pomyślałem, bo faktycznie miałem wcześniej wersję projektu, która właśnie tak się zachowywała. Jasna sprawa, ja tam coś niecoś spartoliłem. No ale teraz już próbowałem sztuczek Nowy_Projekt.bit=>StachuChebel.mcs ... Ciężko zauważyć jakiekolwiek podobieństwo pomiędzy nazwami plików i w związku z tym pomylić się.

Ale tak na marginesie, coś mi w łepetynie zaświtało!! Otóż mam pewne jajco z iMpactem już od pewnego czasu. W zasadzie olałem problem, być może zbyt pochopnie. Mianowicie, Korzystam z WebPacka v14.7 i jakakolwiek próba odpalenia impacta kończy się komunikatem o errorze (boszsz... te anglowulgaryzmy). Mam też na twardzielu v12.1, i stąd odpalam impacta. Może tu jest jajco? Nie wiem, brak mi pomysłu co dalej.

Hmmm..., a może jeszcze inaczej? A gdybym Ci tak podesłał *.bit, Ty byś przemielił to na *.mcs i odesłał? Byłbym b. wdzięczny. Chociaż diabli wiedzą jaki plik zasysa impact. Może przez nieuwagę wdupcyłem mu jakiegoś default'a ?!

Reply to
stchebel

W dniu sobota, 26 lipca 2014 22:30:11 UTC+2 użytkownik Mario napisał:

Szalony pomysł, ino go cholera nie zrobię. Dlaczego? Ano dlatego, że mógłbym uwalić przez to inne scalaki na pokładzie PCB. Jakieś 300$+. Ale tak czysto teoretycznie, maskować *.bit na '0' lub '1' na kolejnych bitach. Wiem, wiem, jest to harcerska metoda, tak nie powinno się robić, ja to rozumiem.. Efekty mogą być opłakane. Ale kurde, korci mnie....

Reply to
stchebel

W dniu 26.07.2014 23:20, snipped-for-privacy@gmail.com pisze:

Wydaje się w porządku.

Możesz sprawdzić który plik ładuje do PROMu. Najpierw zobacz czy widzi, że się zmienił plik .bit. Gdy w trakcie kompilacji projektu masz otwarty Impact, to przy próbie wykonania Generate File zgłosi ostrzeżenie, że plik źródłowy zmienił się poza Impactem. To znaczy że widzi zmianę pliku bit. Wygeneruj plik mcs. Odszukaj powstały plik mcs (po czasie utworzenia) i usuń go. Jeśli mimo tego dasz radę wykonać Programm (z Available Operations w tabie Impact Processes) dla twojego XCF16 to znaczy, że sobie programujesz inną wersją pliku mcs. Mogę oczywiście spróbować wykonać plik mcs, ale nie jestem pewien efektu. Ja używam szeregowej pamięci xcf04 i do niej wystarczył przełącznik -x xcf04s. Zakładam, że dla XCF16 wystarczy ustawić xcf16p bo jest taki plik bsd, ale może trzeba podać dokładniej typ jak xcf16p_1532 albo xcf16p_fs48. W sumie jest ze 6 plików bsd dla tej pamięci. Poza tym program promgen ma wiele innych przełączników, ale chyba głównie dla konfiguracji daisychain. Wyśle ci maila na twoje konto gmailowe. Jeśli chcesz żebym stworzył plik mcs to podeślij bit

Reply to
Mario

W dniu niedziela, 27 lipca 2014 00:23:55 UTC+2 użytkownik Mario napisał:

OK, serdeczne dzięki. Jutro ( w zasadzie już dzisiaj) rano podeślę *.bit . Dzisiaj już padam na pysk, więc prysznic, piwko i do wyra .

Pozdrawiam, Stachu.

Reply to
stchebel

W dniu 2014-07-27 01:22, snipped-for-privacy@gmail.com pisze:

Etam. Drink i CS GO.

Pozdrawiam MD

Reply to
Mario

W dniu niedziela, 27 lipca 2014 01:26:48 UTC+2 użytkownik Mario napisał:

:)))

Sruuuu !!.. Fajla wysłałem. Zobaczymy co z tego wyjdzie. Oby wyszło OK. Jeżeli tak, to wiadomo do czego się przypie....ć. Ano do impacta, albo burdelu u mnie w kompie. Jak dalej będzie to samo, to już brak pomysłów mnie ogarnia.

Reply to
stchebel

A tak z ciekawości- murarz zdradzić co ten projekt z FPGA ma robić? I dlaczego na FPGA?

Reply to
Marek

W dniu niedziela, 27 lipca 2014 16:18:19 UTC+2 użytkownik Marek napisał:

Tak po krótce, to ma odbierać dane 12-to bitowe z przetwornika A/C z częstotliwością 80MHz, robić w czasie rzeczywistym demodulację sygnału i cisnąć to przez USB do peceta.

Reply to
stchebel

W dniu 27.07.2014 19:51, snipped-for-privacy@gmail.com pisze:

To trochę tak jak w moim projekcie. Tylko ja na 50Ms/s. Ale inny target więc nie jesteśmy konkurencją :) ATSD jaki przetwornik? Coś z serii LTC22xx?

Reply to
Mario

W dniu niedziela, 27 lipca 2014 20:41:16 UTC+2 użytkownik Mario napisał:

AD9272

Reply to
stchebel

W dniu 2014-07-26 22:21, snipped-for-privacy@gmail.com pisze:

Może być też tak że wszystko się cacy programuje, za to ze wstawaniem interesu masz problem. Bo a to zasilanie gdzieś jeszcze nie wstało a to gdzieś inicjalizacja nie przeszła. A może sygnały nie zsynchronizowane gdzieś zapodajesz.

Skutek może być właśnie taki że idzie w krzaki. Czy się dobrze programuje to już chyba sprawdziłeś. Resztę koledzy już napisali.

Adam

Reply to
Adam Górski

W dniu poniedziałek, 28 lipca 2014 00:34:58 UTC+2 użytkownik Adam Górski napisał:

A jednak coś nie tak u mnie z impactem. Kolega Mario wygenerował mi mcs'a i wszystko jest OK.

Reply to
stchebel

W dniu 2014-07-28 00:25, snipped-for-privacy@gmail.com pisze:

8 kanałowy nieźle. I cena niezła.
Reply to
Mario

W dniu 28.07.2014 01:05, snipped-for-privacy@gmail.com pisze:

Cieszę się, że mogłem pomóc. Sam możesz sobie generować mcs wsadowo. Promgen istnieje w wersji dla windowsa i linuksa. Wrzuć sobie do foldera projektu skrypt z zawartością: #!/bin/bash rm a_costam.mcs rm a_costam.prm rm a_costam.cfi /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/promgen -p mcs -x xcf16p -u 00 a_costam -o a_costam.mcs

Oczywiście ścieżkę do promgen wpisz swoją. W przypadku windowsowego pliku bat usuń pierwszą linię - tę #!...., no i zamień rm na del. Usuwanie plików nie jest konieczne bo promgen nadpisze, ale masz pewność, że na pewno nie masz poprzedniej wersji gdy np. promgen wyszedł z błędem.

Reply to
Mario

A pdf do niego się zaczyna: "The AD9272 is designed for low cost...". Widać to zdanie to taki zaklinacz rzeczywistości, jest w każdym pdfie, u każdego producenta.

Reply to
Marek

W dniu 2014-07-28 02:11, Mario pisze:

Mam wrażenie że z narzędziami od X ciągle są jakieś jaja ( przynajmniej z tymi darmowymi ) Wnioskuje na podstawie tego co ludzie piszą w inecie ( zwykle używam A ).

Jako że sam z X korzystałem ostatnio z 12 - 14 lat temu, możesz napisać jak to jest obecnie z narzędziami od X ?

Adam

Reply to
Adam Górski

W dniu 29.07.2014 00:05, Adam Górski pisze:

Zajmuję się tym z doskoku. Nie mam skali porównawczej, bo nie robiłem nic w środowisku od Altery. Z jednej strony podoba mi się bo przy błędach kompilacji dostaję linki do opisów takich błędów z wyjaśnieniem na stronach X czy na forach. Czyli dość dobre wsparcie. Z drugiej strony wersja windowa nie pracuje z W 8.1 ( no dobra da się uruchomić ale pracuje niestabilnie), a linuksowa ma pewne problemy z Impactem opisywane już przeze mnie. Obcy interfejs (Digilent) jest automatycznie wykrywany i pod win i lin - nie trzeba instalować sterowników. Z drugiej strony obecność tego interfejsu uniemożliwia otworzenie zapisanej konfiguracji programu do programowania PROMu. Trzeba trochę pokombinować. W sumie to według mnie typówka jeśli chodzi o środowisko deweloperskie uzyskiwane za darmo. Pamiętam podobnie było z AVRStudio. Tez trzeba było kombinować z nieoryginalnym kabelkiem, czy z podpięciem gcc. Czy zrobienie toolchaina dla ARMów. Nie ma co grymasić trochę wysiłku i przy pomocy darmowych narzędzi można robić całkiem przyzwoite projekty.

Gdybym zajmował się profesjonalnie programowaniem pod FPGA i kupiłbym komercyjną wersję wraz z firmowym kabelkiem to niektórych problemów by nie było. Mimo wszystko z pracy ISE 14.7 na Linuksie 64 jestem zadowolony. Jest stabilny, pracuje szybko, a wspomniane problemy ominąłem korzystając z uruchamiania niektórych narzędzi wsadowo.

Reply to
Mario

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.