Nauka programowania FPGA

No wlasnie nie widze sensu, mialy te zalete, ze kiedys je w miare dobrze znalem, wiec szansa popelnienia bledu mniejsza, ale ... po co sie ograniczac ...

Hm, jakbym tak uzyl konkretnego TTL ... nie musialby uwzglednic szczegolow jego budowy, ktore w danym projekcie sa calkowicie nieistotne, alevon o tym nie wie, a zamodelowane ma (dla starych inzynierow) ?

I to brzmi sensownie.

J.

Użytkownik stchebel napisał w wiadomości grup dyskusyjnych: snipped-for-privacy@googlegroups.com... W dniu czwartek, 8 lutego 2018 21:25:45 UTC+1 użytkownik Sebastian Biały napisał:

A po co im wiedziec jak dziala dioda ?

Oni sa od projektowania ASIC, i maja placone np za wiedze jak dziala dekoder MPEG.

J.

Jednym z powodów dla których tak cieżko przyjmują sie arduino na ARMach jest brak peryferiów obsługuących 3.3V. Niektore wyświetlacze nie dzialają z 3.3. Niektóre uklady I2C nie działają. itd itp. Lista jest dośc spora. Sytuacje poprawi upowszechnienie się innych klonów Arduino. Obecnie perferia działające z 3.3V sa w mniejszości.

Co nikomu nie ogranicza uzywania lutownicy, buforów, rezystorów i czegokolwiek tam sobie wymyślą. Tylko że to jest dodatkow *trudnośc*. CPLD zdejmuje to brzemię i pozwala skupić sie na problemie a nie na detalach działania układów wejściowych. Tu nie ma mowy o wyższości CPLD nad FPGA, tylko o kosztach startu w tym temacie. CPLD jest tańszy z wielu powodów, od kosztu układów, przez peryferia po oprogramowanie (tutaj kosztem jest absurdalny rozmiar współczesnych środowisk)

Widzisz, z miejsca gdzie siedzę zawodowo widać bardzo duzy kawałek rynku EDA od środka. Powiedzmy że wiem co jest obecnie stosowane na świecie i jakie techniki zarzadzania jakością stosowane są w dużych firmach zatrudniających tysiące programistów HDL. Jeśli wydaje Ci się że ktokolwiek z nich rysuje schematy w dyzych projektach to po prostu nie zauważyleś postepu. Owszem, rysuje się schematy w duperelowatych przypadkach migania dioda czy zrobienia jakiegoś bufora z DRAM i sporadycznie rysuje się schematy kiedy managerem jest Stasiek. Jesli chodzi o elektronikę dużej skali i cieżkich parametrów (lotnictwo, medycyna, wojsko) mozna tylko parsknąć śmiechem. Wszystkie, powtarzam, wszystkie duże firmy stosują zupełnie inne metody zarzadzania jakoscią niż armia Staśków gapiący sie w druty. Nawet nie zdajesz sobie sprawy jak wiele wydarzyło się w ostatnich 10 latach w tej dziedzinie i jak bardzo dramatycznie podniesiono wymogi jakościowe. W zasadzie cały proces obrotu pieniedzmi w EDA skupia sie obecnie na weryfikacji a nie na projektowaniu. Projektowanie jest trywialne wobec weryfikacji.

Mentalnie tkwisz ciagle w latach 60-tych. W międzyczasie HDL nabrały prawie wszystkich technik programistycznych z normalnego programowania, w szczególności wielu pojęć z Inżynieri Oprogramowania, jak rownież języki zmieniły się dramatycznie przypominając duże jezyki obiektowe. Takie rzeczy jak obiektowe uni testy, randomizacje, farmy regresyjne, weryfikacja formalna, śledzenie wymagań, kontrola wersji, wzorce projektowe, code review są *CODZIENNOŚCIĄ* w tej branży i pojawiły się tam głównie dlatego że Staśków jest mniej, za to więcej ludzi rozumiejących po co to wszystko wymyślono w programowaniu i dlaczego generuje to zysk i jakość. To że został na świecie jakiś Stasiek co uważa że gapienie się w druty rozwiązuje te problemy to nic nie można poradzić. Świat bez Staśka będzie taki sam.

