On 2/10/2018 4:30 PM, Marek wrote:
>> 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.
> A czy ma to znaczenie nazwa firmy tyou Qualcomm czy 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ł.

do góry

Sebastian Biały 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.

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.

> Obecnie wymogi pod względem weryfikacji pofruneły w kosmos.
> Kto nie zdążył się dostosować, przegrał.

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

do góry

On 2/10/2018 10:53 PM, Piotr Wyderski 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.

Dyskusja już dawno nie jest ściśle 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?

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.

> Czy chociaż poprosił o pomoc w zorganizowaniu
> jednoosobowej działalności gospodarczej, mającej się zajmować HDL?

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

> 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

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

, niezależnie od wątpliwej
> wartości merytorycznej tego stwierdzenia?

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.

> Nie budujemy tutaj fabryki
> i nam tematyka continuous delivery kompletnie wisi. Wygłupiłeś się,

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.

> ale przerośnięte ego

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.

> nie pozwala Ci się do tego przyznać, więc
> obrażasz pozostałych dyskutantów i wygadujesz bzdury o Qualcomach
> i Samsungach.

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.

> Szkoda, bo do dziś miałem Cię za naprawdę rozsądnego gościa.

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.

>> Obecnie wymogi pod względem weryfikacji pofruneły w kosmos.
> > Kto nie zdążył się dostosować, przegrał.
> 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.

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

do góry

On Sun, 11 Feb 2018 00:56:07 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> 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.

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

do góry

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

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

jp

--

www.flowservice.pl
www.flowsystem.pl

do góry

On 2/11/2018 8:07 AM, Marek 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??

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

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

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.

do góry

W dniu 2018-02-11 o 11:12, Sebastian Biały pisze:
>
> 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.
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.

--
Pozdrawiam
Piotrek

do góry

Dnia Sun, 11 Feb 2018 12:32:28 +0100, Piotr Dmochowski napisał(a):
> W dniu 2018-02-11 o 11:12, Sebastian Biały pisze:
>> 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.
> 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?

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

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

Marketing sobie narysuje, zeby klienta zachecic :-)


J.

do góry

W dniu 2018-02-11 o 13:47, J.F. pisze:
> Dnia Sun, 11 Feb 2018 12:32:28 +0100, Piotr Dmochowski napisał(a):
>> W dniu 2018-02-11 o 11:12, Sebastian Biały pisze:
>>> 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.
>> 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?
>
> Wyciaga ktos projekt procesora, projekt akceleratora, dopisuje jak sa
> polaczone i mowi "nasz dzial zakonczyl".
>
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 :)

--
Pozdrawiam
Piotrek

do góry

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.

do góry