On 2/11/2018 12:32 PM, Piotr Dmochowski wrote:
> Załóżmy że dzwoni prezes i mówi: zróbcie mi procesor 8 rdzeni z grafiką.
> Co się dalej dzieje?

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 IT na ten przykład diagramy jednak się stosuje np. UML i BPML.

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

> Fakt że
> program z nich nie powstanie, ale żeby pokazać co ma powstać i jak ma
> działać jednak są lepsze niż sterty tekstu.

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.