Nie masz pojęcia co krytykujesz. Nie wiesz co jest obecnie stosowane w EDA bo siedzisz od 30 lat w tym samym minimum lokalnym potrzeb robiąc swoje miganie diodami i bufory w DRAM. Nie ma sensu dyskutować o tym że można inaczej bo sila przyzwyczajenia jest ogromna. Pozwól jednak że porechoczę nieco słysząc opinie jednego misiaczka co gapi się w druty na temat rynku światowego co go na oczy nie widział. Zatrudnij się w większej firmie z rynku EDA, nawet w PL, zobaczysz na własne oczy jak się wychodzi z jaskini i gdzie świat jest obecnie. Raczej nie w rysowaniu schematów. Świat EDA w ostatnich 10 latach przeżył rewolucję na skale absurdalną. Przykro mi że przesiedziałeś ją w jaskini. Wielu w tej branzy nie wytrzymało tempa. Nie dziwie się, nauczenie się obiektowości kiedy przez 30 lat rysowało się miganie diodą uważając to za szczyt umiejętności bywa okrutnie trudne.

I pamiętaj, ignorancja nie jest siłą.

Świat również wymyślił coś takiego jak ISO xxxx. System zarządzania jakością:) Cały ten pierdolnik powstał tylko po to, by dać naprawdę duże zarobki i możliwości łapówkarstwa dla totalnych nieuków i nierobów.

No to teraz trzasnąłeś jak łysy grzywką o krawężnik. Po pierwsze, akurat zajmuję się diagnostyką medyczną. Piszesz, że projektowanie jest trywialne wobec weryfikacji... Ów Stasiek gapiący się na druty zaprojektował ultrasonograf, który oczywiście w swojej klasie powala np. Toshibę (modelu nie podaję z premedytacją). I nie jest to tylko subiektywna opinia Staśka. Wracając do tematu schemat/HDL, popatrz tutaj:

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; library UNISIM; use UNISIM.VComponents.all;

entity bmod is Port ( A : in STD_LOGIC_VECTOR (15 downto 0); CLK : in STD_LOGIC; C : out STD_LOGIC_VECTOR (15 downto 0)); end bmod;

architecture Behavioral of bmod is type Rejestr_Type is array (63 downto 0) of std_logic_vector(15 downto 0); signal Cs:std_logic_vector(21 downto 0):=(others=>'0'); signal Rejestr:Rejestr_Type; shared variable Suma:integer;

begin

process(CLK) begin if rising_edge(CLK) then Rejestr<=Rejestr(62 downto 0)&A; Suma:=0; for i in 0 to 63 loop Suma:=Suma+to_integer(signed('0'&Rejestr(i))); end loop; Cs<=std_logic_vector(to_unsigned(Suma,22)); end if; end process; C<=Cs(21 downto 6); end Behavioral;

Co to robi? Mam nadzieję, że dasz sobie z tym radę, ale napisz tak szczerze.. Ile czasu zajęło Ci zrozumienie powyższego?

Taaak... Mentalnie jestem w latach '60:)) ISOxxxx wymaga rozwieszania nawet po kiblach banerów "Jakość jest dla nas najważniejsza":)) NIE ŻARTUJĘ!! Coś w stylu "PZPR przewodnią siłą Narodu". Baa.. Mało tego.. Świat poszedł tak do przodu, że wymyślił RoHS. Stasiek też jakoś jest w tym temacie zacofany, bo uważa że jest to o kant dupy rozbić. W temacie długości śledzi i kształcie bananów też jestem zacofany :))

Siłą jest RoHS, kursy zarządzania jakością, byle sprzedać badziewie... Dlaczego gary Zeptera są droższe od tych z byle marketu, chociaż te z marketu są zrobione ze stali nierdzewnej? No ba.., bo te od Zeptera są ze stali szlachetnej :))

W dniu czwartek, 8 lutego 2018 21:38:44 UTC+1 użytkownik Sebastian Biały napisał:

