Elektroda.pl
Elektroda.pl
X
Mierniki instalacji Metrel
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt

piotrva 24 Cze 2013 15:39 21492 30
  • Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt

    Witam Koleżanki i Kolegów!
    Jak zwykle projekty, które prezentuję tak i ten w stylu pająka - bo projekt prototypowy.

    Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt
    Na zdjęciu od lewej: Zestaw LCMXO2-7000HE-B-EVN wykorzystywany jako programator, płytka prototypowa z układem MachXO2-256 na przejściówce DIP, płytka EvB5.1 firmy And-Tech z procesorem ATMega644p i wyświetlaczem LED

    Ale do rzeczy:

    0. Co to jest
    Układ zaimplementowany w kostce MachXO2-256 to sprzętowy sterownik wyświetlacza LED. Przesyłamy do niego za pomocą interfejsu SPI dane, które mają być wyświetlane, a układ zajmuje się ich konwersją na odpowiednie wzory liczb, a co najważniejsze multipleksowaniem tychże wyświetlaczy.

    Oczywiście wiadomo, że można by zrobić to wszystko dysponując zasobami mikrokontrolera, ale nie o to tu chodzi. Po pierwsze projekt ten ma zademonstrować działanie układów FPGA, po drugie zaś dzięki takiemu układowi procesor w ogóle nie musi zajmować się obsługą wyświetlaczy - po prostu wysyła dane do układu i one są wyświetlane.


    1. Od czego się zaczęło
    Jakieś pół roku temu Kolega @leonw32 zaprezentował na łamach forum projekt generatora DDS na stosunkowo tanim układzie FPGA: https://www.elektroda.pl/rtvforum/topic2499889.html..
    Jako że od zawsze interesowały mnie takie zagadnienia, jednakże nigdy nie było wystarczająco dużo czasu i funduszy na jakiś duży zestaw FPGA, zobaczywszy serię układów MachXO2 pomyślałem, że to coś dla mnie. W końcu stałem się posiadaczem zestawu LCMXO2-7000HE-B-EVN (cena ok. 200zł), a potem kostek MachXO2-256 na adapterach DIP (wykonane przez @leonw32).
    Po prostych konstrukcjach typu liczniki chciałem wreszcie wykonać jakiś praktyczny układ i w pierwszej kolejności wybór padł na driver do multipleksowanych wyświetlaczy 7-segmentowych

    2. Szczypta teorii o FPGA
    W wielkim skrócie i uproszczeniu układy FPGA to struktury umożliwiające odwzorowanie niemalże dowolnego układu logicznego. Są one dużo szybsze niż mikrokontrolery (opóźnienia wynikają jedynie z czasu propagacji sygnału wewnątrz układu), a takze mogą wykonywać operacje zupełnie asynchronicznie, a nie tylko, tak jak procesor, sekwencyjnie.




    Po większą dawkę bardziej szczegółowej teorii zapraszam na stronę: http://leon-instruments.blogspot.com/2012/10/ukady-programowalne.html

    3. Pierwsze problemy
    Pierwsze problemy z układem miałem już po samym jego otrzymaniu.
    Po podłączeniu wszystkich pinów zasilania, oraz programatora (opartego o układ FT2232H na płytce LCMXO2-7000HE-B-EVN) moim oczom ukazał się komunikat o permamentnym zabezpieczeniu układu przed przyszłym zapisem i odczytem... Po długich bojach, testach drugiego układu - nadal ten sam komunikat...
    A co było przyczyną?
    Zasilanie - jak się okazało te scalaczki są bardzo, ale to bardzo wrażliwe na warunki zasilania. Dodanie zgodnie z zaleceniami producenta kondensatorów na każdej nóżce VCC spowodowało, że problemy zniknęły jak za dotknięciem czarodziejskiej różdżki.
    Co ciekawe w czasie testów po dołożeniu kilku kondensatorów uzyskałem możliwość kasowania pamięci flash oraz zapisu programu "bezpośrednio" do obszaru konfiguracyjnego (pamięć SRAM), pomimo, że zapis do pamięci FLASH był niemożliwy. Stąd wniosek, że zapisywanie pamięci flash generuje dużo więcej zakłóceń zasilania niż praca układu i programowanie innych pamięci.

    Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt
    Na zdjęciu: Płytka prototypowa i widoczne kondensatory filtrujące zasilanie układu MachXO2-256

    4. Programator
    Co do programatora - nie musimy wcale inwestować w bardzo drogi sprzęt - wystarczy standardowa przejściówka z układem FT2232H o odpowiedniej konfiguracji i możemy zaczynać pracę.
    Można także, podobnie jak ja, wykorzystać układ z płytki ewaluacyjnej - wystarczy tylko wgrać do układu MachXO2-7000 program zawierający konfigurację dezaktywującą interfejs JTAG w tym układzie (komunikację przywracamy zwierając pin JTAGENB do zasilania na czas kolejnego przeprogramowania układu na głównej płytce testowej).
    Szkoda tylko, że projektant płytki nie przewidział możliwości takiego połączenia układów, aby kolejne można było dołączać w konfiguracji daisy-chain i tym samym programować układ na płytce i zewnętrzne kości bez manipulacji blokadą interfejsu JTAG w głównym FPGA.

    Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt
    Na zdjęciu: Konfiguracja układu MachXO2-7000 wyłączająca interfejs JTAG i przekształcająca zestaw LCMXO2-7000HE-B-EVN w programator JTAG

    5. Płytka prototypowa
    Po wszystkich bojach ze stroną sprzętową wykonałem przedstawioną wcześniej płytkę prototypową. Płytka zawiera:
    a) złącze programatora JTAG zgodne pinowo ze złączem na zestawie LCMXO2-7000HE-B-EVN,
    b) 10 pinów zasilających (5x 3.3V, 5x GND),
    c) Podstawka do umieszczenia generatora kwarcowego z sygnałem doprowadzonym do pinu 4 układu MachXO2-256,
    d) Złącze do wpięcia układu MachXO2-256 na przejściówce DIP (wraz z doprowadzonym i odpowiednio odfiltrowanym zasilaniem)
    e) Wyprowadzenia wszystkich (poza zasilającymi) pinów układu

    Sterownik wyświetlaczy LED na układzie FPGA - miniprojekt
    Na zdjęciu: Płytka prototypowa z zamontowanym układem MachXO2-256

    6. Zasada działania
    a) Komunikacja
    Komunikacja odbywa się za pomocą interfejsu SPI, za pomoca którego urządzenie nadrzędne przesyła 3 bajty (w moim przypadku wykorzystałem mikrokontroler rodziny AVR - ATMega644p - taki był pod ręką i na płytce ze zgrabnie podłączonym wyświetlaczem LED). Dwa z nich reprezentują 16-bitową liczbę do wyświetlenia na wyświetlaczach w formie heksadecymalnej (stąd liczby dziesiętne trzeba przekształcić na format BCD), zaś trzeci bajt to bajt konfiguracyjny. Jego 4 starsze bity służą do włączania bądź wyłączania poszczególnych cyfr, zaś 4 młodsze pozwalają na zapalanie w dowolnej konfiguracji kropek.
    Dane są zatrzaskiwane na zboczu narastającym pinu CS - podobnie jak w popularnych układach 74xx595 (tam jest to pin LATCH).
    b) Wyświetlanie
    Tu właściwie nie ma co się rozpisywać - układ na podstawie danych przesłanych interfejsem SPI i zatrzaśniętych na zatrzasku wyjściowym wyświetla je na wyświetlaczach w trybie multipleksowanym z częstotliwością około 240Hz. Układ korzysta z wewnętrznego oscylatora i nie wymaga zewnętrznych źródeł sygnału zegarowego. Dane liczbowe są oczywiście dekodowane na kody odpowiednich znaków.

    7. Podziękowania
    Chciałbym podziękować:
    Koledze @leonw32, który wciągnął mnie w tę dziedzinę elektroniki cyfrowej, a także udzielił wielkiej pomocy w czasie uruchamiania układów oraz dał mi wiele wskazówek, a co najważniejsze wykonał adaptery DIP dla układów MachXO2-256. http://leon-instruments.blogspot.com/
    Kolegom pomocnym w temacie dot. budowy modułu SPI, którzy oprócz odpowiedzi na pytania udzielali także wskazówek na przyszłość.

    8. Kody
    W załączniku pliki zawierające:
    a) Projekt programu Lattice Diamond dla układu MachXO2-256, opisujący w języku Verilog nasz sterownik wyświetlacza.
    b) Projekt AVR Studio 4.18 z programem w języku C, który kontroluje pracę wyświetlecza w celach demonstracyjnych.

    Cóż, chyba na razie nic więcej nie mogę dodać. Oczekuję na konstruktywną krytykę oraz pytania, na które w miare posiadanej wiedzy na ten temat (a muszę przyznać, że raczkuję w tej dziedzinie) odpowiem.


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • Mierniki instalacji Metrel
  • #2 24 Cze 2013 18:50
    Mariano5
    Poziom 11  

    piotrva napisał:
    Dopisałem na początku dokładne wyjaśnienie co to jest:

    W opisie zaznaczyłeś także napotkane trudności. Ciekaw jestem, czy ten Twój układ z opisywaną filtracją nie wykrzaczył by się w moim przypadku z którym walczę od kilku dni. (w samym sterowniku oprócz kondensatorów, transili, szybkich diod, programowych zwłok stosuję zewnętrzne ograniczniki, i nadal jest siara)

    Z tak wrażliwym układem, to chyba musiał byś zastosować klatkę Faradaja gzie komunikacja, oraz zasilanie odbywa się przy pomocy wiązki laserowej. :D

  • Mierniki instalacji Metrel
  • #3 24 Cze 2013 19:28
    piotrva
    Moderator na urlopie...

    Mariano5 napisał:
    Z tak wrażliwym układem, to chyba musiał byś zastosować klatkę Faradaja gzie komunikacja, oraz zasilanie odbywa się przy pomocy wiązki laserowej.

    Cóż, gdyby układ był montowany od razu na odpowiednio zaprojektowanej płytce PCB, a nie na pająka, myślę, że takich problemów by nie było.
    Obecnie całość leży sobie (i działa) 5cm od kabla 230VAC zasilającego komputer ;)

  • #4 24 Cze 2013 19:41
    Mariano5
    Poziom 11  

    Cytat:
    Cóż, gdyby układ był montowany od razu na odpowiednio zaprojektowanej płytce PCB, a nie na pająka, myślę, że takich problemów by nie było.
    Obecnie całość leży sobie (i działa) 5cm od kabla 230VAC zasilającego komputer


    A to teraz wyobraź sobie sterownik gdzie Ci się wszystkie przewody przeplatają w korytkach.
    Do tego wszelkie przepięcia pochodzą z indukcyjnych urządzeń zewnętrznych zasilanych z sieci trójfazowej. I co ty na to? W moim sterowniku który jest znacznie bardziej odporny na impulsy elektromagnetyczne zastosowałem klatkę Faradaja (jest o wiele lepiej, ale jeszcze zdarzają się błędy. )

  • #6 24 Cze 2013 20:20
    piotrva
    Moderator na urlopie...

    piotrva napisał:
    nie o to tu chodzi. Po pierwsze projekt ten ma zademonstrować działanie układów FPGA

    Wiadomo, że można kupić gotowy układ, można to zrobić na samym mikrokontrolerze, którego zasoby nawet nie odczują takiego wyświetlacza, ale jak napisałem - chodzi o nauczenie się czegoś i zaprezentowanie możliwości małych i tanich układów FPGA.

  • #7 24 Cze 2013 20:35
    Mariano5
    Poziom 11  

    piotrva napisał:
    Wiadomo, że można kupić gotowy układ, można to zrobić na samym mikrokontrolerze, którego zasoby nawet nie odczują takiego wyświetlacza, ale jak napisałem - chodzi o nauczenie się czegoś i zaprezentowanie możliwości małych i tanich układów FPGA.


    Ale te małe układy FPGA w porównaniu do mikro-kontrolerów nie są też aż takie tanie... (niestety)
    Do tego kolega wspomniał o napotkanych problemach. A więc jak z funkcjonalnością ?

  • #8 24 Cze 2013 22:32
    piotrva
    Moderator na urlopie...

    Proponuję zakończyć ten jakże rozwijający dyskusję off-topic dot. zakłóceń.
    Moje pierwsze podłączenia prototypowe na pająka były NIEZGODNE z zaleceniami producenta. To samo dzieje się choćby z procesorami AVR - też jak źle podłączymy to dzieją się dziwne rzeczy (niekontrolowane resety, wariacje podczas programowania, zamazanie sygnatury, przypadkowe ustawienia fusebitów itp. - piszę z własnego doświadczenia).
    Jak już mówiłem, w tej chwili układ jest podłączony zgodnie z zaleceniami producenta i typowe zakłócenia (GSM, 230VAC, Bluetooth, WiFi) go nie ruszają. Pewnie przy zakłóceniach indukcyjnych należałoby bardzo precyzyjnie odizolować ich źródło i odpowiednio rozplanować zasilanie oraz ekranowanie, ale problem dotyczyłby wtedy nie tylko układu FPGA, ale także choćby procesora AVR i innych układów cyfrowych.

    Co do ceny - owszem, są droższe, ale na uC w podobnej cenie wielu rzeczy nie zrobisz. Nawet biorąc pod uwagę procesory z wyższej półki skomplikowania - typu ARM-STM32 - ciężko będzie znaleźć coś, co przepuści Ci sygnał o częstotliwości ok. 250MHz
    Aktualnie właśnie robię programowalny dzielnik częstotliwości.
    Tak, wiem, też można kupić za 5zł gotowy scalak, tak wiem, skoro raz miałem problemy z zasilaniem to pewnie nie jest możliwa stabilna praca na odpowiedniej PCB - w końcu wiadomo, że firma Lattice wypuszcza buble.
    Dla porównania, skoro Kolega tak o tych niedogodnościach z zasilaniem mówi, sprawdzał Kolega jakie warunki zasilania mają inne FPGA?
    Polecam zajrzeć choćby tu: http://www.digilentinc.com/Data/Products/S3BOARD/S3BOARD_RM.pdf (strona 59)

    PS. Gratuluję 100 postów i projektu stworzonego w środowisku graficznym ;)

  • #9 25 Cze 2013 00:27
    leonow32

    Poziom 30  

    Panowie koledzy! Jak zostało w pierwszym poście zaznaczone - ten układ powstał w celach TESTOWYCH, dzięki czemu autor tematu nauczył się poprawnie łączyć zasilanie, co jest bardzo często bagatelizowane przez (przemądrzałych) domorosłych konstruktorów. W tym temacie została zademonstrowana współpraca procesora z FPGA, co w profesjonalnych konstrukcjach zdarza się bardzo często, zwłaszcza w projektach trochę bardziej złożonych ;) Główną zaletą FPGA w powiązaniu z procesorem jest to, że w ten sposób można sobie zrobić WŁASNE peryferia, szyte na miarę potrzeb. Jeśli te potrzeby się zmienią (bo klient sobie wymyśli jakieś inne widzimisie) to bez najmniejszego problemu można owe peryferia zmienić tak łatwo jak kod programu do procka, a w przypadku stosowania ASICów trzeba by znaleźć inne scalaki i na nowo projektować płytkę. Nie ma co porównywać FPGA do procesorów, bo to jest zupełnie inna bajka i do innych celów te układy zostały stworzone! Natomiast to, że prezentowane tutaj zastosowanie jest trywialne - to przecież oczywiste! Od czego innego autor miałby zacząć naukę FPGA? :)

    Porównując z innymi FPGA, scalaczek MachXO2 jest najłatwiejszy i najtańszy! Do zasilania wymaga jedynie napięcia 3,3V i nie potrzebuje żadnych innych napięć. Do tego parę kondensatorów i śmiga aż do 323MHz. Kosztuje 12zł, a ma wbudowaną pamięć stałą, generator (czyli żadnych dodatkowych kosztów) i przede wszystkim występuje w obudowie, którą można ręcznie przylutować bez zaawansowanego sprzętu ani laminatu 10-warstwowego ;) programator da się zrobić na FT2232, a oprogramowanie Diamond jest darmowe również do celów komercyjnych. Doskonała rzecz dla początkujących w temacie FPGA :)

  • #10 25 Cze 2013 01:52
    lelekx
    Poziom 29  

    Bardzo fajnie, że takie projekciki się pojawiają na Elektrodzie - miło że ktoś się stara pokazać, FPGA nie gryzą. Wiele rzeczy da się zrobić wyłącznie na mikrokontrolerze, ale tam gdzie się MCU nie wyrabia jest miejsce do popisu dla logiki programowalnej.

    Pozdrawiam wszystkich zrzędzących :)

  • #11 25 Cze 2013 16:43
    Mariano5
    Poziom 11  

    piotrva napisał:
    PS. Gratuluję 100 postów i projektu stworzonego w środowisku graficznym


    To co pokazuję publicznie nie świadczy o ilości wykonanych projektów.
    Co do zakłóceń, to jest sprawą oczywistą iż, owe zjawisko dotyczy również AVR-ów, w przeciwnym razie nie pisał bym o podjętych środkach zapobiegawczych.

    Tak po za tematem, to mogę powiedzieć tyle że jeśli mowa o AVR-ach, to sam montaż oraz dobroć zasilania jest zaledwie wierzchołkiem góry lodowej. (AVR-y są strasznie wrażliwe na fale elektromagnetyczne. np. uderzenie impulsu w trakcie rozruchu maszyny indukcyjnej)

  • #12 26 Cze 2013 01:13
    folkien
    Poziom 11  

    W pliku SPI.v masz

    Kod: verilog
    Zaloguj się, aby zobaczyć kod


    Jesteś pewien, że to dobre rowiązanie? To ci stworzy przerzutnik taktowany ChipSelectem, tymczasem ChipSelect to nie jest sygnal zegarowy. W tym projekcie to raczej bez znaczenia, ale nie powinno sie tworzyc dodatkowych/sztucznych zegarow. Raz, że nie masz w FPGA tyle buforów globalnych, żeby przenosić wszystkie dodatkowe sygnał zegarowe, a dwa że przez to, pojawi ci się hazard i nierównomierne załączanie przerzutników.

    Profesjonalnie możesz to zrobić pipeline'ując ChipSelect, najlepiej dwa razy , wtedy uzyskasz sygnał równy okresowi zegara - oraz używając jednej bramki nand. Wystarczy ze z clockiem zegara, przepiszesz
    Kod: vhdl
    Zaloguj się, aby zobaczyć kod

    i teraz juz wystarczy sprawdzic czy cs_rising_edge == 1?

    Edit : Poprawiłem ostatnia linijke :) thx za uwagę :)

  • #13 26 Cze 2013 15:38
    piotrva
    Moderator na urlopie...

    folkien napisał:
    Jesteś pewien, że to dobre rowiązanie?

    Gdybym był nie napisałbym:
    piotrva napisał:
    muszę przyznać, że raczkuję w tej dziedzinie

    Jak tylko przetestuję to pokażę ostateczny kod modułu SPI.

    Dodano po 41 [minuty]:

    Pomijając, że Kol. @folkien pomylił zbocza w ostatnim wyrażeniu, całość działa.
    W tej chwili moduł SPI wygląda tak:
    Kod: verilog
    Zaloguj się, aby zobaczyć kod

    Oczywiście do wyprowadzenia sync_clk należy doprowadzić odpowiednio szybki sygnał zegarowy.

    Także dziękuję za merytoryczną uwagę, cenną sugestię i wartościową wypowiedź.

  • #14 26 Cze 2013 16:18
    folkien
    Poziom 11  

    :) Tak gwoli jeszcze ścisłości jeżeli masz taki kod

    Kod: verilog
    Zaloguj się, aby zobaczyć kod

    to istnieje prawdopodobieństwo stworzenia Latch'a czyli przerzutnika reagującego nie na zbocze, ale na stan logiczny - ogolnie laczy sie unika, opozniają propagację sygnałów w chipie. Tutaj cię ratuje to, że masz powyżej posedge od CLK i być może zrobi z tego multiplexer lub jakaś logikę - musiałbyś zsyntezować i zobaczyć jak wygląda RTL - ale bardzo bardzo dobrą zasadą jest dla każdego if'a od stanu logicznego, pisanie else.
    np.
    Kod: verilog
    Zaloguj się, aby zobaczyć kod

    Powyższy kod jest czytelniejszy i jak widać daje multiplexer, sterowany sygnałem cs_rising_edge, którego wyjście jest zatrzaskiwane z zegarem do data.

    Ja też zawsze daje jako wejście do układu sygnał RESET, którego potem używam do resetowania CHIP'a. Myślę że to dobra praktyka, szczególnie że większość przerzutników w FPGA ma ten reset wbudowany - zależnie od architektury, synchroniczny lub asynchroniczny.

  • #16 27 Cze 2013 21:29
    olinek2
    Poziom 23  

    Ma ktoś doświadczenie jak MACHXO2 się odnoszą np. do Spartanów, czy trzeba dużo zmieniać kodu, żeby przeportować sobie kod na owe scalaczki :) ? Czy syntezery łapią VHDL'a czy tylko Verilog ?

    Jak układy spisują się przy zegarach dochodzących do 300MHz i czy mógłby mi ktoś nakreślić jak cenowo to wygląda w stosunku do np. odpowiadającego mu Spartana :). Z góry dzięki ;)

  • #17 27 Cze 2013 21:48
    leonow32

    Poziom 30  

    Nie ma "odpowiadającego Spratana" :P z założenia MachXO2 to układy low-costowe do prostych aplikacji, a Spartany to zdecydowanie większy kaliber :)

    Diamond łyka również VHDL i IPexpress generuje kody w obu językach. Tutaj jest krótki przegląd tego środowiska
    http://leon-instruments.blogspot.com/2013/04/lattice-diamond.html

    Tu jest ciekawa prezentacja o zastosowaniach małych FPGA
    http://www.latticesemi.com/documents/I0222.pdf

  • #18 27 Cze 2013 22:51
    piotrva
    Moderator na urlopie...

    Dodam, że do syntezy mamy do wyboru (zarówno z VHDL jak i Verilog) 2 narzędzia wbudowane: Lattice LSE i Synplify Pro - oba działają nieco inaczej i generują różne struktury wynikowe.
    Na razie nie sprawdzałem nic w granicach 300MHz, ale u mnie 133MHz łyknął bez problemu podczas prostych testów (bardzo prostych - bardziej zaawansowanych rzeczy wysokoczęstotliwościowych jeszcze nie robiłem).

  • #19 27 Cze 2013 23:36
    folkien
    Poziom 11  

    Cała kwestia zależy od tego jak duży jest twój projekt. Syntezując napisany układ otrzymasz wyniki ile zajmie on przerzutników, bramek, LUT'ów, DCM'ów, BlockRamów itd. Tak jak już wyżej napisano, jeżeli MachXO2 to małe FPGA, to prawdopodnie kod pisany na ten układ pojdzie na praktycznie każdym spartanie.

    Dla rodziny Spartan 3 w tym www.xilinx.com/support/documentation/data_sheets/ds099.pdf pdfie na stronie 2-giej jest krótkie porównanie proponowanych układ. Można tam podejrzeć ilość bloków mnożących, DCM'ów czy LUT'ów.

    Koniec końców, środowisko Webpack ISE jest darmowe, więc najlepiej ściągnąć, stworzyć projekt, zaimportować kod i spróbować zsyntezować oraz przeprowadzić Place&Route'a, w wybranym przez siebie układzie:) Jak się nie zmieści to otrzymasz stosowną informację :)

    ISE czyta VHDL jak i Veriloga. Schematy też jak najbardziej :) co do taktowania to pamiętaj, że tak jak zaprojektujesz układ, takiego będziesz mógł użyć zegara. ISE wyliczy ci z syntezy czy P&R maksymalną częstotliwość zegara dla danego Design'u, ale żeby być dokładnym warto dodać constrainty czasowe, w których zdefiniujesz zakładaną przez ciebie częstotę taktowania. :)

  • #20 27 Cze 2013 23:45
    piotrva
    Moderator na urlopie...

    Swoją drogą przy dalszych eksperymentach z SPI (tym razem robiłem rejestr parallel in serial out) zauważyłem, że dane powinny być przecież wystawiane na miso na zboczu opadającym SCK, a próbkowane z mosi na zboczu narastającym - a w moim designie jest to zrealizowane błędnie.

  • #21 28 Cze 2013 00:07
    olinek2
    Poziom 23  

    Nie no na WebPacku mam gotowy wsadzik już działający na Spartanie3 :) wykorzystuję jakieś 25-30% 200tys. wersji :) Zegar mam tam na 250MHz, choć podejmowałem próby z 300MHz i działał pięknie ;)
    Pytałem z ciekawości, bo w sumie siedziałem jedynie na Spartanach trochę robiąc jeden lekko komercyjny,konkretniejszy projekt (z dużymi wymogami czasowymi głównie - wchodziły w grę już czasy propagacji układu i parę innych dupereli :)).

  • #23 28 Cze 2013 10:47
    michal.bedzin
    Poziom 15  

    A jaką część twojego układu zajmuje twój moduł? Zastanawiam się trochę nad tymi układami, ale zastanawiam czy je ugryźć :D 7000 LUTów to nie jest wcale tak mało, jak na przeciętne potrzeby z układami programowalnymi.

  • #24 28 Cze 2013 11:08
    olinek2
    Poziom 23  

    U mnie 707 4ro wejściowych LUTów :)

  • #25 28 Cze 2013 11:18
    michal.bedzin
    Poziom 15  

    Tak, ale ty mówisz o Spartanie :P A mnie interesują osiągi tego narzędzia od Lattice (tak wiem mogę sobie ściągnąć i przesyntezować układ, ale wolę się po prostu zapytać :D )

  • #26 28 Cze 2013 21:13
    piotrva
    Moderator na urlopie...

    Raport z mapowania projektu:

    Code:

    Design Summary
       Number of registers:    79
          PFU registers:    66
          PIO registers:    13
       Number of SLICEs:            40 out of   128 (31%)
          SLICEs(logic/ROM):        32 out of    32 (100%)
          SLICEs(logic/ROM/RAM):     8 out of    96 (8%)
              As RAM:            0 out of    96 (0%)
              As Logic/ROM:      8 out of    96 (8%)
       Number of logic LUT4s:      26
       Number of distributed RAM:   0 (0 LUT4s)
       Number of ripple logic:     17 (34 LUT4s)
       Number of shift registers:   0
       Total number of LUT4s:      60
       Number of PIO sites used: 16 out of 22 (73%)
       Number of block RAMs:  0 out of 0
       Number of GSRs:  0 out of 1 (0%)
       EFB used :       No
       JTAG used :      No
       Readback used :  No
       Oscillator used :  Yes
       Startup used :   No
       POR :            On
       Bandgap :        On
       Number of Power Controller:  0 out of 1 (0%)
       Number of Dynamic Bank Controller (BCINRD):  0 out of 4 (0%)
       Number of DCCA:  0 out of 8 (0%)
       Number of DCMA:  0 out of 2 (0%)

  • #27 30 Cze 2013 00:10
    piotrva
    Moderator na urlopie...

    piotrva napisał:
    Swoją drogą przy dalszych eksperymentach z SPI (tym razem robiłem rejestr parallel in serial out) zauważyłem, że dane powinny być przecież wystawiane na miso na zboczu opadającym SCK, a próbkowane z mosi na zboczu narastającym - a w moim designie jest to zrealizowane błędnie.

    W związku z czym napisałem moduł SPI jeszcze nieco inaczej:
    Kod: verilog
    Zaloguj się, aby zobaczyć kod

  • #28 30 Cze 2013 10:46
    leonow32

    Poziom 30  

    Ciekawe jak działa SPI wbudowane w Embedded Function Block. Producent podaje, że dzięki temu można zaoszczędzić pełno zasobów, jakoś nie zdobyłem motywacji, by przekopać się przez dokumentację tego cuda :) jakoś to można wstawić też poprzez IPexpress.

    Tu są różne instrukcje na ten temat
    http://latticesemi.com/en/Products/FPGAandCPLD/MachXO2.aspx

  • #29 30 Cze 2013 17:56
    piotrva
    Moderator na urlopie...

    Staram się to rozgryźć właśnie - dostęp do tego modułu jest przez interfejs wishbone - coś jak rejestry przestrzeni IO w procesorze. Mamy szynę danych wejściowych, wyjściowych, linię adresową i sygnały sterujące.
    I najpierw należy podać odpowiednią konfigurację do rejestrów SPI (sekwencyjnie oczywiście), a potem sekwencyjnie wysyłać/odbierać dane z samych rejestrów SPI (w sumie bardzo podobnie jak w uC).
    No ale pierwsze trzeba to rozgryźć i ogarnąć samą komunikację poprzez ten interfejs - może po weekendzie znajdę na to czas.

  • #30 08 Lip 2013 23:14
    spider_mp3
    Poziom 9  

    Którego programatora najlepiej użyć?