Tym facetom w Xilinksie to już kompletnie szajba odbiła. Im wręcz chyba odpierdoliło
i mam nadzieję że ich software developement supervisor dostanie srogiego kopa w dupę.

Brak możliwości projektowania z poziomu graficznego (schemat).

Bardzo sobię cenię projektowanie behawioralne i FSM w VHDL/Verilog , chociaż tego
drugiego zbytnio nie lubię (temat na osobny wątek).

Projektowanie strukturalne w VHDL/Verilog też ma swoje plusy, postrzegam je jedynie w
projektach w których jest n-krotność kanałów.

===========

Przy dużych projektach, to jak se projektant pojedzie na ryby, to ni Wuja po powrocie
nie będzie wiedział po tygodniu o co mu chodziło i co napisał.

Na schemacie zajęło by mu to góra godzinę.

=================

Xilinx chwali się teraz tym, że Vivado kompiluje jakieś 30% szybciej..
Buahaha!!! Czyli zamiast 10 minut, mamy 6 minut!! SUPER!! Ino z projektem trza się
pierdolić 4 tygodnie vs. 1 tydzień (ISE).

do góry

W dniu 2015-01-24 o 17:11, s...@g...com pisze:
> Tym facetom w Xilinksie to już kompletnie szajba odbiła. Im wręcz chyba
odpierdoliło i mam nadzieję że ich software developement supervisor dostanie srogiego
kopa w dupę.
>


[pac]


Quartus górą :)

@

do góry

On 2015-01-24 17:11, s...@g...com wrote:
> Brak możliwości projektowania z poziomu graficznego (schemat).

Uważaj. Projektowanie z poziomu kodu ma wiele zalet, że wymienie choćby
testy. EDA obecnie oszalała na punkcie testowania i weryfikacji i cały
impet rynku kierowany jest naweryfikację. Takie testy *NIE* projektuje
się graficznie. Graficzne opisy są poprostu gówno warte w poważnych
zastosowaniach (np. DO-254). Od czasu schematów wymyslono wiele technik
programowania HDL dramatycznie podnoszacych jakość kiepskich języków
opisu sprzętu (asercje, coverage, constrains, unit testy itd). Tak wiem
że dla wielu legacy hardwareowców to jest zbiór bzdur bo najlepsze są
druty i bramki. Życie.

> Przy dużych projektach, to jak se projektant pojedzie na ryby
>, to ni Wuja po powrocie nie będzie wiedział po tygodniu o co mu chodziło i co
napisał.

To kiepski programista jest. Bo kod ma byc łatwo czytać a nie pisać.

> Na schemacie zajęło by mu to góra godzinę.

Mam dostęp do pewnego schematu. Jakieś 30 tyś przerzutników,
multiplekserów, liczników itp drobnostek. Czyli godzinka, nie? No, chyba
ze mowisz o mruganiu diodą. A, i bład jest "cztery metry po lewej i
17centymetrow od góry".

Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
schematem graficznym. Chyba że mówisz o mruganiu diodą robionym przez
jednego klikacza ... tak, to wtedy można ...

do góry

"Artur Miller" <n...@n...com> wrote in message
news:ma0gsh$f2g$1@usenet.news.interia.pl...
> Quartus górą :)