Układy mnożące i konfigurowalny RAM nie są niczym dziwnym. Mentalnie jesteś w latach '60-tych.

Czyli skala migania diodą. A więc nic nie rozumiesz z tego gdzie obenie jest rynek EDA.

Nikt tego nie wie.

Po pierwsze nie masz specyfikacji i śledzenia wymogów.

Po drugie nie masz unit testów bądzie jakichkolwiek innych testów pozwalających okresli co to NAPRAWDĘ robi.

Kazdy kto patrzy na kod ktory nie posiada TESTÓW i ma być stosowany w medycynie pierwsze co zrobi wyrzuci do koszta. Masz testy? Tak działa obecnie świat. Możesz oczywiście groźnie i komicznie tupać nogą stawiając słowo honoru ponad fakty.

Ktoś kto przychodzi do Staska z pytaniem czy może mu zaprojektować demodulator AM zakłada że Stasiek poza tym że jest zajebisty ma jeszcze dowody formalne na takie twierdzenie. Sporo się zmieniło od czasu kiedy Staśki projektowały następne sterowniki zegarków szkolnych.

Kompletnie nie rozumiesz o czym tutaj piszę. Mogę Ci przedstawić dowolny kawałek kodu z dowolnej dziedziny i tez naprężać mięśnie że nic z tego nie pojmiesz. A ty jak zwykle jesteś ignorantem któremu świat uciekł kilkanascie lat do przodu i dalej starasz się każdego pouczać o tym że w średniowieczu pisali tak a tak. Przegrałeś nascie lat rozwoju EDA, nie będziesz już w stanie tego nadgonić. Pozostanie tylko miganie diodami i pouczanie na grupach.

Niz poza pustymi sloganami nie masz aby temu zaprzeczyć. Prawdopodobnie to wyniak z faktu że kręcisz się w miniaturowych projektach i nie rozumiesz z jakimi problemami musi się zmierzyć Qualcomm produkując swoje zabawki.

Ani jeden z moich argumentów nie mowi nic o ISO. Aczkolwiek większość branż krytycznych przy projektowaniu wymaga wielu ISO a wiele z tych ISO to własnie opisy metodyki testowania i projektowania. Nie ma ISO mówiącego o kilkunastu Staśkach gapiących sie w druty. Za to znajdziesz np. wymogi konkretnego coverage. Nie spelnisz ich i milionem Staśków. Właśnie wylądowaleś w niszy migania diodami.

Nie przypominam sobie aby w firmach EDA wisiały transparenty o zajebistości czegokolwiek. Widocznie nie mają tego ISO. Widze natomiast ludzi którzy potrafili wyjśc z bycia Staśkami, czasem dużym kosztem, ale zawsze z zyskiem.

Bredzisz już od rzeczy. To w sumie smutne patrzeć na to jak ktoś swoją niewiedzę i archaiczne zachowania stara się wypromować jako zalety. Nie masz pojecia o rynku EDA. Nie wiesz co się obecnie robi, jakimi metodami, jakimi ideami, jakimi skalami. Potrafisz tylko hejtować wszystko czego nie ogarniasz. A ogarniasz jak widać niewiele z współczesnego świata. Pustka, tylko wiatr świszczy.

W przecietnym CPLD je ciezko znaleźć, ale to kwestia cięcia cytatów.

A czy ma to znaczenie nazwa firmy tyou Qualcomm czy Samsung?? Co umie spieprzyć Qualcomm czego by nie umiał np. Samsung?

