W dniu sobota, 24 stycznia 2015 18:52:44 UTC+1 użytkownik Mario napisał:

> >
> > Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
> > opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
> > schematem graficznym.

Słusznie!! Pomyśl i wyjaśnij!!

>
> Wtrącę się troszkę chociaż ogólnie masz rację.
> Schemat może być robiony hierarchicznie, więc da się podzielić pracą w
> grupie.
>

Guzik ma rację. Też projektuję hierarchicznie. Dlaczego? Bo jeden rzut oka na
malunek. Antek robi syfrówę, Józek przetwornik AC, Zenek robi FPGA, Zocha robi PCB.

Rzut oka i wszystko jasne!! Mogę dla jaj podesłać swój projekt FPGA w postaci VHDL -
strukturalny + niektóre podzespoły behavioralnie. Te drugie to raczej załapiecie
prawie od strzału.

Zaś pierwsze..., ni wuja !! Sam po tygodniu przerwy mam z tym problemy. Na grafice,
wystarczy godzinka...

do góry

On 2015-01-24 18:52, Mario wrote:
> Schemat może być robiony hierarchicznie, więc da się podzielić pracą w
> grupie.

A plików tekstowych *NIE* trzeba dzielić. Od czasu systemów kontroli
wersji z mergowaniem. I znowu schemat przegrywa.

do góry

On 2015-01-24 18:53, s...@g...com wrote:
>> Uważaj. Projektowanie z poziomu kodu ma wiele zalet, że wymienie choćby
>> testy.
> Przestań!! Jak się na czymś nie znasz, to się nie mędrkuj. TestBenche istotnie
pisze się w dowolnym HDL

Przegapiłeś ostatnie jakieś 10 lat. Zadanie domowe z googla:
SystemVerilog i UVM. Przed UVM było trochę innych. I bedzie pare
nastepnych, prawie na 100%. Dynamika tu jest kosmiczna.

I powtarzam: nie tylko gołe testy. Asercje, contrains, randomizacje,
TLM. To jest pisane w HDLu i *WPLATANE* w kod. Bo asercja jest naturalną
częścią kodu. W schemacie nie masz możliwosci postawienia głupiej
asercji. Odcinasz w ten sposób bardzo ważne mechanizmy zwiększające
jakość i ulatwiające debugowanie.

Świat naprawdę zna lepsze metody opisu elektroniki na dowolnym poziomie
od tranzystorów po transakcje. Lepsze od schematów. Naprawdę.

>, ale guano ma to wspólnego ze środowiskiem projektowym

*NIE* jest to takie proste. Miało kiedyś. Przez ostatnie 10 lat wiele
się zmieniło. Ewentualnie engine zbierający wyniki może mieć formę
środowiska. Testy obecnie pisze się w tym samym języku co implementację,
akurat taka moda. Obecnie na topie jest SystemVerilog. Jutro pewnie coś
głupszego od veriloga choć nie wiem czy nie osiągnięto już dna.

do góry

On 2015-01-24 19:20, s...@g...com wrote:
>>> Zgadnij dlaczego 99% implementacji software/firmware/hardware jest
>>> opisanych tekstem a nie grafiką. I pomyśl jak pracuje się zespołowo nad
>>> schematem graficznym.
> Słusznie!! Pomyśl i wyjaśnij!!

Dla schematow nie dorobiliśmy się jeszcze sensownych:
a) wygodnego komparatora zmian (niezbędne przypracy zespołowej)
b) wygodnej metody łaczenia zmian wykonywanych przez różnych developerów
(niezbedne przy pracy zespołowej)
c) środowisk które pozwalają te operacje zintegrować z systemami
kontroliwersji
d) formatu pliku który jest przyjazny dla systemów kontroli wersji
e) wygodnego edytora (90% znanych mi edytorów schematów nie ma
funcjonalności rozpychania elementów czy automatcznego routingu drutów,
a to tylko mały kawałek braków)
f) wsparcia dla konwersji hdl->sch która nie robi kupy

Jesli chodzi o edytowanie schematów to mamy gdzies okolice
średniowiecza. Bez względu na cenę jaką płaciszza software. Złożonośc
problemu jest ogromna. I nie warta ceny.

>Antek robi syfrówę, Józek przetwornik AC, Zenek robi FPGA, Zocha robi PCB.

A czemu AC nie mogą robić Józek i Marek? Bo się *NIE* da? Coś Cię ogranicza?

do góry

On 2015-01-24 18:43, s...@g...com wrote:
> Zaprogramuj w np. TTL'ach for( i = 1; i <= 10; i++ )

Tego się nie programuje. To się syntezuje. Innymi slowy wynik tej
syntezy może być diametralnie różnyw zalezności od tego co jest w środku
pętli. I być może niemożliwy.

