RTV forum PL | NewsGroups PL

Nauka programowania FPGA

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Nauka programowania FPGA

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

Guest

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ł:
Quote:
On 2/9/2018 10:26 AM, stchebel_at_gmail.com wrote:
Świat odchodzi od rysowania schematów [1]. To wynika z bardzo wielu
przyczyn ale najwazniejsze to jest niemożność stosowania technik
zapewniania jakości na takim designie. W zasadzie profesjonalny hardware
produkuje się obecnie *wyłacznie* za pomocą opisu który pozwala na
stosowanie annotacji, śledzenia wymagań, unit testowania (i kilku innych
poziomów testowania), pracy w grupie, systemów kontroli wersji,
wykrywania regresji, automatycznego lintowania itd. Rysowanie schematów
jest marginesem do projektów migania diodami. To ślepa uliczka.
[1] Nie wyssałem tego z palca.

Świat również wymyślił coś takiego jak ISO xxxx. System zarządzania jakościąSmile 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.

Quote:
Najdelikatniej jak umiem.. Nie pisz skąd te bzdury wyssałeś :)

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.


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?

Quote:
Kontrola wersji, regresja.. O czym Ty gościu p........ ?

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.

Taaak... Mentalnie jestem w latach '60:)) ISOxxxx wymaga rozwieszania nawet po kiblach banerów "Jakość jest dla nas najważniejsza"Smile) 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 Smile)

Quote:

Da się "elektronikom" wyprać mózg? Chyba tak...

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

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

Sebastian Biały
Guest

Sat Feb 10, 2018 2:24 pm   



On 2/10/2018 12:55 PM, stchebel_at_gmail.com wrote:
Quote:
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.

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

Quote:
Co to robi?

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.

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

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.

Quote:
Taaak... Mentalnie jestem w latach '60:))

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.

Quote:
ISOxxxx

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.

Quote:
Zeptera są ze stali szlachetnej Smile)

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.

Guest

Sat Feb 10, 2018 2:45 pm   



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

Quote:
b) FPGA zawierają dziwne peryferia jako bonus (np. gotowe uklady mnożące
albo konfigurowalną pamięć RAM)


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

Sebastian Biały
Guest

Sat Feb 10, 2018 3:15 pm   



On 2/10/2018 1:45 PM, stchebel_at_gmail.com wrote:
Quote:
b) FPGA zawierają dziwne peryferia jako bonus (np. gotowe uklady mnożące
albo konfigurowalną pamięć RAM)
Układy mnożące i konfigurowalny RAM nie są niczym dziwnym. Mentalnie jesteś w latach '60-tych.

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

Marek
Guest

Sat Feb 10, 2018 4:30 pm   



On Sat, 10 Feb 2018 14:24:01 +0100, Sebastian
Biały<heby_at_poczta.onet.pl> wrote:
Quote:
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?? Co
umie spieprzyć Qualcomm czego by nie umiał np. Samsung?

--
Marek

Sebastian Biały
Guest

Sat Feb 10, 2018 5:15 pm   



On 2/10/2018 4:30 PM, Marek wrote:
Quote:
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ł.

Piotr Wyderski
Guest

Sat Feb 10, 2018 10:53 pm   



Sebastian Biały wrote:

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

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

Sebastian Biały
Guest

Sun Feb 11, 2018 12:56 am   



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

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

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

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

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

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

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

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

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

Marek
Guest

Sun Feb 11, 2018 8:07 am   



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

jacek pozniak
Guest

Sun Feb 11, 2018 10:18 am   



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

Sebastian Biały
Guest

Sun Feb 11, 2018 11:12 am   



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

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

Piotr Dmochowski
Guest

Sun Feb 11, 2018 12:32 pm   



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

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

J.F.
Guest

Sun Feb 11, 2018 1:47 pm   



Dnia Sun, 11 Feb 2018 12:32:28 +0100, Piotr Dmochowski napisał(a):
Quote:
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

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

Piotr Dmochowski
Guest

Sun Feb 11, 2018 3:07 pm   



W dniu 2018-02-11 o 13:47, J.F. pisze:
Quote:
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 Wink
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

Sebastian Biały
Guest

Sun Feb 11, 2018 3:27 pm   



On 2/11/2018 12:32 PM, Piotr Dmochowski wrote:
Quote:
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.

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

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

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Nauka programowania FPGA

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map