Rożnica jest w tym czy to jest Qualcomm ze swoimi CPU czy Stasiek ze swoim demodulatorem AM. Roznica jest w skali. W małej skali, duperelowatych projektów do migania diodą, rysowanie schematów nigdy nie zniknie. Za dużo tam Staśkow. W firmach które mają 1000 x większą skalę zagadnienia zapewne by umarli ze śmiechu gdyby ktoś przyjmował się do roboty z 30 letnim stażem elektronika HDL i nie znał pojęć takich jak regresja, testowanie, coverage, dowodzenie formalne, farmy regresyjne itp. Oni tam być może potrzebuja paru magików od oglądania drutów, ale pozostały tysiąc programistów robi to inaczej, czerpiąc calymi garściami z rynku software wliczając w to obiektowość (tak, jest na to niesłychane parcie w SystemVerilogu, pozostawie jako zagatkę dla ciekawskich czy to się syntezuje i po co to w ogóle). Od dziesięciolecia dostepne to dla Kowalskich a w duzych firmach wypracowano to wczesniej. Czasy kiedy projektowało się 6502 na duzym arkuszu papieru sa słusznie minione ale niektorzy dalej to robią. I robić bedą. Nie kazdy musi robić od razu duże projekty. Sprzedanie dzisiaj IP Core na rynku poważnym bez wsparcia w postaci calej inzynierii programowania jest mocno utrudnione. Wszyscy muszą spelniać jakieś wymogi i ich dostawcy również. Obecnie wymogi pod względem weryfikacji pofruneły w kosmos. Kto nie zdążył się dostosować, przegrał.

Często kierujesz modły do kapitana Obviousa, a sam masz problem z przeczytaniem ze zrozumieniem trzech wyrazów. Masz je w tytule wątku. Czy ktoś tu w ogóle zadał pytanie o to, jak należy zorganizować firmę złożoną z kilkuset programistów HDL i z jakimi problemami się wtedy spotka? Czy chociaż poprosił o pomoc w zorganizowaniu jednoosobowej działalności gospodarczej, mającej się zajmować HDL? Nie, człowiek sobie chce pomigać diodą i dostał kilka propozycji, jak pomigać diodą. To Ty nie wiadomo skąd wyskoczyłeś z komentarzem "schematy są do dupy, bo wielkie fabryki odchodzą od schematów." A kogo to, do jasnej cholery, obchodzi, niezależnie od wątpliwej wartości merytorycznej tego stwierdzenia? Nie budujemy tutaj fabryki i nam tematyka continuous delivery kompletnie wisi. Wygłupiłeś się, ale przerośnięte ego nie pozwala Ci się do tego przyznać, więc obrażasz pozostałych dyskutantów i wygadujesz bzdury o Qualcomach i Samsungach. Szkoda, bo do dziś miałem Cię za naprawdę rozsądnego gościa.

Będziemy to mieli na uwadze, w domowym zaciszu migając sobie diodą. Jak tylko projekt wróci z farmy regresyjnej, zrobimy sobie jednoosobowy daily standup i zweryfikujemy formalnie wartość opornika.

Piotr

Dyskusja już dawno nie jest ściśle w tytule wątku.

Nie, ale ktoś bezczelnie postarał się wykazać swoją ignorancję nazywając testy regresyjne i systemy kontroli wersji pieprzeniem. Zazwyczaj to ten sam ignorant który krytykuje wszystko czego nie ogarnia i co jest nowsze niż 50 lat. Jeszcze ktoś przeczyta i nie daj Boże pomyśli że to prawda.

Rozumiem że jesteś rodzajem szeryfa który za każdym razem jak ktoś rzuci dygresję nie na temat wątku to chcesz walić w łeb? Określiłem długowfalowy trend przemysłowy. To o tyle istotne że jak ktoś zapyta na innej grupie "jakiego języka warto się uczyć" to odpowiedź "Delphi" jest debilna bo bez przyszłości choć bez wątpienia do hello worldów ciągle się nadaje, tylko po h... tego używać. Może warto sobie zdawać sprawę że rysowanie schematów nie ma przyszłości poza niszami. Do migania diodą jak znalazł. Do większych rzeczy nie. Można się spierać gdzie jest granica. Zaryzykuję że w zerze. Innymi słowy nie warto nawet do migania diodą brać schematu bo nie ma zalet a "lepiej widać" to tylko subiektywność.

(na marginesie: istnieje coś takiego jak flow danych. Tam stosuje się schematy ale w innym celu: w celu wizualizacji kodu w HDL jako narzędzie do debugu. Innymi słowy sa generowane z kodu HDL i ma to sens. Sa też generujące kod ze schematu jednak tutaj tracą się prawie wszystkie "nowoczesne" techniki weryfikacji projektu i zarządzania jakością)

