VHDL vs. Verilog

Temat w zasadzie w stylu "lepsze są blondyny, czy rude?" Ja w zaparte jestem za VHDL'em. Trochę trza się do tego przyzwyczaić, jest to tzw. "strong typed language" i BARDZO DOBRZE !! Semantyka Veriloga jest trochę podobna do Pascala, ale BROŃ CIĘ PANIE rozumować kategoriami programistycznymi w odniesieniu do HW. Trza się przestawić na zupełnie inny poziom abstrakcji używając VHDL/Verilog, a pisząc programy Pascal/C/C++. Co się tyczy opisu HW, zdecydowanie obstaję za VHDL.

A soft w większości przypadków trza skrobać w C/C++. A już TOTALNYM popaprańcem jest typ "VOLATILE" !! Zalecany w aplikacjach ADC. Głupszej głupoty nie widziałem!! No cheba, że przetwarzamy sygnał o nośnej paru Hertzów próbkowany z częstotliwością pierdyljona Gigahertzów. Trochę przesadziłem, ale generalnie o to chodzi. Porządnej demodulacji FM ja bym tak nie robił. A cholera wie jak se to kompilator z tym pokombinował....

Reply to
stchebel
Loading thread data ...

W dniu 16.08.2013 19:12, snipped-for-privacy@gmail.com pisze:

Ano właśnie, dostałem w zeszłym roku taką śmieszną płytkę Lattice MachX02 Pico Dev Kit. Chciałbym się tym trochę pobawić, ale jeśli chodzi o FPGA/CPLD to jestem totalnie zielony, nigdy nie miałem z tym do czynienia i nie bardzo wiem z której strony się do tego zabrać. Może jakaś porada co będzie prostsze do ogarnięcia dla kogoś przyzwyczajonego do C i 8 bitów?

Reply to
Jakub Rakus

W dniu piątek, 16 sierpnia 2013 22:52:16 UTC+2 użytkownik Jakub Rakus napisał:

Z CPLD nigdy się nie bawiłem, bo i takiej potrzeby nie było. Jest to co prawda tanie, ale zbyt wiele logiki do tego nie upchasz. Co się zaś tyczy FPGA, to zapomnij na wstępie o C/C++ i wszelakich językach programowania. FPGA to nie jest procek na którym możesz jakiś tam soft wyrzeźbić. FPGA jest to platforma hardwarowa, taka 'tabula rasa' na której możesz sobie w obrębie jej zasobów wystrugać dowolną logikę bez lutownicy. Przy odpowiednio zasobnych FPGA nawet i procka, którego możesz dalej oprogramiać. Jeżeli to Cię interesuje, zassaj sobie za darmola WebPack'a z

formatting link
, i pobaw się najpierw projektowaniem byle czego z poziomu normalnego schematu. Bramki, liczniki, sumatory i tym podobne pierdualia. Konkretne numery pinów wejściowych i wyjściowych też sam określasz bez lutkolby (UCF-user constraint file). Krótko mówiąc sam smarujesz se schemat tego co ma siedzieć w scalaku i co on ma robić. Fajne, co nie?! Możesz se i procka w/g własnego pomysłu wystrugać!! A idąc dalej w las, są właśnie takie narzędzia jak VHDL/Verilog - języki którymi opisujesz co badziewie ma robić. Cholernie wygodne. Wyobraź sobie zaprojektowanie sumatora n-bitowego na poziomie bramek. Jest trochę roboty.. A wystarczy napisać A<=B+C, resztę zrobi za Ciebie soft i zaimplementuje do wybranego układu FPGA.

Generalnie nie ma się czego bać, ino przestaw myślenie z C na hardware. A najlepiej na początek przygody z FPGA w ogóle zapomnij o wszelakich językach programowania. Bo to zupełnie 2 różne zagadnienia.

Mam nadzieję, że trochę rozjaśniłem temat. Jakby cosik nie było jasne, śmiało pytaj tutaj. Na miarę wiedzy postaram się doradzić.

Reply to
stchebel

W dniu 17.08.2013 22:30, snipped-for-privacy@gmail.com pisze:

To może jakiś przykład praktyczny co takiego można zrobić "łatwo" na FPGA, co na zwykłym procku jest "trudne" (znaczy się zajmuje duuużo linii kodu, długo się wykonuje i/lub mocno obciąża CPU jakimiś mnożeniami i dzieleniami)?

