Podstawy programowania FPGA z zestawem Elbert v2 VHDL czy Verilog?

Thu Feb 08, 2018 9:42 pm   

On 2/8/2018 12:50 AM, stchebel@gmail.com wrote:

To cecha języka. *TEGO* języka. W innym może być/jest inaczej. W dodatku
to żadna zaleta, to tylko jakieś założenie związane ze sposobem syntezy
takich układów lub poziomem alkocholu we krwi członka komitetu
standaryzującego lub wręcz brakiem takowego (verilog).

Thu Feb 08, 2018 11:10 pm   

W dniu czwartek, 8 lutego 2018 07:37:17 UTC+1 użytkownik Grzegorz Kurczyk napisał:

==============
Sie zagalopowałeś.. Ten drugi przypadek a<=b itd.. istotnie sugeruje shift register, no ale dla ścisłości należałoby to opisać jako proces z pewną listą parametrów czułości. Skomplikowane?! Nie !! Precyzyjne!! No i niestety chcąc nie chcąc daję się zaś prowokować do odwiecznej dyskusji nt. języków programowania.. Abstrahując od faktu, że VHDL/Verilog nie są językami programowania, twierdzę iż C powstał nie z potrzeby, ale że się dało. Podobnież jak Verilog. Zdecydowanie lepszym moim zdaniem odpowiednikiem C jest Pascal. VHDL powstał na bazie ADA. Prosty, chyba pierwszy język programowania obiektowego. Idealnie pasujący strukturalnie i behawioralnie do opisu i łatwej konstrukcji syntezy elektroniki cyfrowej na dowolną platformę. Verilog jest promowany, bo w zapisie podobny do C. I tak jak w latach 80'tych pieprzono, że C jest językiem wyższego rzędu, optymalnym w sensie czasu wykonania kodu wynikowego (bo krótki zapis jak w assemblerze) tak samo się pierdoli głupoty odn. VHDL/Verilog. Synteza równań logicznych, to "małe piwko". Synteza stanów maszynowych, to trochę więcej roboty, ale są gotowe narzędzia zarówno pod Veriloga jak i pod VHDL. Więc w tym temacie też nie ma o czym gadać.

Jedni lubią blondynki, inni brunetki...

Thu Feb 08, 2018 11:20 pm   

W dniu 08.02.2018 o 22:10, stchebel@gmail.com pisze:

Aj tam zaraz zagalopowałem co najwyżej użyłem zbyt dużego skrótu
myślowego Chodziło mi konkretnie o takie dwa przykłady:

module test1(
input clk,
input a,
output reg d
);
reg b, c;
always @(posedge clk) begin
b <= a;
c <= b;
d <= c;
end

wynik syntezy ftp://control.slupsk.pl/pub/fpga/test1.png

----------------------------------------------------


module test2(
input clk,
input a,
output reg d
);
reg b, c;
always @(posedge clk) begin
b = a;
c = b;
d = c;
end

wynik syntezy ftp://control.slupsk.pl/pub/fpga/test2.png
----------------------------------------------------


No i niestety chcąc nie chcąc daję się zaś prowokować do odwiecznej
dyskusji nt. języków programowania.. Abstrahując od faktu, że
VHDL/Verilog nie są językami programowania, twierdzę iż C powstał nie z
potrzeby, ale że się dało. Podobnież jak Verilog. Zdecydowanie lepszym
moim zdaniem odpowiednikiem C jest Pascal. VHDL powstał na bazie ADA.
Prosty, chyba pierwszy język programowania obiektowego. Idealnie
pasujący strukturalnie i behawioralnie do opisu i łatwej konstrukcji
syntezy elektroniki cyfrowej na dowolną platformę. Verilog jest
promowany, bo w zapisie podobny do C. I tak jak w latach 80'tych
pieprzono, że C jest językiem wyższego rzędu, optymalnym w sensie czasu
wykonania kodu wynikowego (bo krótki zapis jak w assemblerze) tak samo
się pierdoli głupoty odn. VHDL/Verilog. Synteza równań logicznych, to
"małe piwko". Synteza stanów maszynowych, to trochę więcej roboty, ale
są gotowe narzędzia zarówno pod Veriloga jak i pod VHDL. Więc w tym
temacie też nie ma o czym gadać.