Okazuje się ze obchodzi, w dodatku strasznie zabolało.

, niezależnie od wątpliwej

Możesz tą wątpliwość uzasadnić. Tylko prosze nie na podstawie nastu pudełek z kilkudziesięcioma drutami choć i tam można trywialne wykazać żałosne wady tego rozwiązania.

Możesz to wykazać kontrargumentacją.

(na marginesie: nigdzie nie pisałem o continous delivery, pisalem o weryfikacji a to robi się na projektach do migania dioda tak samo jak na projektach cpu)

Przykład: Posiadanie w domu systemu kontroli wersji jest rzeczą oczywistą i naturalną, nawet do projektów hobbystycznych. Wciskanie do niego schematow jednakże jest wyjątkowo zabawnym i pełnym przygód doświadczeniem z dziedziny wkładania kwadratowych klockow w trójkatne dziurki. Efektem czego kilku znajomych, co te schematy ukochało, systemów kontroli wersji nie stosuje "bo nie działa i w ogóle to gówno jest" jak usłyszałem przepełnioną ignorancją tezę jednego z nich. A to tylko jedno, najbardziej trywialne narzędzie, z całego spektrum narzedzi stosowanych w EDA ktore nie mają sensu w przypadku schematów.

W czym ono się wyraża? Na informowaniu o faktach bądz walczeniu z ignorancją?

Najzwyczajniej i Ciebie zabolało że schematy nie są topowoym osiągnięciem ludzkości i masz problem z akceptacją że reszta świata się tym nie bawi na poważnie. Wszyscy tylko gadaja o tych glupich UVMach, regresjach, randomizacjach, farmach, specyfikacjach i innych bzdurach zamiast jak "za naszych czasów" rysować schemty na TTLach. No niestety tak wygląda świat. Można to oczywiście ignorować. Nie ma przymusu.

Udowodnij że to bzdury poprzez wyjasnienie grupie co tak naprawdę robią duże firmy projektujace ASICe. Skoro to bzdury to powinno być na najbliższych targach EDA miliard stoisk z oprogramowaniem do rysowania schematów z narzedziami pozwalającymi ogarniać miliony pudełek i setki milionów drutow. Zacznij też przy okazji od wykazania gdzie napisałem słowo "Samsung" w tym wątku.

Być może nie dostrzegasz faktu że ktoś może widzieć rynek EDA nieco szerzej i nieco bardziej od środka niż z małej firemki na zadupiu PL robiące miganie diodami. Byc może wieloma diodami i być może wieloma przerzutnikami, ale to ciągle skala 1000x mniejsza niż trend przemysłowy. A trend przemysłowy tworzy rzeczywistość i narzędzia których nie sposób zignorować na jakimś etapie bo w końcu trafią i do hobbystów i małych firm. W zasadzie już trafiły tylko tu i tam jeszcze nie zauważyli.

I dalej tłuczesz sie w temacie wątku kiedy już dawno nie o tym.

Ale żeby nie było: początkujący ma zawsze problem. Jesli wdepnie od razu w bagno bez wyjścia to istnieje niezerowa szansa że mu już tak zostanie. Może powinien mieć świadomość że rysując schemat uzywa technologii która jest w odwrocie, a w zasadzie jest niszowa, z dead end. Podobnie jak Delphi, co nie zmienia faktu że ma wielu gorących zwolenników gotowych umrzeć za honor obrony dobrego imienia "nastepnego martwego języka" trolując w niebogłosy na sąsiednich grupach jak im tylko przypadkiem na odcisk nadepnąć.

Realistyczne spojrzenie na swoją pracę bywa bolesne, więc zrozumiała jest reakcja obronna. Nic nie poradzę.