W ogólności jeśli ktoś w FPGA zamierza liczyć silnie za pomocą
rekurencji to jest idiotą. Tylko co z tego wynika w dyskusji nad
kiepskością schematów w HDL? Na schemacie tej pętli nie zrobisz. LabView
probował - kupa wyszła.

> W opisie behawioralnym np., multiplekser o dowolnej szerokości szyn wejściowych da
się opisać w paru linijkach kodu.
> Strukturalnie, na bramkach też się da opisać. Na 8-mio bitowych danych, idę o
zakład, że za Wuja Wacka nie załapiesz opisu tak "od strzału"

Po co mam opisywać multiplekser na poziomie bramek skoro poziom wyżej
też się syntezuje i działa tak samo?

> Na schemacie, byle rzut oka i wszystko jasne.

Na te kilkaset bramek? Gratuluje. Kolesie od weryfikacji formalnej
hardware mają czasem problem z podobną skalą komplikacji. Ale oni mają
zazwyczaj tylko 8 rdzeni po 5GHz i kilka godzin pracy kompa.

do góry

"Sebastian Biały" <h...@p...onet.pl> wrote in message
news:ma0rnp$p5c$1@node1.news.atman.pl...
> On 2015-01-24 18:52, Mario wrote:
>> Schemat może być robiony hierarchicznie,
>> więc da się podzielić pracą w grupie.
>
> A plików tekstowych *NIE* trzeba dzielić. Od czasu systemów kontroli
> wersji z mergowaniem. I znowu schemat przegrywa.

Nawet w takich przypadkach zwykle programiści jednak dzielą się
modułami i 3 z nich nie robi na raz zmian w jednej 5-linijkowej funkcji.

Ale faktem jest, że graficznemu podejściu brakuje wsparcia kontroli wersji.

do góry

W dniu sobota, 24 stycznia 2015 20:36:47 UTC+1 użytkownik Sebastian Biały napisał:

> Przegapiłeś ostatnie jakieś 10 lat. Zadanie domowe z googla:
> SystemVerilog i UVM. Przed UVM było trochę innych. I bedzie pare
> nastepnych, prawie na 100%. Dynamika tu jest kosmiczna.
>

SystemVerilog istotnie może być ważny dla kogoś, kto pisze w Verilogu, kto pisze
doktorat lub pracę habilitacyjną. Weryfikacja funkcjonalna działania projektowanego
urządzenia jest istotna i bezdyskusyjna. Na wstępie z poziomu symulatorów.

> I powtarzam: nie tylko gołe testy. Asercje, contrains, randomizacje,
> TLM. To jest pisane w HDLu i *WPLATANE* w kod. Bo asercja jest naturalną
> częścią kodu. W schemacie nie masz możliwosci postawienia głupiej
> asercji.

Istotnie, na schemacie tego nie zobaczysz. Czego?! A na przykład constrais'ów.
Bo i po co? Przecież byle student wie/powinien wiedzieć, że z projektem należy
skojarzyć 'constraintsy'. A z drugiej strony, jest to ino kwestia edytora schematów.
Istotnie, nie znam takowego, który wyświetlałby na schemacie 'constrains'y'.
Chociaż.... Np. Altium ma taką możliwość.

> Odcinasz w ten sposób bardzo ważne mechanizmy zwiększające
> jakość i ulatwiające debugowanie.

Niczego nie odcinam. Piszesz tylko o debugowaniu. To zupełnie inna bajka niż projekt
urządzenia. Istotnie, testbenche 'nasmarowane' graficznie, to jakieś SF.

>
> Świat naprawdę zna lepsze metody opisu elektroniki na dowolnym poziomie
> od tranzystorów po transakcje. Lepsze od schematów. Naprawdę.

Zaprojektuj latarkę, albo coś w tym stylu metodą opisową. Da się? Jasne, że się da!!
I pokaż to dajmy na to 7-latkowi. Zrobi coś z Twojego "schematu"? Ni Wuja!!

>
> >, ale guano ma to wspólnego ze środowiskiem projektowym
>
> *NIE* jest to takie proste. Miało kiedyś. Przez ostatnie 10 lat wiele
> się zmieniło. Ewentualnie engine zbierający wyniki może mieć formę
> środowiska. Testy obecnie pisze się w tym samym języku co implementację,
> akurat taka moda. Obecnie na topie jest SystemVerilog. Jutro pewnie coś
> głupszego od veriloga choć nie wiem czy nie osiągnięto już dna.

Ciągle marudzisz o testach.. Też je robię, testbencze smaruję w VHDL'u, ale toplevel
urządzenia robię hierarchicznie i z poziomu schematu.

do góry