Żeby tylko im nie wpadło do głowy wyrzucić graficznego
trybu w następnych wersjach... :-(

do góry

<s...@g...com> wrote in message
news:35f2f587-9fb6-431e-a815-aaac52ce115b@googlegrou
ps.com...
> Przy dużych projektach, to jak se projektant pojedzie na ryby,
> to ni Wuja po powrocie nie będzie wiedział po tygodniu
> o co mu chodziło i co napisał.
>
> Na schemacie zajęło by mu to góra godzinę.

Jest w tym temacie jedna zaleta trybu VHDL/Verilog nad graficznym...

Mianowicie "version control" - i porównywanie co się zmieniło
z wersji 1.45 do wersji 1.46 i 1.47 Twojego projektu...
Wrzucasz pliki tekstowe do takiego Starteam czy innego klienta
i pokazuje Ci pięknie każdą linijkę zmiany plików tekstowych.
Umożliwia Ci np. łączenie zmian z różnych odnóg projektów...
Tak jak to robią nasi koledzy z działów software (C/C++/Java itp).

Ja nie znam na dzień dzisiejszy narzędzia które wzięłoby jeden
plik *.bdf z Quartusa i porównało z drugim plikiem *.bdf i potem
ładnie, również graficznie, podkreśliło/zaakcentowało zmiany
naniesione między tymi plikami...

A to jest duża wada projektowania graficznego którą załatwia VHDL.

do góry

"Sebastian Biały" <h...@p...onet.pl> wrote in message
news:ma0h4r$5a8$1@node2.news.atman.pl...
> Mam dostęp do pewnego schematu. Jakieś 30 tyś przerzutników,
> multiplekserów, liczników itp drobnostek. Czyli godzinka, nie?
> No, chyba ze mowisz o mruganiu diodą.
> A, i bład jest "cztery metry po lewej i 17centymetrow od góry".

Nie mów mi, że w top-level masz 30 tysięcy przerzutników...
Bo to niepoważne jeśli nie używasz hierarchicznych bloków.

do góry

On 2015-01-24 17:38, Pszemol wrote:
>> Mam dostęp do pewnego schematu. Jakieś 30 tyś przerzutników,
>> multiplekserów, liczników itp drobnostek. Czyli godzinka, nie?
>> No, chyba ze mowisz o mruganiu diodą.
>> A, i bład jest "cztery metry po lewej i 17centymetrow od góry".
> Nie mów mi, że w top-level masz 30 tysięcy przerzutników...
> Bo to niepoważne jeśli nie używasz hierarchicznych bloków.

Projekt został wydziargany przez firme wktórej pracowal kolega (robili
coś koło 3 lat). O ile wiem mieli na starcie wczesne źródo w postaci
płaskiego schematu (może po jakiejś syntezie lub reverse engeneering
istniejącego urządzenia) który rozwijali. Używali niewiele bloków (tylko
do nowych rzeczy). Analiza schematu sprowadzała się głównie do
debugowania działania w symulatorze i poprawy bądź dopisania
(dorysowania) obok poprawki. Prawdopodobnie nie przepisali tego do hdl
dlatego że średnia wieku była >45 lat a kolega ją mocno zaniżał. Projekt
jest bez sensu (nie da się go ani poprawić, bo schematów nie da się
łatwo poprawiać, ani testować) ale doskonale obrazuje problem z gatunku
"wole schemat". To masz, kurna. To ekstremalny przykład, wiem.

Z kodem coś zawsze można zrobić jak się jest w takiej dup... jak duzy
schemat graficzny to tylko kupić dębowe pudełko i czekać.

do góry

W dniu sobota, 24 stycznia 2015 17:27:08 UTC+1 użytkownik Sebastian Biały napisał:


> > Przy dużych projektach, to jak se projektant pojedzie na ryby
> >, to ni Wuja po powrocie nie będzie wiedział po tygodniu o co mu chodziło i co
napisał.
>
> To kiepski programista jest. Bo kod ma byc łatwo czytać a nie pisać.
>

Hęęę..? Programista? Co Ty pier.....sz?
Zaprogramuj w np. TTL'ach for( i = 1; i <= 10; i++ )

Dla ułatwienia "zaprogramuj" to w FPGA - da się coś podobnego zrobić w opisie
strukturalnym (VHDL/Verilog).

W opisie behawioralnym np., multiplekser o dowolnej szerokości szyn wejściowych da
się opisać w paru linijkach kodu.

Strukturalnie, na bramkach też się da opisać. Na 8-mio bitowych danych, idę o zakład,
że za Wuja Wacka nie załapiesz opisu tak "od strzału"

Na schemacie, byle rzut oka i wszystko jasne.

================

A na Gruuubych projektach w opisie strukturalnym, to być się posrał.
Jak każdy. Ja też.

Amen.

do góry

W dniu 2015-01-24 o 17:27, Sebastian Biały pisze:
> On 2015-01-24 17:11, s...@g...com wrote:
>> Brak możliwości projektowania z poziomu graficznego (schemat).
>
> Uważaj. Projektowanie z poziomu kodu ma wiele zalet, że wymienie choćby
> testy. EDA obecnie oszalała na punkcie testowania i weryfikacji i cały
> impet rynku kierowany jest naweryfikację. Takie testy *NIE* projektuje
> się graficznie. Graficzne opisy są poprostu gówno warte w poważnych
> zastosowaniach (np. DO-254). Od czasu schematów wymyslono wiele technik
> programowania HDL dramatycznie podnoszacych jakość kiepskich języków
> opisu sprzętu (asercje, coverage, constrains, unit testy itd). Tak wiem
> że dla wielu legacy hardwareowców to jest zbiór bzdur bo najlepsze są
> druty i bramki. Życie.
>
>> Przy dużych projektach, to jak se projektant pojedzie na ryby
>> , to ni Wuja po powrocie nie będzie wiedział po tygodniu o co mu
>> chodziło i co napisał.
>
> To kiepski programista jest. Bo kod ma byc łatwo czytać a nie pisać.
>
>> Na schemacie zajęło by mu to góra godzinę.
>
> Mam dostęp do pewnego schematu. Jakieś 30 tyś przerzutników,
> multiplekserów, liczników itp drobnostek. Czyli godzinka, nie? No, chyba
> ze mowisz o mruganiu diodą. A, i bład jest "cztery metry po lewej i
> 17centymetrow od góry".
>
> Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
> opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
> schematem graficznym.

Wtrącę się troszkę chociaż ogólnie masz rację.
Schemat może być robiony hierarchicznie, więc da się podzielić pracą w
grupie.


--
pozdrawiam
MD

do góry

W dniu sobota, 24 stycznia 2015 17:27:08 UTC+1 użytkownik Sebastian Biały napisał:

>
> Uważaj. Projektowanie z poziomu kodu ma wiele zalet, że wymienie choćby
> testy.

Przestań!! Jak się na czymś nie znasz, to się nie mędrkuj. TestBenche istotnie pisze
się w dowolnym HDL, ale guano ma to wspólnego ze środowiskiem projektowym. O ile
oczywiście owo środowisko nie jest w stanie "wypluć" sieci połączeń i elementarnej
logiki w standarcie IEEE.

Tłumaczenie automatyczne sch=>hdl jest b. ważne, natomiast środowisko projektowe bez
sch jest o kant dupy rozbić.

Amen.

do góry