XILINX - VIVADO

W dniu 2015-01-24 o 17:11, snipped-for-privacy@gmail.com pisze:

[pac]

Quartus górą :)

@

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.

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

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

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

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

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.

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

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

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.

W dniu sobota, 24 stycznia 2015 18:52:44 UTC+1 użytkownik Mario napisał:

Słusznie!! Pomyśl i wyjaśnij!!

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

A plików tekstowych *NIE* trzeba dzielić. Od czasu systemów kontroli wersji z mergowaniem. I znowu schemat przegrywa.

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

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

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.

A czemu AC nie mogą robić Józek i Marek? Bo się *NIE* da? Coś Cię ogranicza?

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.

Po co mam opisywać multiplekser na poziomie bramek skoro poziom wyżej też się syntezuje i działa tak samo?

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.

Nawet w takich przypadkach zwykle programiści jednak dzielą się modułami i 3 z nich nie robi na raz zmian w jednej 5-linijkowej funkcji.

Ale faktem jest, że graficznemu podejściu brakuje wsparcia kontroli wersji.

W dniu sobota, 24 stycznia 2015 20:36:47 UTC+1 użytkownik Sebastian Biały napisał:

SystemVerilog istotnie może być ważny dla kogoś, kto pisze w Verilogu, kto pisze doktorat lub pracę habilitacyjną. Weryfikacja funkcjonalna działania projektowanego urządzenia jest istotna i bezdyskusyjna. Na wstępie z poziomu symulatorów.

Istotnie, na schemacie tego nie zobaczysz. Czego?! A na przykład constrais'ów. Bo i po co? Przecież byle student wie/powinien wiedzieć, że z projektem należy skojarzyć 'constraintsy'. A z drugiej strony, jest to ino kwestia edytora schematów. Istotnie, nie znam takowego, który wyświetlałby na schemacie 'constrains'y'. Chociaż.... Np. Altium ma taką możliwość.

Niczego nie odcinam. Piszesz tylko o debugowaniu. To zupełnie inna bajka niż projekt urządzenia. Istotnie, testbenche 'nasmarowane' graficznie, to jakieś SF.

Zaprojektuj latarkę, albo coś w tym stylu metodą opisową. Da się? Jasne, że się da!! I pokaż to dajmy na to 7-latkowi. Zrobi coś z Twojego "schematu"? Ni Wuja!!

Ciągle marudzisz o testach.. Też je robię, testbencze smaruję w VHDL'u, ale toplevel urządzenia robię hierarchicznie i z poziomu schematu.