W dniu 19.08.2013 21:55, Adam Górski pisze:
> W dniu 2013-08-19 21:01, Jakub Rakus pisze:
>> W dniu 18.08.2013 22:36, butek pisze:
>>> W dniu 18.08.2013 21:46, Jakub Rakus pisze:
>>>>
>>>> A jakiś prosty analizator stanów logicznych dałoby radę łatwo na tym
>>>> zrobić?
>>>>
>>> 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.
>>>
>>
>> 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.
>>
>
> 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

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.
--
Pozdrawiam
Jakub Rakus

do góry

W dniu 2013-08-19 21:59, Jakub Rakus 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.

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.

--
Michał

do góry

On 2013-08-18 23:13, Adam Górski wrote:
> Ale fakt, w jakimkolwiek HDL-u to trzeba mieć wyższy poziom abstrakcji
> niż w C / C++.

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.

do góry

On 2013-08-17 22:30, s...@g...com wrote:
> A wystarczy napisać A<=B+C

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?

do góry

W dniu wtorek, 20 sierpnia 2013 21:31:26 UTC+2 użytkownik Sebastian Biały napisał:
> On 2013-08-17 22:30, s...@g...com wrote:
>
> > A wystarczy napisać A<=B+C
>
>
>
> 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?

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?

do góry

W dniu 2013-08-20 22:57, s...@g...com pisze:
> W dniu wtorek, 20 sierpnia 2013 21:31:26 UTC+2 użytkownik Sebastian Biały napisał:
>> On 2013-08-17 22:30, s...@g...com wrote:
>>
>>> A wystarczy napisać A<=B+C
>>
>>
>>
>> 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?
>
> 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?
>

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.

--
pozdrawiam
MD

do góry

Jakub Rakus wrote:
[...]
> 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.

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:
http://www.freerangefactory.org/site/pmwiki.php/Main
/Books

pzdr.
j.

do góry

Dnia Tue, 20 Aug 2013 13:57:55 -0700 (PDT), s...@g...com
>> 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?
>
> 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?

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.

do góry

>> Ale fakt, w jakimkolwiek HDL-u to trzeba mieć wyższy poziom abstrakcji
>> niż w C / C++.
>
> 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.
>

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

do góry

W dniu wtorek, 20 sierpnia 2013 23:45:37 UTC+2 użytkownik Mario napisał:
> W dniu 2013-08-20 22:57, s...@g...com pisze:
>
> > W dniu wtorek, 20 sierpnia 2013 21:31:26 UTC+2 użytkownik Sebastian Biały
napisał:
>
> >> On 2013-08-17 22:30, s...@g...com wrote:
>
> >>
>
> >>> A wystarczy napisać A<=B+C
>
> >>
>
> >>
>
> >>
>
> >> 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?
>
> >
>
> > 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?
>
> >
>
>
>
> 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.
>
>

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.

do góry