Witam Robie urzadzenie na CPLD Altery (MAX 2), korzystam z Quartusa, wszystko pisane glownie w VHDLu. Urzadzonko ma byc takim prostym oscyloskopem, CPLD obsluguje 2 przetw AC (SPI), pamiec statyczna RAM i wysyla dane do PCta przez USB (konwerter FTDI). Projekt jest zbudowany w postaci kilku Block Toolow - kazdy obsluguje co innego (SPI, RAM, FTDI) i jest pisany w VHDLU z wykorzystaniem instrukcji process (aby wykonywac instrukcje sekwencyjne). Oddzielnie bloki testowalem i dzialaja ok. Schody pojawiaja sie przy skladaniu tego wszystkiego w calosc - miedzy blokami jest sporo sygnalow laczacych jeden z drugim w celu kontroli ich dzialania, wszystko robi sie coraz bardziej zagmatwane i trudne w opanowaniu. Rezultat na razie jest taki ze ukald dziala ale sa pewne bledy i 'losowo' pojawiajace sie dziwne rzeczy z ktorymi nie moge dac sobie rady. Stad pytanie : czym kierowac sie przy budowie takiego projektu - tzn jak najlepiej to napisac, probowac polaczyc wszystkie procesy do jednego bloku, czy moze wykorzystac funkcje czy cos jeszcze innego ?
O - jeszcze jeden :) Ja niedawno zakonczylem bardzo podobny projekt - chipy rodziny MAX7000 - kilka bo nie udalo mi sie kupic "duzych i szybkich" ram wypruty ze starej plyty 386 (cache), FTDI+piv16f627 do komunikacji z PC, ADS831 jako ADC.
Jakbym czytal o swoim oscyloskopie :)
Proponowalbym zrobienie pewnej liczby jednostek (entity) realizujacych potrzebne ci funkcje - np. kontroler RAM, jednostka sterujaca komunikacj, glowna jednostak strujaca, ich dokladne przetestowanie i "zlozenie" w oscyloskop - dzieki temu podczas testowania bedziesz mial mniej sygnalow do obserwacji (np. podczas testowania modulu "oscyloskop" nie bedziesz musial analizowac wewnetrznych syglanow kontrolera RAM)
Pare rzeczy ktore zapamietalem z wlasnych "bojow" -
1) czytelne i precyzyjne nazwy sygnalow i jednostek to podstawa
2) kazda jednostke nalezy przetestowac a "wklikiwanie" sekwencji wymuszajacych w edytorze sygnalow szybko przestaje byc zabawne - rozsadnie jest wiec do kazdej jednostki dodac testbencha, nawet jesli jego jedyna funkcja jest wygenerowanie sygalnow sterujacych - zarezerwuj w nim troche miejsca na wymuszenia typu "ale takie cos napewno sie tutj nie pojawi"
3) male jednostki sa mile :)
4) duze jednostki skladaj z malych - po ich dokladnym przetestowaniu - i staraj sie zminimalizowac ilosc sygnalow w jednostce - ulatwi ci to zycie podczas testowania
5) zrob "symulatory" urzadzen zewnetrznych (ramu, przetwornika ADC, jednostki komunikacyjnej) i przetestuj symulacje kompletnego urzadzenia (lub bloku - np. w testbenchu kontrolera ram "podlacz" do niego behawioralny model twojej pamieci)
6) zrealizowanie poprawnej komunikacji pomiedzy blokami pracujacymi z roznymi zegarami nie jest tak proste jakby sie na pierwszy rzut oka wydawalo a bledy w takich modulach ciezkie do zidentyfikowania - wszystkie takie miejsca testuj dwa razy dokladniej
I jescze ostrzezenie na koniec - moj "oscyloskop" nie jest specjalnie uzyteczny - ze wzgledu na mala czestosliowsc probkowania, dlugi czas "przeladowywania" danych z bufora do PC i wiele innych drazniacych drobiazgow o ktorych zapomnialem/nie pomyslalem a ktore w gotowym sprzecie nie wystepuja - wiec jesli budujesz swoj osc. bo potrzebujesz go do pracy/zabawy przemysl zakup gotowego - a jesli traktujesz go jako projekt "naukowy" - coz, zycze dobrej zabawy :)
Nie do konca rozumiem jak wykonac to co proponujesz. Do tej pory mam plik schematowy (bdf) na ktorym mam bloki do poszczegolnych zadan : adc, ram, ftdi. Kazdy blok opisuje plik VHDL. Bloki polaczone sa pojedynczymi 'przewodami' lub magistralami. Problem bardziej tkwi w tym jak je przetestowac dobrze, np. bez pozostalych blokow przetestowanie przetw ac wydaje mi sie niemozliwe bez jakiegos analizatora stanow logicznych. Aktualnie mam problem wlasnie z ADC bo nie zawsze sie wyzwala chyba przez co rozjezdzaja mi sie czasy miedzy probkami.
Na razie znalazlem tylko w menu Processing/Start/Start Test Bench Template Writer co wygenerowalo mi plik vht dla projektu. Co z tym zrobic dalej niestety nie wiem :/
Jest to glownie projekt naukowy, probkowanie max tylko 400 kHz, wielkosc bufora jest na tyle mala ze odswierzanie obrazu na kompie jest w miare wystarczajace, do prostych zastosowan jest ok. trzeba tylko wyeliminowac obecne bledy :)
Moze niezbyt precyzyjnie to opisalem wczesniej ale tak wlasnie mam to zrobione. Na schemacie sa bloki obslugujace poszczegolne uklady, polaczone sa przewodami i magistralami. Kazdy blok opisuje oddzielny plik VHDL. Problem sprowadza sie bardziej do tego ze niektore bloki dzialaja dziwnie/ inaczej niz wynikaloby z analizy programu.
I kazdy z nich jest jednostka (entity) - mozesz te jednostki skladac do kupy przy pomocy edytora schematow (tak jak teraz to robisz) mozesz je skladac uzywajac ich jako elementow skladowych (component) innych jednostek opisanych w VHDL.
Quartus ma taki "analizator" - wprawdzie pozwala symulowac tylko "zaimplemenotwane" bloki wiec nie da sie uzywac wielu rzeczy (np. zasymulowac przetwornika AC) ale do sprawdzania timingow jest bardzo dobry. Do testowania na wyzszym poziomie potrzebujesz symulatora VHDL np. ModelSim - niestety altera nie udostepnia go za darmo. Mozesz go zciagnac ze strony Xilinxa - niestety w takiej kombinacji najprawdopodbniej nie bedziesz mogl uzywac plikow generowanych przez edytor schematow quartusa (wszystko trzeba bedzie przepisac w VHDL) i "firmowych" bloczkow altery. Jesli jednak uzywasz tylko biblioteki ieee nie powinienes miec zadnych roblemow
Znaczy pozwlasz sie prowadzic kreatorowi... Testbech to - w uproszczeniu - jednostka zawierajaca testowany komponent i zrudla sygnalow wymuszajacych - przy czym taki testbench nie musi byc implementowalny wiec przy definiowaniu sygnalow sterujacych mozna uzywac opisu behawioralnego (dozwolne sa opoznienia itp. nierealizowalne w hardware elementy). Jako pomoc naukowa polecam ksiazke "Projektowanie układów cyfrowych z wykorzystaniem języka VHDL" Mark Zwoliński.
A porzadny wzmacniacz wejsciowy (i tlumik) juz masz? Ja go sobie zostawilem na koniec jako "bulka z maslem" a tu sie okazalo ze analogowka potrafi naprawde paskudne rzeczy wyrabiac... Przy jego konstrukcji tez sie sporo nauczylem - glownie "jak sie takich rzeczy nie robi" :) Przy okazji - pisales ze gubia ci sie probki - jestes pewny ze znikaja na polaczneiu ADC-RAM? Jeden z problemow ktory solidnie dal mi w kosc objawial sie "znikaniem" czesci probek - z 32kB bufora ginelo zwykle
100 do 1000 probek - okazalo sie ze problem lezy we wspolpracy z modulem obslugujacym FTDI - jego zegar jest asynchroniczny w stosunku do zegara reszty ukladu (duzo wolniejszy - zrobilem go na mikrokontrolerze) i dopoki solidnie tego bloczka nie przeprojektowalem czesto sie zdazalo ze oscyloskop byl przekonany ze probka juz zostala wyslana a modol komunikacyjny nic o niej nie wiedzial. Najbardziej denerwujace bylo to ze nigdy nie udalo mi sie uzyskac bledu w symulacji
Taka zabawa wydaje mi sie zbyt daleko posunieta komplikacja :) ale kto wie moze sprobuje.
No cos tam na wejsciu jest :) Jak na razie to w jednym kanale leca jakies smieci wysokiej czestotliowsci (szpilki jakby), co ciekawe w drugim nic takiego nie ma chociaz maja odentyczna budowe :)
To juz sprawdzilem, pecet odbiera zawsze tyle probek ile czytam z RAMU - tutaj chyba przydaje sie bufor w FT245R i wogole fajnie rozwiazana magistrala FIFO.
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.