W paru projektach wykorzystałem już proste układy logiczne GAL. Niby
przestarzałe rozwiązanie, ale ułatwia zadanie tam, gdzie normalnie
trzeba by użyć kilku-kilkunastu układów logicznych. W dodatku możliwość
zastosowania znacznie bardziej dowolnej konfiguracji wejść/wyjść ułatwia
projektowanie PCB.

Teraz chciałbym się bliżej przyjrzeć bardziej złożonym układom
programowalnym. Zabrałem się za czytanie podręcznika VHDL-a, chciałem
trochę poeksperymentować na jakimś zestawie deweloperskim i zrobić
konkretny projekt. Docelowo pewnie będę eksperymentował z FPGA, ale na
razie chciałem zacząć od CPLD - choćby z uwagi na fakt, że nie
potrzebują zewnętrznej pamięci do przechowywania konfiguracji.
Wstępnie zdecydowałem się na układ Xilinx CoolRunner II XC2C256.

Nie mam jeszcze wielkiego rozeznania w możliwościach tych układów i tym,
jak zaawansowane projekty można stworzyć za ich pomocą, tak samo, jak
byłbym w stanie ocenić np. możliwości mikrokontrolera na podstawie
taktowania, rozmiaru pamięci i zestawu peryferiów.
Wiem, że na nowoczesnych FPGA można tworzyć całe zestawy
mikroprocesorowe a nawet odtwarzać komputery retro. Gdzie się mniej
więcej wpisuje wspomniany układ CPLD?

Domyślam się, że mikrokontrolera z dedykowanymi peryferiami na nim nie
stworzę. Domyślam się, że z prostym zegarem (a nawet zegarem z
kalendarzem) nie będzie problemu. A czy np. wystarczy "miejsca" na
zaprogramowanie synchronizacji czasu po DCF77?

do góry

Atlantis wrote:

> Nie mam jeszcze wielkiego rozeznania w możliwościach tych układów i tym,
> jak zaawansowane projekty można stworzyć za ich pomocą, tak samo, jak
> byłbym w stanie ocenić np. możliwości mikrokontrolera na podstawie
> taktowania, rozmiaru pamięci i zestawu peryferiów.
> Wiem, że na nowoczesnych FPGA można tworzyć całe zestawy
> mikroprocesorowe a nawet odtwarzać komputery retro. Gdzie się mniej
> więcej wpisuje wspomniany układ CPLD?

Jak się poszczęści, to mniej-więcej to to będzie jeden układ peryferyjny
z Amigi.

> Domyślam się, że mikrokontrolera z dedykowanymi peryferiami na nim nie
> stworzę. Domyślam się, że z prostym zegarem (a nawet zegarem z
> kalendarzem) nie będzie problemu. A czy np. wystarczy "miejsca" na
> zaprogramowanie synchronizacji czasu po DCF77?

Zależy jaką synchronizację chcesz robić. Jeśli ograniczysz się do
modulacji amplitudy i dokładność sekundowa wystarczy, to spokojnie
wejdzie. Jeśli chcesz wykorzystać informację z modulacji fazy, odbiór
podszumowy jak w GPS i dosynchronizować się precyzyjnie do nośnej, to
nawet fourierowski "koprocesor" do obliczania korelacji za chińskiego
boga w to nie wejdzie.

Moim zdaniem zamierzasz pójść ślepą uliczką. Główną zaletą układów CPLD
są stosunkowo precyzyjne timingi i działanie od razu po włączeniu. Ten
wynalazek służy głównie do pochłaniania "glue logic" z projektu, a nie
do "przetwarzania" czegokolwiek -- jeśli nie masz takich problemów, to
to nie jest rozwiązanie. Dlatego ja bym sugerował uczyć się CPLD *po*
FPGA, a nie przed. O ile w ogóle.

Kup sobie jakąś płytkę z FPGA jak chcesz iść w "czysty" sprzęt, albo coś
z PSoC5LP, jak wolisz rozwiązania mieszane typu SoC. FPGA weź od razu z
blokami DSP, szkoda marnować życie na rzeźbienie multiplikatorów w
LUTach. FPGA typu SoC (Cyclone V/Zynq) nie bierz na początek, bo się
pogubisz.

FYI, FPGA bez pamięci zewnętrznej też istnieją; zobacz np. u Microsemi.

Pozdrawiam, Piotr

do góry

On 13.09.2020 20:35, Piotr Wyderski wrote:

