VHDL + Quartus II - kilka pytan
Masz problem? Zapytaj na forum elektroda.pl
From: Shooter <shooter_at_nospam_bezspamu.op.pl>
Subject: VHDL + Quartus II - kilka pytan
Date: Sat, 22 Jul 2006 15:55:17 +0000 (UTC)
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 ?
--
Shooter
From: Gregor <pij_at_nospam_wiecej.piwa.a.nie.spamuj.pl>
Subject: VHDL + Quartus II - kilka pytan
Date: Sat, 22 Jul 2006 19:43:11 +0200
Shooter napisal:
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).
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.
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.
Jakbym czytal o swoim oscyloskopie :)
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 ?
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 :)
Pozdrawiam
GRG
From: Shooter <shooter_at_nospam_bezspamu.op.pl>
Subject: Re: VHDL + Quartus II - kilka pytan
Date: Sun, 23 Jul 2006 11:10:49 +0000 (UTC)
Gregor napisal :
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.
Widze ze temat stal sie ostatnio popularny :)
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)
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.
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"
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 :/
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 :)
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 :)
--
Shooter
From: smietniczek_at_nospam_chello.at
Subject: Re: VHDL + Quartus II - kilka pytan
Date: 23 Jul 2006 12:09:10 -0700
Shooter schrieb:
Gregor napisal :
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
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.
przetestowac dobrze, np. bez pozostalych blokow przetestowanie przetw ac
wydaje mi sie niemozliwe bez jakiegos analizatora stanow logicznych.
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
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 :/
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=B3ad=F3w cyfrowych z wykorzystaniem j=EAzyka
VHDL" Mark Zwoli=F1ski.
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 :)
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
GRG
From: Shooter <shooter_at_nospam_bezspamu.op.pl>
Subject: Re: VHDL + Quartus II - kilka pytan
Date: Mon, 24 Jul 2006 15:31:49 +0000 (UTC)
napisal :
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
Taka zabawa wydaje mi sie zbyt daleko posunieta komplikacja :) ale kto wie
moze sprobuje.
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" :)
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 :)
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 /ciach
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.
--
Shooter
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: Re: VHDL + Quartus II - kilka pytan
Date: Sat, 22 Jul 2006 16:22:00 -0500
"Shooter" <shooter_at_nospam_bezspamu.op.pl> wrote in message news:Xns9808B71F135EEshooteroppl_at_nospam_127.0.0.1...
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 ?
Moze powinienes polaczyc VHDL z wizualizacja na schemacie ?
To znaczy z kilkunastu malych plików VHDL porobic symbole
i potem uzywajac edytora schematów wrzucic na schemat te
symbole i dokonac polaczen juz metoda wizualna: druty i magistrale?
Wtedy wciaz bedziesz mógl detalami zajmowac sie w VHDL
a hierarchie miedzy modulami opanujesz latwiej "wizualnie".
From: Shooter <shooter_at_nospam_bezspamu.op.pl>
Subject: Re: VHDL + Quartus II - kilka pytan
Date: Sun, 23 Jul 2006 11:16:23 +0000 (UTC)
Pszemol napisal :
Moze powinienes polaczyc VHDL z wizualizacja na schemacie ?
To znaczy z kilkunastu malych plików VHDL porobic symbole
i potem uzywajac edytora schematów wrzucic na schemat te
symbole i dokonac polaczen juz metoda wizualna: druty i magistrale?
Wtedy wciaz bedziesz mógl detalami zajmowac sie w VHDL
a hierarchie miedzy modulami opanujesz latwiej "wizualnie".
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.
--
Shooter
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: Re: VHDL + Quartus II - kilka pytan
Date: Sun, 23 Jul 2006 23:26:50 -0500
"Shooter" <shooter_at_nospam_bezspamu.op.pl> wrote in message news:Xns980987D81458Fshooteroppl_at_nospam_127.0.0.1...
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.
Może nie wziąłeś pod uwagę, że VHDL nie w 100% daje się
realizować w bramkach logicznych ? To język stworzony do
symulacji a nie do projektowania układów logicznych...
Zrób tak - weź sobie taki bloczek który "dziwnie" działa,
ustaw dla niego że ma być "top level" - przekompiluj
i wleź do RTL-Viewer. Będziesz miał wgląd w to, jak
komputer "zrozumiał" ten Twój VHDL w postaci bramek i
flip-flopów. Funkcja takiego podglądu jest dostępna
zdaje się od wersji 5.0 więc jak masz nowego Quartusa
to pewnie ją masz... W ostateczności jeśli nie jesteś
w stanie znaleźć błedu w VHDL to zawsze możesz ten jeden
"dziwny" uklad zrealizować w dyskretnych bramkach...