W dniu wtorek, 13 marca 2018 22:15:44 UTC+1 użytkownik Sebastian Biały napisał:
> On 3/13/2018 4:35 PM, s...@g...com wrote:
> > Symulator w ISE nie ma żadnych ograniczeń co do rozmiaru projektu. Ograniczenia
dostępnych peryferiów? Jakich?!
>
> Nie wiem akurat co ise ogranicza, ale inni ograniczali ficzery języka
> (asercje, nowe standardy itp) oraz dostęp do niektórych co bardziej
> interesujacych IP (jak np. brak gotowca DDR3[1] itd).


No to jak nie wiesz co ISE ogranicza, to po co gadasz że wszystkie darmówki są do
bani. Piszesz, że inni coś ograniczali.. Ja Adamowi nie proponuję "innych". Jakoś
"innie" argumentujesz.. Jak "inny"..

>
> > darmową to TYLKO ograniczenia co do dostępnych kostek i niektórych IP.
>
> Dokładnie o tym piszę.

Niedokładnie !!

>
> > Tak czy inaczej nie jest to absolutnie nic na kształt demo.
>
> Nie mam ochoty wykłucać się o definicje co rozumiem przez demo w
> software/hardware.
>
> >> Prawda tez taka że za standardem SystemVeriloga nikt nie nadąża bo
> >> robiony po pijaku ale przynajmniej komercyjni się starają kiedy świat
> >> free software nie jest w stanie zrobić sensownego parsera
> >> średniowiecznych wersji VHDLa czy Veriloga.
> > Nie korzystam z free software, ale nie chce mi się wierzyć żeby w sofcie free
nawet parser nie działał..
>
> Nie dziala poprawnie nawet w komercyjnych symulatorach ale tam komuś
> chce się przegladać te tysiące stron standardu w poszukiwaniu cienia
> sensu i szansy na naprawę. W przypadku free wszyscy zatrzymali się 20
> lat temu i stoi. Tak, da się kompilować helloworldy, ale cieżkie rzeczy
> nie przejdą. Ciezkie czyli asercje, obiektowość, debugging, ip cory,
> modele zewnetrzne, mixed, analog itd itp. Nie ma freeware majace te
> elementy. Zazwyczaj znajdzie się coś z gatunku "potrafimy troche
> parsować i troche symulowac Veriloga z przed 10 lat, huraaa!".

Ojapierdole!! A tymczasem komóry działają, kompy też.. Chyba jesteś zwolennikiem
teorii, że bąk nie może latać, bo ma zbyt małe skrzydła w stosunku do swojej masy. No
ale bąk o tym nie wie, więc lata :). Podobnież jest ze mną. Przepuszczam swoje
projekty przez symulator nie wiedząc że jest on do bani. Dzięki owej niewiedzy
urządzenia działają zgodnie z założeniem i wynikiem symulacji.

>
> Sytuacja podobna jak z C++ - nie ma ani jednego pełnego kompilatora tego
> języka, choć wszystkie potrafią 98%. Róznica taka że w hardware tak mają
> za grube tysiące a w software tak mają za 0.
>

No to masz pole do popisu!!


>
> Nie ma takiego co jest dobre. Na rynku hardware albo męczysz się jako
> hobbysta z ograniczeniami albo męczysz się jako klient dużej korpo z
> bugami softu, może tylko lżej, bo jest na kogo pokrzyczeć.

Zmień zawód.
>

>
> Nie, po prostu potrzebujesz analog view. A ja potrzebuje asercji,
> odpalania zdalnego na farmie weryfikacyjnej, raportowania regresji itd itp.

Nawet nie wiem co to jest farma weryfikacyjna i raport regresji itd itp. Wiem, że 30
lat temu nie było takiej nowomowy i dzięki temu zakupiona wówczas mikrofalówka
koreańska działa do dzisiaj. Żarówę ino wymieniałem 2 tygodnie temu (tę do
oświetlenia wnętrza). A moja kobita kupiła se jakiegoś nowego gadżeta typu smartfon,
czy ajfon, który zapewne przeszedł przez jakąś farmę. Efekt jest taki, że jak ktoś do
niej dzwonił, a była w innym pokoju i mi krzyknęła "odbierz telefon", to niestety
poddałem się. Sorry!! Nie umiem !! Kapujesz?!

>
> > Zasobożerność, to właśnie nie jest ŻADEN problem.
>
> Dla edukacji zasadniczy. Odpalenie kompilatora, symulatora itd. powinno
> zając sekundy. Zajmuje więcej bo srodowisko jest za grube. Większośc
> malych projektów programista HDL przesiaduje przed ekranem gapiąc się w
> coraz to głupsze komunikaty i czekając na wynik i zastanawiając się
> czemu symulacja dwóch bramek wymaga odpalania sie przez 10 sek jakiś
> zdumiewająco verbose narzedzi diabli wiedza do czego.

Piepszysz głupoty. Parę sekund więcej w czasie odpalania + jakieś tam komunikaty, to
problem ZASADNICZY? Weź przestań...

>

> To nic nie pomaga, aplikacje do HW są cieżkie nawet dla bardzo
> nowoczesnych komputerów. Jest inna sprawą że w tej branzy znajdziesz
> idiotów pracujących na *certyfikowanych* redhatach 3.0 i spodziewających
> się ze ich soft za $x000 bedzie tam banglał. Ale nawet jak możesz kupić
> wypasiony komputer to czasy symulacji, kompilacji, ładowania, analizy
> itd liczone sa w *tygodniach* na projekt dla jednego eventu. Taki Linux
> na symulowanym niskopoziomowo CPU potrafi wstawać kilka dni. Wiec
> pojęcie "troche stówek na pamięć i dysk" może być niedoszacowaniem. Dla
> hobbysty może wystraczyć choć jak wczęsniej programował w językach
> programowania software to pewno rzuci monitorem o scianę.

Adam chce się nauczyć HDL. O czym Ty zaś nawijasz? Jakiś nowatorski prom kosmiczny
chcesz zrobić? Implementacja do FPGA/CPLD trwa trochę dłużej niż kompilacja softu pod
CPU. Synteza, mapowanie do zasobów kostki, routing (topologia - matematyka), to
trochę musi potrwać. Na moim lapku, XC6SLX45 z prawie pełnym wykorzystaniem zasobów
BRAM+DSP+kupa slajsów trwa to jakieś 20 minut. Dla Adamowego multipleksera będzie to
niecała minuta. Nie sprawdzałem, ale idę o zakład, że będzie to w tych okolicach.



> Do tego sa inne techniki niż gapienie sie w ekran, nawet z wykresem
> analogowym, ponieważ wieki temu dowiedziono że gapienie sie w ekran bywa
> obarczone czynnikiem ludzkim.

Chętnie poznam ów dowód. Jak mnie przekona, to wypierdolę oscyloskop za okno.