> Moim zdaniem zamierzasz pójść ślepą uliczką. Główną zaletą układów CPLD
> są stosunkowo precyzyjne timingi i działanie od razu po włączeniu. Ten
> wynalazek służy głównie do pochłaniania "glue logic" z projektu, a nie
> do "przetwarzania" czegokolwiek -- jeśli nie masz takich problemów, to
> to nie jest rozwiązanie. Dlatego ja bym sugerował uczyć się CPLD *po*
> FPGA, a nie przed. O ile w ogóle.

Tak, wiem. To nie jest docelowe wykorzystanie tych układów. Po prostu
ucząc się nowych układów lubię sobie postawić jakiś cel w postaci
niezbyt skomplikowanego projektu do wykonania. W ten sposób po
pierwszych próbach na zestawie deweloperskim mogę sobie zaprojektować
płytkę i uczyć się programowania tego konkretnego układu.
"Glue logic" trudno przetestować bez reszty układu, a rozwijanie
bardziej skomplikowanego projektu w celach dydaktycznych trochę mija się
z celem. Zbyt duże ryzyko, że trzeba będzie się zastanawiać czy nie
działa CPLD, czy może jakiś inny element układu.

Docelowo myślę o wykorzystaniu CPLD do w dwóch zastosowaniach:
1) Logika w ukłądach mikroprocesorowych. Czasem hobbystycznie składam
coś na starszych CPU. O ile w przypadku ośmiobitowych procesorów układy
z serii 74xx wystarczają, a GAL-e zapewniają pełną swobodę, to przy
MC68020 przydałoby się coś większego. :)
2) Projektowanie własnych układów peryferyjnych, współpracujących z MCU.

do góry

Piotr Wyderski <p...@n...mil> napisał(a):
> Dlatego ja bym sugerował uczyć się CPLD *po* FPGA, a nie przed. O ile w
> ogóle.

To po co ja zacząłem czytać Twój kurs CPLD w EdW? ;)

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

Grzegorz Niemirowski wrote:

> To po co ja zacząłem czytać Twój kurs CPLD w EdW? ;)

Kurs był PLD, a nie CPLD. ;-P

W zamierzeniu miał doprowadzić do pełnego wykorzystania SoC, ze
szczególnym naciskiem na integrację PLD z elementami analogowymi i
zahaczać o DSP, bo platforma jest wyjątkowo ciekawa i wszystkie klocki
są na miejscu. Mierniczki, odbiorniczki, nadajniczki, dwutlenek węgla,
taka sytuacja.

Natomiast Atlantis chce od razu wskoczyć w "twardą" logikę, więc go ten
SoC będzie tylko rozpraszał. :-)

Pozdrawiam, Piotr

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:rjloov$tf4l$...@p...wsisiz.edu.pl..
.
[...]
>Kup sobie jakąś płytkę z FPGA jak chcesz iść w "czysty" sprzęt, albo
>coś z PSoC5LP, jak wolisz rozwiązania mieszane typu SoC. FPGA weź od
>razu z blokami DSP, szkoda marnować życie na rzeźbienie
>multiplikatorów w LUTach. FPGA typu SoC (Cyclone V/Zynq) nie bierz na
>początek, bo się pogubisz.
>FYI, FPGA bez pamięci zewnętrznej też istnieją; zobacz np. u
>Microsemi.

Piotrze, a tak na marginesie ups up-online sinus czy solarow - na czym
zrobic falownik, tzn sterowanie falownika ?

Trzeba wygenowac PWM do sterowania mostkiem, z szykanami typu np
kontrola pradu.
Na procesorku odpowiednio mocnym - wiadomo, ze da rade.
Na procku DSP - moze i overkill, ale moze lepiej niz rzezbic sinusy na
8 bit.

Ale mam jakies opory przeciw sterowaniu drogich tranzystorow z
programu, ktory moze sie zawiesic czy glupoty wygenerowac :-)

FPGA ... no wlasnie - zdaży sie załadowac program/konfiguracja, czy
tranzystory spłoną wczesniej ?

J.

do góry

J.F. wrote:

> Trzeba wygenowac PWM do sterowania mostkiem, z szykanami typu np
> kontrola pradu.
> Na procesorku odpowiednio mocnym - wiadomo, ze da rade.
> Na procku DSP - moze i overkill, ale moze lepiej niz rzezbic sinusy na 8
> bit.

PSoc5LP spokojnie da radę i będzie się dało to zrobić bez rzucenia się
na głęboką wodę w stylu przerzucenia się od razu na FPGA. Akurat
liczenie sinusa jest proste, dokładność 18-bitowa to dwa zajrzenia w
tabelkę i jedno mnożenie. Da się zrobić całkowicie poza programem
głównego ARMa.

