W dniu 2013-08-21 17:20, s...@g...com pisze:
> 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 ?

Jak pisałem możesz użyć rzutowania jawnego. A w VHDL masz do tego jakieś
z d. wyjęte biblioteki które mogą być albo i nie być w konkretnej instalce.

> 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.
>

Tia, tylko że w każdej książce autor podaje inne biblioteki. Każdą po
kolei próbujesz, a taki np. Webpack ich nie ma. Jak już coś sobie
sklecisz to nie masz pewności czy przy kolejnej wersji Webpacka
zadziała prawidłowo konwersja projektu do nowszej wersji.
I słusznie wspomniałeś o Fortranie. VHDL jest w tej chwili na etapie
Fortranu z 77 r.


--
pozdrawiam
MD

do góry

W dniu wtorek, 20 sierpnia 2013 21:27:57 UTC+2 użytkownik Sebastian Biały napisał:
> 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.

Kolega miał zapewne co innego na myśli pisząc o poziomie abstrakcji (ja zresztą też).
Dajmy na to taki kod w języku C:

a=b+c;
d=a+e;

A teraz te same 2 linijki w odwrotnej kolejności:

d=a+e;
a=b+c;

Zgodzisz się, że wynik w zmiennej "d" w obu przypadkach może być różny. W VHDL'u nie
ma znaczenia kolejność zapisu. Kolejne linijki kodu opisują operacje na sygnałach i
"połączenia" między sygnałami. Stąd:

1) a<=b+c;
d<=a+e;

2) d<=a+e;
a<=b+c;

to jeden i ten sam pieron!

do góry

W dniu środa, 21 sierpnia 2013 17:32:29 UTC+2 użytkownik Mario napisał:

>
>
> Tia, tylko że w każdej książce autor podaje inne biblioteki. Każdą po
>
> kolei próbujesz, a taki np. Webpack ich nie ma. Jak już coś sobie
>
> sklecisz to nie masz pewności czy przy kolejnej wersji Webpacka
>
> zadziała prawidłowo konwersja projektu do nowszej wersji.
>

Podaj konkretny przykład, podyskutujemy..

do góry

On 2013-08-20 22:57, 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.

Nie jest. Polemizuje z twoja opinią jakoby było to proste. W językach
opisu sprzętu nic nie jest proste zaczynając od dodawania ...


> Jeżeli dajmy na to napiszemy w Pascalu a:=b+c;

... to pracujesz na architekturze i języku który doskonale definiuje co
to jest dodawanie. W sprzęcie zazwyczaj nie definiujesz tego w sposób
uniwersalny bo tam są czasem zagadnienia typu "jak dodać 3 druty w 2C do
4 drutów Unsigned, przy czym wiadomo że mam 3 cykle zegara a w dodaku na
wyjściu może być mały hazard bo i tak mam zatrzask". Porownanie do
języków typu Pascal jest zwodnicze. To nie dziala tak samo mimo
podobnych składni.

do góry

On 2013-08-21 17:33, s...@g...com wrote:
> W VHDL'u nie ma znaczenia kolejność zapisu.

Przesadzasz z upraszczaniem. Ma znaczenie i nie ma. To że sygnały są w
rzeczywistości przypisywane na suspendzie procesu nijak nie oznacza że
kolejność jest bez znaczenia - tam masz subtelne opóźnienie symulowane w
postaci cyklów delta i nie da się go zapisać tak prostym zdaniem,
szczególnie jeśli dotyczy ono np. dwóch procesów wzajemnie czułych na
zmiany.

Nic gorszego nie może spotkać człowieka jak nadmierne upraszczanie
HDLowych zapisów. Że wspomnę choćby Veriloga z jego zapisem "blokujacym"
i "nieblokujacym" na którym nie jeden doktorat zrobiono.

do góry

W dniu 2013-08-21 17:40, s...@g...com pisze:
> W dniu środa, 21 sierpnia 2013 17:32:29 UTC+2 użytkownik Mario napisał:
>
>>
>>
>> Tia, tylko że w każdej książce autor podaje inne biblioteki. Każdą po
>>
>> kolei próbujesz, a taki np. Webpack ich nie ma. Jak już coś sobie
>>
>> sklecisz to nie masz pewności czy przy kolejnej wersji Webpacka
>>
>> zadziała prawidłowo konwersja projektu do nowszej wersji.
>>
>
> Podaj konkretny przykład, podyskutujemy..
>

Problem trochę stary więc szczegółów nie pamiętam. Walczyłem z konwersją
vector > uint i w drugą stronę. Funkcje do konwersji siedzą w dwóch
różnych bibliotekach: arith i numeric. I nie wiem czemu są to całkiem
różne funkcje. Bibliotyeki nawzajem się wykluczają. Numeric jest
zalecana jako nowsza. Jednak żaden książkowy przykład z numeric nie
udało mi się skompilować w ISE. W końcu zrobiłem to jakoś na arith. Ale
pozostało mi wrażenie, że jak robią taki sformalizowany język ze
sztywnym typowaniem, to kretyństwem jest robić chaos w czymś tak
podstawowym jak konwersja typów.

--
pozdrawiam
MD

do góry

On 08/21/2013 07:46 PM, Mario wrote:
>>
>
> Problem trochę stary więc szczegółów nie pamiętam. Walczyłem z konwersją
> vector > uint i w drugą stronę. Funkcje do konwersji siedzą w dwóch
> różnych bibliotekach: arith i numeric. I nie wiem czemu są to całkiem
> różne funkcje. Bibliotyeki nawzajem się wykluczają. Numeric jest
> zalecana jako nowsza. Jednak żaden książkowy przykład z numeric nie
> udało mi się skompilować w ISE. W końcu zrobiłem to jakoś na arith. Ale
> pozostało mi wrażenie, że jak robią taki sformalizowany język ze
> sztywnym typowaniem, to kretyństwem jest robić chaos w czymś tak
> podstawowym jak konwersja typów.
>

numeric jest zgodny ze standardem IEEE, arith to de-facto standard
Synopsysa.
Osobiście nie mialem problemu z używaniem numeric pod ISE.

A tak poza tym, ISE już jest teraz ledwo wspierane, Xilinx promuje Vivado.

do góry

W dniu 21.08.2013 05:45, Jacek Radzikowski pisze:
> 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.
>

Wielkie dzięki, o takie coś właśnie mi chodziło.

--
Pozdrawiam
Jakub Rakus

do góry