Podstawy programowania FPGA z zestawem Elbert v2 VHDL czy Verilog?

Sat Feb 10, 2018 1:55 pm   

W dniu piątek, 9 lutego 2018 21:16:46 UTC+1 użytkownik Sebastian Biały napisał:

Ś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:

http://imagizer.imageshack.us/a/img923/5962/Pjm3pT.jpg

To jest demodulator AM. Ma do zrobienia sqrt(I^2+Q^2). Prawda, że na pierwszy rzut oka wiadomo o co chodzi? W postaci HDL całość tego? No problem, jedno kliknięcie i jak sobie tego życzysz dostaniesz wersję strukturalną w VHDL/Verilog. Do wyboru, do koloru.. Tyle, że zanim zrozumiesz o co w tym chodzi, spędzisz ładnych parę godzin. Jest tam też klocek "bmod". Opis behawioralny :

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 )

Sat Feb 10, 2018 2:24 pm   

On 2/10/2018 12:55 PM, stchebel@gmail.com wrote:

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.

Sat Feb 10, 2018 2:45 pm   

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.

Sat Feb 10, 2018 3:15 pm   

On 2/10/2018 1:45 PM, stchebel@gmail.com wrote:

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

Sat Feb 10, 2018 4:30 pm   

On Sat, 10 Feb 2018 14:24:01 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

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

--
Marek

Sat Feb 10, 2018 5:15 pm   

On 2/10/2018 4:30 PM, Marek wrote:

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

Sat Feb 10, 2018 10:53 pm   

Sebastian Biały wrote:


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

Sun Feb 11, 2018 12:56 am   

On 2/10/2018 10:53 PM, Piotr Wyderski wrote:

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

Sun Feb 11, 2018 8:07 am   

On Sun, 11 Feb 2018 00:56:07 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

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

--
Marek

Sun Feb 11, 2018 10:18 am   

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

jp

--

www.flowservice.pl
www.flowsystem.pl

Sun Feb 11, 2018 11:12 am   

On 2/11/2018 8:07 AM, Marek wrote:

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.

Sun Feb 11, 2018 12:32 pm   

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

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.

--
Pozdrawiam
Piotrek

Sun Feb 11, 2018 1:47 pm   

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

http://www.zipcores.com/
Ci to jacys niskopoziomowi sa, nie oferuja ani procesora, ani
akceleratora :-)

ARM np zadnych procesorow nie robi
https://www.arm.com/products/processors


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

Marketing sobie narysuje, zeby klienta zachecic :-)


J.

Sun Feb 11, 2018 3:07 pm   

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

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 :)

--
Pozdrawiam
Piotrek

Sun Feb 11, 2018 3:27 pm   

On 2/11/2018 12:32 PM, Piotr Dmochowski wrote:

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
*oficjalnie*. Wiadomo jednak nieoficjalnie że wiele z tych firm
wynajdywalo kwadratowe koła od wielu lat zmagając sie z identycznymi
problemami. Obecnie rynak oferuje już rozwiązania uniwersalne (i to jest
ostatnie 10 lat gwaltownego rozwoju weryfikacji).


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.