Wcale nie zamierzam nic prowokować. Jedni wolą ogórki, a drudzy
ogrodnika córki Każdy język ma swoje "walety" i "zady". Dużo pisałem
w Pascalu i pascalopodobnych. Borlandowskie kompilatory TurboPascala na
x86 dawały tak zwięzły kod wynikowy, że jak przeglądałem go pod
debbugerem, to w assemblerze nie dałoby się już zbyt wiele
zoptymalizować. Pascal bardziej wymuszał czytelny zapis, ale przy
programowaniu nie raz mi "brakowało" zwięzłej konstrukcji typu
suma+=*wskaznik++; która ponoć jest nieczytelna. Przy programowaniu
małych 8-bitowych uC często mieszałem C z assemblerem. Pewne rzeczy
nawet wygodniej się robiło mi się w assemblerze :-)


--
Pozdrawiam
Grzegorz

Thu Feb 08, 2018 11:40 pm   

Sebastian Biały wrote:


Gubisz kontekst, który masz w tytule wątku. Człowiek chce sobie
popróbować zabawy z FPGA bez posiadania głębszej wiedzy o temacie.
Zachęcanie go do profesjonalnego podejścia do tematu to kpina.
Odpadnie na skonfigurowaniu środowiska testowego, o jakichkolwiek
elementach pracy zespołowej nie wspominając. Na tym etapie schematy
są idealne.


Nie wiem, z czego to wyssałeś, ale polecasz techniki właściwe do
budowania atomowych okrętów podwodnych człowiekowi, który chce
zbudować swoją pierwszą tratwę. Po kolei, Sebastian.

Pozdrawiam, Piotr

Thu Feb 08, 2018 11:44 pm   

Sebastian Biały wrote:


Tylko po co ma być "taniej"? To nie jest Chińczyk, którego zadaniem jest
zoptymalizowanie kilku centów. Na początek ma być wygodnie, a nie tanio.
W tym przypadku różnica to całe dwa dolary (cy8ckit-059 kosztuje $10,
a potrafi znacznie więcej niż mniejsze CPLD).

Pozdrawiam, Piotr

Thu Feb 08, 2018 11:48 pm   

stchebel@gmail.com wrote:


No nie rozpędzajmy się, dokładnie po to masz = i <=. Oba to przypisania,
a działają kapkę inaczej. :-)

Pozdrawiam, Piotr

Fri Feb 09, 2018 10:04 am   

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:p5ibo8$e9a$1@node2.news.atman.pl...
On 2/7/2018 2:59 PM, Piotr Wyderski wrote:

Poza tym ... nowoczesne uklady maja setki miliardow tranzystorow.
Jak chesz to narysowac ?
Nawet zakladajac, ze nie rysujemy tranzystorow czy np liczniki czy
rejestry.


Szczegolnie w kontekscie tych setek miliardow :-)

Z drugiej strony - jakas tam koncepcje konstrukcji danego bloku
projektant powinien miec, i myslec mniejszymi blokami.
A moze juz nie musi ? Kompilator/optymalizator zrobi to za niego z
opisu behawioralnego ?

I wezmy na tapete ten Nixie zegar - z jednej strony fajnie by bylo,
jakbym to co pisalem narysowal Atlantisowi, ale z drugiej:
-uzywac starych elementow TTL ? Po co, CPLD nie jest ograniczona do
ich zasobu.
-uzywac abstrakcyjnych licznik/rejestr/dekoder ... pogladowo swietnie,
ale one maja duzo opcji, trzeba sie za bardzo skupic na prawidlowym
okresleniu wszystkich, zeby dzialalo :-)

J.

Fri Feb 09, 2018 10:06 am   

W dniu czwartek, 8 lutego 2018 23:48:44 UTC+1 użytkownik Piotr Wyderski napisał:

Użyłem skrótu myślowego. Wiadomo, że '=' dotyczy zmiennych, a '<=' dotyczy sygnałów. Dla wątkotwórcy może się to wydawać trochę dziwne (zmienne w sprzęcie?), ale ma to sens. I tak w końcu kompilator, a raczej implementator zrobi z tego syntezę sygnałową.

Fri Feb 09, 2018 11:26 am   

W dniu czwartek, 8 lutego 2018 21:25:45 UTC+1 użytkownik Sebastian Biały napisał:

Najdelikatniej jak umiem.. Nie pisz skąd te bzdury wyssałeś :)