Możesz to zrobić na wiele sposobów: przeprogramowywać PWM za pomocą DMA
sterowanego przez UDB, wygenerować sinusa IDACem (do 8Msa/s) i PWM
zrobić "analogowo" na komparatorze, napisać cały sterownik w asemblerze
DFB i uruchomić go jako koprocesor. Jest wiele opcji.

> FPGA ... no wlasnie - zdaży sie załadowac program/konfiguracja, czy
> tranzystory spłoną wczesniej ?

Przecież sterowanie tranzystorami musisz zrobić w sposób odporny na
pojedynczy błąd w sterowniku, np. polegający na ustawieniu stanu
wysokiej impedancji na wejściu drivera. IEC62304 Class B.

Pozdrawiam, Piotr

do góry

W dniu 14.09.2020 o 10:40, J.F. pisze:
>
> Ale mam jakies opory przeciw sterowaniu drogich tranzystorow z programu,
> ktory moze sie zawiesic czy glupoty wygenerowac :-)
>
To raczej kwestia takiego zaprojektowania układu sterowania tranzystorów
aby nie było możliwości programowego włączenia górnego i dolnego
tranzystora jednocześnie.


> FPGA ... no wlasnie - zdaży sie załadowac program/konfiguracja, czy
> tranzystory spłoną wczesniej ?
>
Podobny problem jest w uC podczas resetu. W zależności od konstrukcji
piny były w tym momencie wejściem HiZ, wejściem z pullup albo jeszcze
jakiś inny stan nieustalony. Trzeba było kombinować coś między prockiem
a tranzystorami (i tak najczęściej musiał byc jakiś driver) aby
wyeliminować możliwość zwarcia mostka lub podania pełnego napięcia na
obciążenie w czasie startu programu lub resetu procka.

Z tego co pamiętam Atmelowski AT90PWM3 zawiera logikę do sterownia
mostkiem 3F, która sprzętowo zabezpiecza przed takimi niespodziankami.


--
Pozdrawiam
Grzegorz

do góry

Użytkownik "Grzegorz Kurczyk" napisał w wiadomości grup
dyskusyjnych:5f5f3446$0$555$6...@n...neostrada.
pl...
W dniu 14.09.2020 o 10:40, J.F. pisze:
>> Ale mam jakies opory przeciw sterowaniu drogich tranzystorow z
>> programu, ktory moze sie zawiesic czy glupoty wygenerowac :-)
>
>To raczej kwestia takiego zaprojektowania układu sterowania
>tranzystorów aby nie było możliwości programowego włączenia górnego i
>dolnego tranzystora jednocześnie.

Plus pare innych zabezpieczen - ze np nie moze byc jeden kierunek w
mostku zbyt dlugo otwarty, jakies zabezpieczenie nadpradowe tez by sie
przydalo ... no i wlasnie - decyzja projektowa - dac te zabezpieczenia
mozliwie proste i moze nawet na dyskretnych elementach,
czy rozbudowac troche i wsadzic w CPLD,

czy zrobic w FPGA/CPLD caly falownik sinusoidalny, a tylko sterowac
prockiem parametry ... i tu byc moze wyjdzie, ze srednie CPLD jest za
slabe na zrobienie nawet DDS ..

>>> FPGA ... no wlasnie - zdaży sie załadowac program/konfiguracja,
>>> czy tranzystory spłoną wczesniej ?
>
>>Podobny problem jest w uC podczas resetu. W zależności od
>>konstrukcji piny były w tym momencie wejściem HiZ, wejściem z pullup
>>albo jeszcze jakiś inny stan nieustalony. Trzeba było kombinować coś
>>między prockiem a tranzystorami (i tak najczęściej musiał byc jakiś
>>driver) aby wyeliminować możliwość zwarcia mostka lub podania
>>pełnego napięcia na obciążenie w czasie startu programu lub resetu
>>procka.

Driver i tak musi byc ... ale stan na wyjsciach FPGA w czasie
konfigurowania jaki jest ?

>Z tego co pamiętam Atmelowski AT90PWM3 zawiera logikę do sterownia
>mostkiem 3F, która sprzętowo zabezpiecza przed takimi
>niespodziankami.

A w czasie resetu ? :-)

J.

do góry

Grzegorz Kurczyk wrote:

> Podobny problem jest w uC podczas resetu. W zależności od konstrukcji
> piny były w tym momencie wejściem HiZ, wejściem z pullup albo jeszcze
> jakiś inny stan nieustalony.

W 5LP można zadać w konfiguracji stan na czas resetu. Właśnie dlatego.

Pozdrawiam, Piotr

do góry