Reply to
Jakub Rakus

W dniu 18.08.2013 18:02, MiSter pisze:

A jakiś prosty analizator stanów logicznych dałoby radę łatwo na tym zrobić?

Reply to
Jakub Rakus

W dniu 18.08.2013 21:46, Jakub Rakus pisze:

Dobrze działające analizatory się TYLKO na "tym" robi. Wszelkie cuda na AVR'ach i ogólnie sekwencyjnie przetwarzających uC to lepsze, bądź gorsze zabawki. Siłą FPGA jest właśnie przetwarzanie równoległe bez opóźnień - a tego na uC nie osiągniesz nigdy.

Reply to
butek

W dniu 2013-08-16 19:12, snipped-for-privacy@gmail.com pisze:

Hmm... ja też , ale może dla tego że na veriloga później trafiłem , a może dlatego że VHDL dominował. Zobaczymy jak długo to potrwa bo już się słyszy o językach wyższego poziomu.

Ale fakt, w jakimkolwiek HDL-u to trzeba mieć wyższy poziom abstrakcji niż w C / C++.

Ale to długa historia.

Adam

Reply to
Adam Górski

W dniu 18.08.2013 22:36, butek pisze:

No dobrze, to jeszcze jedno pytanie: czy ktoś poleciłby dobrą lekturę na ten temat, taką co poprowadzi od podstaw do bardziej wymyślnych projektów, może być angielskojęzyczna, bo jak widzę po naszemu niewiele tego jest.

Reply to
Jakub Rakus

W dniu 2013-08-19 21:01, Jakub Rakus pisze:

No tu jest trochę kiepsko. O ile o samej składni jest tego dosyć sporo o tyle o sprawach istotnych raczej mało.

Mówiąc o istotnych sprawach , mam na myśli: "Jak pisać żeby działało.." Np bardzo mało podręczników czysto o VHDL lub verilogu mało mówi o ogólnych zasadach takich jak synchronizacja sygnałów asynchronicznych czy też o problemach w projektach gdzie występuje wiele asynchronicznych zegarów. Doświadczenie trzeba zebrać.

Adam

Reply to
Adam Górski

W dniu 19.08.2013 21:55, Adam Górski pisze:

No ale coś na początek? Angielskojęzycznych pozycji widzę sporo, tylko szkoda coś brać, co może być mało przydatne, dlatego pytam znających temat co by polecili początkującemu.

Reply to
Jakub Rakus

W dniu 2013-08-19 21:59, Jakub Rakus pisze:

Według mnie ciekawą książką jest: Mano M. Morris, Kime Charles R.: Podstawy projektowania układów logicznych i komputerów Niestety do zdobycia tylko z drugiej ręki, wydawca nie planuje wznowienia. Wiele przykładów jest opisanych w Verilogu i VHDL więc każdy może sobie porównać opis tej samej logiki w obu językach. Jest to takie kompendium od podstaw układów cyfrowych, logiki zerojedynkowej aż do projektów mikroprocesorów, pamięci itp. Nie ma w niej konkretów dotyczących układów FPGA czy PLD, przez co może nie jest też idealna do rozpoczęcia działań z tego rodzaju układami. Daje raczej podstawy natury bardziej ogólnej układów cyfrowych, jednak zapisane w języku opisu sprzętu. Dostarcza więc klocki, malutkie, z których można coś konkretnego zbudować. Każdy klocek jest dokładnie opisany.

Reply to
Michał Lankosz

Rozwiń tą myśl, proszę. Z moich obserwacji jest dokladnie odwrotnie - to dopiero od kilku lat w HDLu ktoś ruszyl dupę i zobaczył techniki programistyczne głównie oparte o abstrakcje z przed dzesięcioleci, do tej pory odkrywali głównie kwadratowe koła.

Reply to
Sebastian Biały

Tak, to faktycznie bardzo proste do pierwszego pytania: a to ma być unsigned, 1C, 2C czy może w kodzie Graya (i którym) i czy sumator ma być może szeregowy czy może równoległy?

Reply to
Sebastian Biały