Jakb mawiał Norwid "Bardzo mi z tego przyjemnie ale..." co z tego postępu od 50 lat skoro np. najnowszy tv Samsunga potrzebuje "nagrzać lampy" tak samo jak rubin sprzed 35 lat?? Wtedy user musiał czekać i teraz musi czekać. Taka cywilizacja "proszę czekać". Inny mój ulubiony przykład, na przestrzeni ostatnich lat mimo rotacji urządzeń NIE spotkałem się aby zestaw słuchawka BT- urządzenie działało zawsze bez problemu, zawsze jest lwqurwisjaca loteria czy się podłączy czy nie. Nie umieją tego zrobić. Więc co z tych mądrych testów, unitów, urewow, rrerwow, qrewow* skoro i tak końcowy produkt nie działa, tak jak się tego oczekuje?

"- tak już offtopicznie zupelnie. Mam koleżankę, która zarządza w pewnym corpo tamtejszym środowiskem qrew. Na spotkaniach przy przedstawianiu mina gości bezcenna (szczególnie u kogoś z tzw. biznesu) .

Może jest świeżo po jakimś korposzkoleniu czy jak to się tam nazywa :)

jp

Jaki to ma związek z FPGA? To tylko dziadostwo programistów embedded.

Ponieważ konsument końcowy glosuje portfelem co w tym przypadku oznacza że kupi ładne, ale niekoniecznie dobre.

Tak na marginesie kiedys zapytałem czemu mój telewizor wstaje 10 sekund. Dowiedziałem sie (na tej grupie) że jądro systemu musi znaleźć sobie wszystkie perfyferia. MUSI bo przecież jak inaczej. Innymi slowy widać tutaj wlasnie *dyletanta* który nie jest w stanie dostarczyć oprogramowania o sensownej jakości bo programiści embedded ciągle nie słyszeli o milionie rowiązań tego problemu tylko stosują te same dziadostwo to samo co zawsze i co gorsza sa na świecie ludzie którzy nie widza w tym żadnego problemu.

Pytasz więc dlaczego rynek oprogramowania (w tym i HDL) jest taki gówniany. Bo ludzie gówniani, niereformowalni, zacofani, niedouczeni, religijni. Skoro jusz takie dygresje: odpalasz aplikację olx na androidzie i mam zatrzymania GUI na 5 sekund kiedy aplikacja przetwarza w tle jakieś zapytania. Miałem lepsza responsywnośc na 7MHz na Amidze. Dyletanctwo, dziadostwo. Jest wszechobecne.

Dlatego w HDL masz obecnie taki nacisk na weryfikację. Aby te całe stada dyletantów były zmuszone dostarczyć implementację spelniającą specyfikację *mimo* wszystko. A to że specyfikacja nie kładzie nacisku na wydajność to należy rozmawiać z księgowymi.

Nijak to wszystko jednak nie zmienia ogólnych trendow. Można tuptać nerwowo nogą, wymachiwac rekoma a świat idzie dalej w kierunku który raczej nie ma związku ze schematami poza kilkoma niszami.

W dniu 2018-02-11 o 11:12, Sebastian Biały pisze:

Nie mam zamiaru nic robić w FPGA ale mnie zainteresowało jak wygląda proces robienia np. procesora z akceleratorem grafiki. Załóżmy że dzwoni prezes i mówi: zróbcie mi procesor 8 rdzeni z grafiką. Co się dalej dzieje? W IT na ten przykład diagramy jednak się stosuje np. UML i BPML. Fakt że program z nich nie powstanie, ale żeby pokazać co ma powstać i jak ma działać jednak są lepsze niż sterty tekstu.

Dnia Sun, 11 Feb 2018 12:32:28 +0100, Piotr Dmochowski napisał(a):

Wyciaga ktos projekt procesora, projekt akceleratora, dopisuje jak sa polaczone i mowi "nasz dzial zakonczyl".

To polaczenie moze nie byc takie proste, jak sie okaze ze np oba musza intensywnie korzystac z pamieci SDRAM

ARM np zadnych procesorow nie robi

W sytuacji gdy sprawdzony projekt procesora masz, i sprawdzony projekt akceleratora - to co tu rysowac ?

Marketing sobie narysuje, zeby klienta zachecic :-)

J.

W dniu 2018-02-11 o 13:47, J.F. pisze:

Ok, ale jak nie ma jeszcze nic? Chodzi mi właśnie o sytuację że startujemy z pusta kartką, znaczy się z pustym repozytorium ;) Nie każdy ma szansę pracować w dużym korpo i skoro jest okazja się czegoś dowiedzieć to ciągnę za język :)