Efektem owych bzdur są gnomy "inżynierskie", które nie rozumieją podstaw elektroniki.. Baa.. Mało tego, mają tytuły mgr i nie mają bladego pojęcia jak działa dioda. O doborze parametrów owej nawet nie warto wspominać. Dalej.. Nie żartuję!! Kontrola wersji, regresja.. O czym Ty gościu p........ ?

Jednym z wymogów ISO coś tam, coś tam.., jest powywieszanie w firmie banerów " Jakość jest naszym motto..". Treść chyba inna, ale sens jest dokładnie taki..

"PZPR PRZEWODNIĄ SIŁĄ NARODU"

Da się "elektronikom" wyprać mózg? Chyba tak...

Fri Feb 09, 2018 11:42 am   

J.F. wrote:


A jak zjeść słonia? Po kawałku. Jak w każdej dziedzinie inżynierii,
i tu działa strukturalizacja. Bloczki składasz sobie z bramek/równań,
większe bloczki z mniejszych bloczków i tak aż do celu. A skoro
jednostką koncepcyjną jest moduł o dobrze określonych wejściach
i wyjściach, to w miejscu użycia nie najmniejszej różnicy, jak powstał.


Ale też nie zabrania ich używania. Zrób sobie bloczki/moduły
reprezentujące Twoje ulubione TTLe i z nich sklejaj, jeśli taka wola.
Syntezator i tak przecież zignoruje Twoją strukturę i narzuci swoją,
pasującą do konkretnego układu.


Wiele z nich istnieje w postaci gotowców w sieci, nie musisz poświęcać
na to własnego czasu.

Ja wolę mixed-mode. Podstawowe/dziwne bloczki mam w Verilogu, ale potem
składam z tego serie hierarchicznych schematów, bo w ten sposób widzę od
razu, jak informacja płynie w układzie. Skoro ludzki mózg jest
dostosowany do przetwarzania informacji w postaci graficznej, to po
co mam zamulać obraz sytuacji tekstem? Ja nie jestem software house,
dla którego istotne jest wydajne wspieranie projektów zespołowych
i przenośność bazy kodu. Mam luksus stawiania na czytelność intencji, to
z niego korzystam.

Pozdrawiam, Piotr

Fri Feb 09, 2018 12:27 pm   

W dniu czwartek, 8 lutego 2018 21:35:40 UTC+1 użytkownik Sebastian Biały napisał:


Jak się nie znasz, to dej se spokój.. Piszesz, że FPGA ciężko połączyć z czymkolwiek.. I do tego jeszcze tanio... Problem z logiką 5V? ŻADEN!! Bez żadnych buforów podciągających!! Ty chyba nie znasz marginesów działania TTL'ek.
VCCIO zasilasz napięciem 3.3V, i nie ma bata coby to nie gadało z TTL. To nie tylko teoria!! PRAKTYKA!! Poczytaj sobie o IO specification dot. X lub A, i nie fandzol głupot!!

Fri Feb 09, 2018 2:30 pm   

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:p5jtvd$u9l$1@node2.news.atman.pl...
J.F. wrote:

No wlasnie nie widze sensu, mialy te zalete, ze kiedys je w miare
dobrze znalem, wiec szansa popelnienia bledu mniejsza, ale ... po co
sie ograniczac ...


Hm, jakbym tak uzyl konkretnego TTL ... nie musialby uwzglednic
szczegolow jego budowy, ktore w danym projekcie sa calkowicie
nieistotne, alevon o tym nie wie, a zamodelowane ma (dla starych
inzynierow) ?


I to brzmi sensownie.

J.

Fri Feb 09, 2018 2:46 pm   

Użytkownik stchebel napisał w wiadomości grup
dyskusyjnych:d2d7393f-1066-49bb-b246-adda1931b7d7@googlegroups.com...
W dniu czwartek, 8 lutego 2018 21:25:45 UTC+1 użytkownik Sebastian
Biały napisał:

A po co im wiedziec jak dziala dioda ?

Oni sa od projektowania ASIC, i maja placone np za wiedze jak dziala
dekoder MPEG.



J.

Fri Feb 09, 2018 8:57 pm   

On 2/9/2018 11:27 AM, stchebel@gmail.com wrote:

Jednym z powodów dla których tak cieżko przyjmują sie arduino na ARMach
jest brak peryferiów obsługuących 3.3V. Niektore wyświetlacze nie
dzialają z 3.3. Niektóre uklady I2C nie działają. itd itp. Lista jest
dośc spora. Sytuacje poprawi upowszechnienie się innych klonów Arduino.
Obecnie perferia działające z 3.3V sa w mniejszości.

