NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Vivado od Xilinx Dlaczego brak graficznego projektowania to klapa w dużych systemach?
Guest
Sat Jan 24, 2015 6:11 pm
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).
Artur Miller
Guest
Guest
Sat Jan 24, 2015 6:11 pm
W dniu 2015-01-24 o 17:11, stchebel@gmail.com pisze:
Quote:
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ą :)
@
Sebastian Biały
Guest
Guest
Sat Jan 24, 2015 6:11 pm
On 2015-01-24 17:11, stchebel@gmail.com wrote:
Quote:
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.
Quote:
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 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ć.
Quote:
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 ...
Pszemol
Guest
Guest
Sat Jan 24, 2015 6:11 pm
"Artur Miller" <nomail@nomail.com> wrote in message
news:ma0gsh$f2g$1@usenet.news.interia.pl...
Quote:
Quartus górą 
Żeby tylko im nie wpadło do głowy wyrzucić graficznego
trybu w następnych wersjach...
Pszemol
Guest
Guest
Sat Jan 24, 2015 6:11 pm
<stchebel@gmail.com> wrote in message
news:35f2f587-9fb6-431e-a815-aaac52ce115b@googlegroups.com...
Quote:
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ę.
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.
Pszemol
Guest
Guest
Sat Jan 24, 2015 6:11 pm
"Sebastian Biały" <heby@poczta.onet.pl> wrote in message
news:ma0h4r$5a8$1@node2.news.atman.pl...
Quote:
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".
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.
Sebastian Biały
Guest
Guest
Sat Jan 24, 2015 6:11 pm
On 2015-01-24 17:38, Pszemol wrote:
Quote:
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.
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ć.
Mario
Guest
Guest
Sat Jan 24, 2015 6:52 pm
W dniu 2015-01-24 o 17:27, Sebastian Biały pisze:
Quote:
On 2015-01-24 17:11, stchebel@gmail.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.
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
Guest
Sat Jan 24, 2015 7:43 pm
W dniu sobota, 24 stycznia 2015 17:27:08 UTC+1 użytkownik Sebastian Biały napisał:
Quote:
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ć..
, 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.
Guest
Sat Jan 24, 2015 7:53 pm
W dniu sobota, 24 stycznia 2015 17:27:08 UTC+1 użytkownik Sebastian Biały napisał:
Quote:
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.
Guest
Sat Jan 24, 2015 8:20 pm
W dniu sobota, 24 stycznia 2015 18:52:44 UTC+1 użytkownik Mario napisał:
Quote:
Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
schematem graficznym.
Słusznie!! Pomyśl i wyjaśnij!!
Quote:
Wtrącę się troszkę chociaż ogólnie masz rację.
Schemat może być robiony hierarchicznie, więc da się podzielić pracą w
grupie.
Guzik ma rację. Też projektuję hierarchicznie. Dlaczego? Bo jeden rzut oka na malunek. Antek robi syfrówę, Józek przetwornik AC, Zenek robi FPGA, Zocha robi PCB.
Rzut oka i wszystko jasne!! Mogę dla jaj podesłać swój projekt FPGA w postaci VHDL - strukturalny + niektóre podzespoły behavioralnie. Te drugie to raczej załapiecie prawie od strzału.
Zaś pierwsze..., ni wuja !! Sam po tygodniu przerwy mam z tym problemy. Na grafice, wystarczy godzinka...
Sebastian BiaĹy
Guest
Guest
Sat Jan 24, 2015 8:27 pm
On 2015-01-24 18:52, Mario wrote:
Quote:
Schemat może być robiony hierarchicznie, więc da się podzielić pracą w
grupie.
grupie.
A plików tekstowych *NIE* trzeba dzielić. Od czasu systemów kontroli
wersji z mergowaniem. I znowu schemat przegrywa.
Sebastian Biały
Guest
Guest
Sat Jan 24, 2015 8:36 pm
On 2015-01-24 18:53, stchebel@gmail.com wrote:
Quote:
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
testy.
Przestań!! Jak się na czymś nie znasz, to się nie mędrkuj. TestBenche istotnie pisze się w dowolnym HDL
Przegapiłeś ostatnie jakieś 10 lat. Zadanie domowe z googla:
SystemVerilog i UVM. Przed UVM było trochę innych. I bedzie pare
nastepnych, prawie na 100%. Dynamika tu jest kosmiczna.
I powtarzam: nie tylko gołe testy. Asercje, contrains, randomizacje,
TLM. To jest pisane w HDLu i *WPLATANE* w kod. Bo asercja jest naturalną
częścią kodu. W schemacie nie masz możliwosci postawienia głupiej
asercji. Odcinasz w ten sposób bardzo ważne mechanizmy zwiększające
jakość i ulatwiające debugowanie.
Świat naprawdę zna lepsze metody opisu elektroniki na dowolnym poziomie
od tranzystorów po transakcje. Lepsze od schematów. Naprawdę.
Quote:
, ale guano ma to wspólnego ze środowiskiem projektowym
*NIE* jest to takie proste. Miało kiedyś. Przez ostatnie 10 lat wiele
się zmieniło. Ewentualnie engine zbierający wyniki może mieć formę
środowiska. Testy obecnie pisze się w tym samym języku co implementację,
akurat taka moda. Obecnie na topie jest SystemVerilog. Jutro pewnie coś
głupszego od veriloga choć nie wiem czy nie osiągnięto już dna.
Sebastian Biały
Guest
Guest
Sat Jan 24, 2015 8:44 pm
On 2015-01-24 19:20, stchebel@gmail.com wrote:
Quote:
Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
schematem graficznym.
Słusznie!! Pomyśl i wyjaśnij!!
opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
schematem graficznym.
Słusznie!! Pomyśl i wyjaśnij!!
Dla schematow nie dorobiliśmy się jeszcze sensownych:
a) wygodnego komparatora zmian (niezbędne przypracy zespołowej)
b) wygodnej metody łaczenia zmian wykonywanych przez różnych developerów
(niezbedne przy pracy zespołowej)
c) środowisk które pozwalają te operacje zintegrować z systemami
kontroliwersji
d) formatu pliku który jest przyjazny dla systemów kontroli wersji
e) wygodnego edytora (90% znanych mi edytorów schematów nie ma
funcjonalności rozpychania elementów czy automatcznego routingu drutów,
a to tylko mały kawałek braków)
f) wsparcia dla konwersji hdl->sch która nie robi kupy
Jesli chodzi o edytowanie schematów to mamy gdzies okolice
średniowiecza. Bez względu na cenę jaką płaciszza software. Złożonośc
problemu jest ogromna. I nie warta ceny.
Quote:
Antek robi syfrówę, Józek przetwornik AC, Zenek robi FPGA, Zocha robi PCB.
A czemu AC nie mogą robić Józek i Marek? Bo się *NIE* da? Coś Cię ogranicza?
Sebastian Biały
Guest
Guest
Sat Jan 24, 2015 8:54 pm
On 2015-01-24 18:43, stchebel@gmail.com wrote:
Quote:
Zaprogramuj w np. TTL'ach for( i = 1; i <= 10; i++ )
Tego się nie programuje. To się syntezuje. Innymi slowy wynik tej
syntezy może być diametralnie różnyw zalezności od tego co jest w środku
pętli. I być może niemożliwy.
W ogólności jeśli ktoś w FPGA zamierza liczyć silnie za pomocą
rekurencji to jest idiotą. Tylko co z tego wynika w dyskusji nad
kiepskością schematów w HDL? Na schemacie tej pętli nie zrobisz. LabView
probował - kupa wyszła.
Quote:
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"
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"
Po co mam opisywać multiplekser na poziomie bramek skoro poziom wyżej
też się syntezuje i działa tak samo?
Quote:
Na schemacie, byle rzut oka i wszystko jasne.
Na te kilkaset bramek? Gratuluje. Kolesie od weryfikacji formalnej
hardware mają czasem problem z podobną skalą komplikacji. Ale oni mają
zazwyczaj tylko 8 rdzeni po 5GHz i kilka godzin pracy kompa.
elektroda NewsGroups Forum Index - Elektronika Polska - Vivado od Xilinx Dlaczego brak graficznego projektowania to klapa w dużych systemach?