Pomijając cała masę dupereli związanych z badaniem rynku, najpierw pojawia się specyfikacja.

Specyfikacja ma wiele poziomów. Od ogólnego "zróbcie mi cpu na osiem rdzeni", przez specyfikację dotyczącą architektury, przez spodziewane parametry po procesy technologiczne. Kto to robi i jak to wygląda - nie mam wglądu, przypuszczam że wiele z etapów bazuje na wczesniejszych projektach więc od zera tego nie robią.

Specyfikacja nie jest w EDA specyfikcją jak zazwyczaj w programowaniu. Jesli w specyfikacji jest punkt: 4.6.8.9.18.1 mowiący o tym że instrukcja HCF ma robić to i tamto to w procesie implementacji: a) znajdziesz dokładnie miejsca w kodzie gdzie jest zaimplementowana (śledzenie specyfikacji) b) znajdziesz raporty z testowania tej instrukcji c) znajdziesz raporty z coverage tego testowania d) znajdziesz dokładnie opisane co jest a co nie do zaimplementowania e) znajdziesz w końcu kolorowe słupki pozwalające śledzić stopień zaawansowania implementacji tego ficzera. f) programista ma do dyspozycji cała maszynerie testowania regresyjnego pozwalająca mu refaktorować ten kawałek hardware tak aby nie naruszyć wymagań i nie generować regresji.

W przypadku duzych projektów punkt e) nie jest wcale śmieszny, jest prawdziwym wyzwaniem zarzadzać milionami zalożeń w specyfikacji i oceniać na jakim etapie jest projekt. Złe oszacowanie powoduje straty miliardów dolarów.

W EDA popularne są ostatnio automaty do okreslania stopnia realizacji specyfikacji. To nie to samo, specyfikacja nie zawsze okresla jak zrobić, określa jak ma działać. Różnica jest taka ze ten automat dba o to aby nie zapomnieć o jakimś punkcie. Pozwala to firmie zarządzać dynamicznie procesem produkcji przemieszczając programistów tam gdzie czegoś brakuje. Dzięki temu że dany kawałek hardware jest silnie przetestowany nie musisz wiedzieć nic o resztcie systemu aby refaktorować bądź kontynuowac pracę w jakims miejscu. Duze projekty realizowane są często przez poziom zblizony do unit testów.

Ogolnie można powiedzieć że pojawia się coraz więcej narzedzi pozwalających pisać mniejsze i perfekcyjnie wytestowane kawalki kodu co przypomina nieco dązenie do utopijnej implementacji aplikacji poprzez programowanie z użyciem tylko unit testów. Integracja tez jest istotna, ale jest drugim etapem.

Pamiętaj też że rynek EDA jest ekstremalnie zamkniety, firmy praktycznie nie zdradzają swoich sekretow, czesto przekroczenie drzwi wymaga podpisania NDA. O procesie produkcji w wielu znich niewiele wiadomo

Z punktu widzenia projektu najcenniejsze są testy i proces weryfikacji. Testy pisane sa zgodnie ze sztuką zazwyczaj przed pisaniem implementacji. Jest do tego ogromna ilośc frameworków, wiele z nich czerpie pełnymi garściami z programowania obiektowego (ba, powstał do tego specjalny język E który był czymś w rodzaju eksperymentu i idee przenikneły do SystemVeriloga).

Jesli chcesz zobaczyć jakąś konkretna implementację takiego procesu prodkucji CPU to nie ma mozliwości innej jak zatrudnić się w firmie to robiącej. Nikt nie chwali się swoimi rozwiązaniami publicznie. Jednak z faktu kto jest czyim klientem wynika jakiego uzywają software. I to wiele mówi o tym jak wygląda obecnie produkcja hardware i jakie metody tam stosują.

Nie wykluczam że ktoś tam implementuje wypasione CPU używając schematów, ale nie słyszałem. Nawet chińskie firmy nie widzą sensu stawiania miliona chińczyków szukających buga w drutach.