Co nikomu nie ogranicza uzywania lutownicy, buforów, rezystorów i
czegokolwiek tam sobie wymyślą. Tylko że to jest dodatkow *trudnośc*.
CPLD zdejmuje to brzemię i pozwala skupić sie na problemie a nie na
detalach działania układów wejściowych. Tu nie ma mowy o wyższości CPLD
nad FPGA, tylko o kosztach startu w tym temacie. CPLD jest tańszy z
wielu powodów, od kosztu układów, przez peryferia po oprogramowanie
(tutaj kosztem jest absurdalny rozmiar współczesnych środowisk)

Fri Feb 09, 2018 9:16 pm   

On 2/9/2018 10:26 AM, stchebel@gmail.com wrote:

Widzisz, z miejsca gdzie siedzę zawodowo widać bardzo duzy kawałek rynku
EDA od środka. Powiedzmy że wiem co jest obecnie stosowane na świecie i
jakie techniki zarzadzania jakością stosowane są w dużych firmach
zatrudniających tysiące programistów HDL. Jeśli wydaje Ci się że
ktokolwiek z nich rysuje schematy w dyzych projektach to po prostu nie
zauważyleś postepu. Owszem, rysuje się schematy w duperelowatych
przypadkach migania dioda czy zrobienia jakiegoś bufora z DRAM i
sporadycznie rysuje się schematy kiedy managerem jest Stasiek. Jesli
chodzi o elektronikę dużej skali i cieżkich parametrów (lotnictwo,
medycyna, wojsko) mozna tylko parsknąć śmiechem. Wszystkie, powtarzam,
wszystkie duże firmy stosują zupełnie inne metody zarzadzania jakoscią
niż armia Staśków gapiący sie w druty. Nawet nie zdajesz sobie sprawy
jak wiele wydarzyło się w ostatnich 10 latach w tej dziedzinie i jak
bardzo dramatycznie podniesiono wymogi jakościowe. W zasadzie cały
proces obrotu pieniedzmi w EDA skupia sie obecnie na weryfikacji a nie
na projektowaniu. Projektowanie jest trywialne wobec weryfikacji.


Mentalnie tkwisz ciagle w latach 60-tych. W międzyczasie HDL nabrały
prawie wszystkich technik programistycznych z normalnego programowania,
w szczególności wielu pojęć z Inżynieri Oprogramowania, jak rownież
języki zmieniły się dramatycznie przypominając duże jezyki obiektowe.
Takie rzeczy jak obiektowe uni testy, randomizacje, farmy regresyjne,
weryfikacja formalna, śledzenie wymagań, kontrola wersji, wzorce
projektowe, code review są *CODZIENNOŚCIĄ* w tej branży i pojawiły się
tam głównie dlatego że Staśków jest mniej, za to więcej ludzi
rozumiejących po co to wszystko wymyślono w programowaniu i dlaczego
generuje to zysk i jakość. To że został na świecie jakiś Stasiek co
uważa że gapienie się w druty rozwiązuje te problemy to nic nie można
poradzić. Świat bez Staśka będzie taki sam.


Nie masz pojęcia co krytykujesz. Nie wiesz co jest obecnie stosowane w
EDA bo siedzisz od 30 lat w tym samym minimum lokalnym potrzeb robiąc
swoje miganie diodami i bufory w DRAM. Nie ma sensu dyskutować o tym że
można inaczej bo sila przyzwyczajenia jest ogromna. Pozwól jednak że
porechoczę nieco słysząc opinie jednego misiaczka co gapi się w druty na
temat rynku światowego co go na oczy nie widział. Zatrudnij się w
większej firmie z rynku EDA, nawet w PL, zobaczysz na własne oczy jak
się wychodzi z jaskini i gdzie świat jest obecnie. Raczej nie w
rysowaniu schematów. Świat EDA w ostatnich 10 latach przeżył rewolucję
na skale absurdalną. Przykro mi że przesiedziałeś ją w jaskini. Wielu w
tej branzy nie wytrzymało tempa. Nie dziwie się, nauczenie się
obiektowości kiedy przez 30 lat rysowało się miganie diodą uważając to
za szczyt umiejętności bywa okrutnie trudne.

I pamiętaj, ignorancja nie jest siłą.