Sprawa jest identyczna jak w każdym innym języku. Jeżeli dajmy na to napiszemy w Pascalu a:=b+c; , to równie dobrze można postawić pytanie "czy te zmienne będą typu integer, a może real?". Odpowiedź w obu przypadkach jest taka sama: jak se zmienne/sygnały zadeklarujesz, tak masz. Standardowo przy zapisie A<=B+C narzędzia implementujące zrobią Ci równoległy sumator. Ale jak chcesz, nie ma problemu, żeby poskładać 1-no bitowe sumatory z przeniesieniem w VHDL'u w n-bitowy szeregowiec. Tylko po co?

Reply to
stchebel

W dniu 2013-08-20 22:57, snipped-for-privacy@gmail.com pisze:

Tylko, że czasami trzeba robić operacje na różnych typach. I nie ma standardowych bibliotek do konwersji typów. Różnice między kolejnymi standardami 1076 niby niewielkie, a w praktyce trzeba się napieprzyć aby aby coś poprawnie skompilować. W C masz niejawne rzutowanie, możesz też sam rzutować do jakiegoś typu. Nie musisz do tego celu kombinować z dołączaniem bibliotek i martwić się czy będą działały z aktualną wersją języka. No i możesz po prostu pisać w starej wersji standardu i nowy kompilator się o to nie obrazi.

Reply to
Mario

Jakub Rakus wrote: [...]

Nie wiem czy będzie Ci odpowiadać, ale wygląda całkiem nieźle. Książki prowadzą za rękę, zaczynając od prostych projektów, na koniec zostawiając z wystarczającą wiedzą żeby zabrać się za coś bardziej skomplikowanego:

formatting link
pzdr. j.

Reply to
Jacek Radzikowski

Dnia Tue, 20 Aug 2013 13:57:55 -0700 (PDT), snipped-for-privacy@gmail.com

Panowie, ale to jest jezyk do projektowania sprzetu (nie tylko).

W kazdym innym jezyku kompilator wykorzysta dostepny rozkaz procesora. A tu glowa projektanta w tym czy ma czas i moze byc poskladany kaskadowo z 1-bitowych, czy musi byc szybko i nie wazne ile tranzystorow/bramek/makrocel wyjdzie, byleby te 64 bity sie w 1 cyklu dodaly ...

J.

Reply to
J.F.

Oj, ale nie w rozumieniu technik programowania. Programowanie C/C++ jest zasadniczo sekwencyjne ( stosunkowo niedawno weszły równoległe rdzenie i przetwarzanie równoległe ) Pisanie w HDL jest równoległe z samego założenia - opisuje sprzęt i wymaga nieco więcej wyobraźni.

Pisząc "abstrakcji" miałem na myśli wyższy stopień wykorzystania mózgu ludzkiego.

Pzdr

Adam

Reply to
Adam Górski

W dniu wtorek, 20 sierpnia 2013 23:45:37 UTC+2 użytkownik Mario napisał:

Na tym właśnie polega burdelarstwo języka C !! I z tego właśnie powodu, ze źle pojętego wygodnictwa programiści skrobiący w C piszą aplikację w 3 dni, aby potem ślęczeć 3 miesiące w poszukiwaniu pierdualnego błędu. Deklarowanie zmiennej byle gdzie, to wręcz zaproszenie do burdelarstwa, ale to jeszcze "małe piwo". Natomiast niejawne rzutowanie typów, to tego już za cholerę nie mogę zrozumieć. Nie, żebym nie rozumiał o co w tym chodzi, jak to działa i jak stosować. Ale to jest właśnie najczęstszym powodem strupa na głowie "dlaczego program nie działa?". A co za problem dołączyć bibliotekę, bądź samemu pokombinować nad wymaganą konwersją typu? To jest Twoim zdaniem kombinowanie ? To jest PORZĄDEK i SYSTEMATYKA!! W takim np. Pascalu, czy FORTRANIE taki numer nie przejdzie!! Kompilator od strzału wywala błąd. I bardzo dobrze!! Wiem, młodzi programiści uważają, że C/C++ to najlepszy język na świecie. Na pytanie o znajomość Pascala bądź Algol'a odpowiedź jest : NIE!! Każdy język "ostro typowany", ostro eliminuje upierdliwe "bugg'i", wprowadza porządek itd. A co się zaś tyczy symboli operatorów logicznych w C/C++, to powymyślał je chyba jakiś psychopata.

Reply to
stchebel

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.