Elektroda.pl
Elektroda.pl
X
Elektroda.pl
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Xilinx czy Altera? Koszt softu z Embeded System Design, DSP.

06 Wrz 2010 01:09 3580 11
  • Poziom 9  
    Witam.
    Mam dosyć spore (ponad 10-letnie) doświadczenie z projektowaniem FPGA Xilinx'a
    różnej maści. Aktualnie pracuję na leciwym już trochę , ale spełniającym moje
    wymogi ISE7.1i . Do tej pory projektowałem specjalistyczne karty do PC (arbiter
    PCI + trochę różnego siana cyfrowego). No i nagle wynikła potrzeba zrobienia
    czegoś bardziej pogmatwanego - Embeded System.

    No to jazda , ściągam WebPacka 12.1 , odpalam i widzę , że wszystko to jest tak
    pogmatwane , że nie mogę tego ogarnąć. Zresztą zauważam , że każda kolejna
    wersja ISE jest coraz bardziej "upierdliwa". Ot , chociażby Testbench'e , które
    w wersji 12.1 muszę pisać w VHDL'u. Prościej i szybciej robi się to w edytorze
    graficznym (v7.1i). W wersji 12.1 nie ma już projektowania na stanach
    maszynowych (FSM). O kurde, to już jest poważny krok w tył!

    No dobra , odpalam Xilinx Platform Studio , zatrudniam do roboty Wizarda ,
    wybieram system jednoprocesorowy Microblaze'a , w pewnym momencie dochodzę do definiowania urządzeń I/O. No i psia jego, nie ma w polu wyboru takich podstawowych jak USB czy PCI. Mało tego, załóżmy, że sam zaprojektowałem moduł komunikacyjny w VHDL'u. I jak go do Panie Nędzy dołączyć?

    Koniec psioczenia na Xilinxa. A teraz Altera. Popróbowałem Quartusa 8.0 ..
    No i kurde miłe zaskoczenie. Po 15 minutach, już widzę jak w Embeded System
    podpiąć interfejsy PCI, USB i tym podobne heble. GUI dosyć podobne do ISE, są
    pewne różnice, które z uwagi na rutyniarstwo trochę wpieniają, ale to
    normalne. Da się ogarnąć z czasem.

    Co do konkretnego wyboru FPGA Xil/Alt, jest to sprawa drugorzędna. Ile projekt
    pożre logiki, jeszcze nie wiem. Finalnie wybiorę taki jaki jest potrzebny.

    No i co radzicie? Rozwieść się z Xil i ułożyć się życie z Alt?

    No i jeszcze jedno, ile Alt śpiewa sobie za soft obejmujący Embeded System
    Design i elementy DSP?

    Pozdrawiam.
    MH
  • PCBway
  • Poziom 27  
    same uklady[fpga] sa podobne, software altery duzo lepszy;
    dodatkowo ise nie radzi sobie z synteza rozbudowanych
    projektow, trzeba uzyc synplify czy czegos podobnego,
    w przypadku altery taki posrednik nie jest konieczny;
    plusem xilinx jest to, ze ze wzgledow historycznych jest
    bardziej popularny;
    taka jest powszechna - i moja rowniez - opinia;
    J.A
  • Poziom 21  
    Weź również pod uwagę symulator do TB. Z tego co się orientuję to istnieje do układów xilinxa specjalna wersja modelsima xe za free do zastosowań niekomercyjnych. Co do altery to nie wiem sprawdź sobie wszystko dokładnie. Pozdrawiam
  • PCBway
  • Poziom 30  
    No takiego doświadczenia można pozazdrościć. Mnie jeszcze czeka długa droga do kariery zawodowej, mam nadzieje że zwiąże się z FPGA. Ale do rzeczy. Do produktów Altery (czy Lattice) nie będę się wypowiadał, bo nie miałem z nimi jeszcze do czynienia. Ale tak...

    logison napisał:
    Ot , chociażby Testbench'e , które w wersji 12.1 muszę pisać w VHDL'u. Prościej i szybciej robi się to w edytorze graficznym (v7.1i). W wersji 12.1 nie ma już projektowania na stanach maszynowych (FSM). O kurde , to już jest poważny krok w tył !!

    No nie wiem, ale każdy porządny projektant przygotowuje opis Testbench'a w VHDL. Wynika to z dużej elastyczności i możliwości jakie takie rozwiązanie daje, assert, report, drukowanie danych z pliku i do pliku (textio) czy do konsoli. Porządny napisany testbench sam wyłapuje nam błędny i wskazuje w którym miejscu one są. Takie rozwiązanie zostało dobrze przyjęte przez community na forum Xilinx'a. Sam nasz wykładowca uznał taki generatorek "zabawką dla dzieci" (; Można jeszcze taki coś znaleźć do wersji 10.3. Taka sama sprawa dotyczy maszyny stanów. Też taki opis robi się w VHDL'u. Dobra napisana maszyna stanów, jest bardziej dużo z optymalizowana niż z takiego generatora. W dodatku dochodzi wybór sposobu takiej optymalizacji (np. one-hot). Jeśli poszukujesz takiego narzędzia, to ono jest dostępne teraz w Matlabie, który np. z grafu generuje kod w VHDL'u. Mathworks ma u Xilinx'a pełne wsparcie na ten temat. Pewnie chodziło o skuteczność takiej maszyny.

    logison napisał:
    No dobra , odpalam Xilinx Platform Studio , zatrudniam do roboty Wizarda , wybieram system jednoprocesorowy Microblaze'a , w pewnym momencie dochodzę do definiowania urządzeń I/O. No i psia jego , nie ma w polu wyboru takich podstawowych jak USB czy PCI. Mało tego , załóżmy , że sam zaprojektowałem moduł komunikacyjny w VHDL'u. I jak go do Panie Nędzy dołączyć ??

    Jak co, ale w Xilinx'ie jest miażdżący wszystko support jaki dotąd spotkałem, dla potencjalnego użytkownika. Setki not, user guide itp. Wystarczy zapoznać się z dokumentacją. Genialnie są wytłumaczone tutorial'e do tych narzędzi + pliki na których tłumaczą, ułatwia to przebrnięcie się przez nowy soft Basic Tutorial Embedded for Virtex-5. W dodatku rozbudowany help oraz łączenie się z internetem za pomocą WebTalk'a w celu analizy Warning'a lub Error'a i proponowanie rozwiązania.

    J.A napisał:
    ise nie radzi sobie z synteza rozbudowanych
    projektow, trzeba uzyc synplify czy czegos podobnego,

    Można tą wypowiedź rozszerzyć:?: W dawnych latach, rozwiązania akademickie pod względem syntezy przewyższały te komercyjne. Teraz nie odczuwa się takiego zubożenia. XST już sporo przeszło zmian do dzisiaj. Ale wolałbym być świadomy ograniczeń jak można je wymienić?
  • Poziom 15  
    Witam

    Chciałbym się podzielić swoimi spostrzeżeniami. Swego czasu zawodowo pracowałem na układach Xilinx-a. Obecnie zawodowo mam do czynienia z układami Altery (przy czym zawodowo już nie od strony programowania), a "hobbystycznie" dłubię Alterę.
    W kwestii zasobów i funkcjonalności Xilinx i Altera jest podobna (chociaż ostatnich Spartanów 6 nie znam zbytnio). Niektóre rzeczy podobały mi się bardziej w Xilinxie np. funcjonalność DCM w Spartanie, ale nie widzę jakichś drastycznych różnić (jak zawsze diabeł tkwi w szczegółach :)). Zresztą nowe serie Cyclone III i IV chyba już nie ustępują niczym Spratanom.
    Co do softu to z Quartusem pracuje mi się dużo lepiej. Interfejs jest dużo bardziej przyjazny (ale to kwestia subiektywna -ktoś inny może powiedzieć inaczej) i nie pamiętam aby Quartus mi się zawiesił, co było częste w ISE i dość irytujące np. jak odpaliłeś czasochłonną symulację.
    W kwestii dokumentacji przychylam się do Xilinx-a. Fakt, że mają więcej not aplikacyjnych i przykładów, z których czasem sam korzystam, mimo, że piszę coś na Alterę :).
    Ostatnia sprawa, kwestie praktyczne jak np. obudowy, czy też dostępność. Większość nowych układów jest na BGA jedynie wersje z najmniejszymi zasobami są w TQFP (Altera ma EQFP czyli takie TQFP z padem termicznym na pod obudową), tak więc samodzielne lutowanie w większości wypadków nie wchodzi w grę. Dostępność układów Xilinx-a jest w Polsce trochę lepsza niż Altery, ale wynika to z popularności Xilinx-a w Polsce (jak to napisał użytkownik JA). Ale jeśli kupujesz coś w Farnell-u to nie ma większych problemów.
    Generalnie jeśli nie masz jakiejś silnie umotywowanej potrzeby przechodzenia na Alterę to zostań przy Xilinx-ie. Inaczej to trochę sztuka dla sztuki.

    Pozdrawiam
  • Poziom 27  
    Cytat:
    obinobi:
    Niektóre rzeczy podobały mi się bardziej w Xilinxie np. funcjonalność DCM

    mnie akurat odwrotnie, u altery kazde wyjscie z pll-ki mozna konfigurowac
    niezaleznie i dowolnie [czestotlowosc, faze], z jedngo zewnetrznego zegara
    mozna 'wyprodukowac' i 10 roznych zegarow;
    dcm glownie mnozy/dzieli przez 2 lub odwraca faze;
    Cytat:
    tymon_x:
    Można tą wypowiedź rozszerzyć ?

    co tu rozszerzac ? przy duzych projektach, takich ponad 50% duzego virtexa,
    ise albo pada, albo produkuje niedzialajaca netliste;
    Cytat:
    W dawnych latach, rozwiązania akademickie pod względem syntezy przewyższały te komercyjne. Teraz nie odczuwa się takiego zubożenia.

    niestety nie rozumiem co chcesz przez to powiedziec;
    J.A
  • Poziom 30  
    J.A - źle zrozumiałem, myślałem o wyniku końcowym jaki produkuje synteza do implementacji (szybkość, optymalizacja). A Tobie po prostu chodziło, że soft nie wytrzymuje dużych projektów (; Z tego co dało się wyczytać z Change Log (szczególnie od roku 2009 ISE 11), poprawiono w znacznym stopniu ten aspekt. Wersja 12.2 jest szczególnie mniej awaryjne od tej 10, dobrym posunięciem było odłączenie Isim do oddzielnego procesu.
  • Poziom 9  
    tymon_x napisał:

    No nie wiem, ale każdy porządny projektant przygotowuje opis Testbench'a w VHDL. Wynika to z dużej elastyczności i możliwości jakie takie rozwiązanie daje, assert, report, drukowanie danych z pliku i do pliku (textio) czy do konsoli. Porządny napisany testbench sam wyłapuje nam błędny i wskazuje w którym miejscu one są. Takie rozwiązanie zostało dobrze przyjęte przez community na forum Xilinx'a. Sam nasz wykładowca uznał taki generatorek "zabawką dla dzieci" (; Można jeszcze taki coś znaleźć do wersji 10.3. Taka sama sprawa dotyczy maszyny stanów. Też taki opis robi się w VHDL'u. Dobra napisana maszyna stanów, jest bardziej dużo z optymalizowana niż z takiego generatora. W dodatku dochodzi wybór sposobu takiej optymalizacji (np. one-hot). Jeśli poszukujesz takiego narzędzia, to ono jest dostępne teraz w Matlabie, który np. z grafu generuje kod w VHDL'u. Mathworks ma u Xilinx'a pełne wsparcie na ten temat. Pewnie chodziło o skuteczność takiej maszyny.


    Z całą pewnością testbench opisany w VHDL ma wiele zalet , chociażby takich jakie powyżej wymieniasz. Z całym szacunkiem dla Twojego wykładowcy , ale jestem prawie pewien , że zbyt wiele projektów nie wdrażał do produkcji i nie dokonywał po jakimś czasie modyfikacji istniejącego urządzenia. Testbench w VHDL opisany tekstowo ma jednak takie wady jak pisanie programów komputerowych. Wystarczy 1-2 miesięczna przerwa obcowania z programem i już autorowi ciężko zrozumieć o co mu samemu chodziło. Przy pewnej dozie doświadczenia , już "na nosa" czuje się gdzie mogą wystąpić sytuacje krytyczne i jakie fragmenty symulować. Zmieniając obszar zainteresowania w dużym projekcie , muszę praktycznie pisać nowego testbencha. Również mogę pisać testbencza uwzględniającego wszystkie sygnały w projekcie , automatyczne powiadomienia o błędach ... , i tak mogę się chrzanić przez rok albo i lepiej. A produktu jak nie było tak nie ma. W formie graficznej robi się to "błyskiem". A jeżeli twój wykładowca twierdzi , że graficzne generatory tesbenchów to zabawki , to śmiem twierdzić , iż jego wiedza praktyczna w układach FPGA kończy się na Evaluation-Kit'ach. To samo odn. FSM. Jeszcze mi się nie przytrafiło , aby implementacja z grafu (ok. 100 stanów maszynowych) nie zadziałała z przyczyn o których piszesz. Czysto teoretyczne dywagacje.. Patrząc na wygenerowany kod (ponad 1000 linii) , można się pogubić. Patrząc na grafy , od strzału przypominam sobie o co mi chodziło i mogę modyfikować układ.

    Jeżeli teoria jest w konflikcie z praktyką , to tym gorzej dla... ?? No i z tego właśnie powodu pojawia się na rynku coraz więcej softu generującego VHDL z waveform. Dlaczego WIELCY odchodzą od ludzkiej formy pewnych procesów projektowych i dlaczego wmawiają ludziom , że tak jest lepiej ?? Odp.: BUSINESS i POLITYKA. Z tego właśnie powodu śledzie dopuszczone do obrotu muszą mieć określony wymiar , a banany określoną "krzywistość" .
  • Poziom 20  
    tymon_x napisał:

    No nie wiem, ale każdy porządny projektant przygotowuje opis Testbench'a w VHDL.

    Nie koniecznie w VHDL. VHDL moim skromnym zdaniem dość kiepsko nadaje się do testowania, głównie ze względu na "upierdliwość" i rozlazłość składni oraz brak wygodnych w obsłudze bibliotek. Piszę testbenche w SystemVerilogu i nie wyobrażam sobie testowania w innym języku.

    logison napisał:

    Z całą pewnością testbench opisany w VHDL ma wiele zalet , chociażby takich jakie powyżej wymieniasz. Z całym szacunkiem dla Twojego wykładowcy , ale jestem prawie pewien , że zbyt wiele projektów nie wdrażał do produkcji i nie dokonywał po jakimś czasie modyfikacji istniejącego urządzenia.

    Nie rób takich założeń. Nie każdy wykładowca jest suchym teoretykiem :)

    Cytat:

    Testbench w VHDL opisany tekstowo ma jednak takie wady jak pisanie programów komputerowych. Wystarczy 1-2 miesięczna przerwa obcowania z programem i już autorowi ciężko zrozumieć o co mu samemu chodziło.

    Na tej samej zasadzie możesz mieć problem ze zrozumieniem "szlaczków", które narysowałeś w waveform editorze kilka miesięcy wcześniej.

    Cytat:

    Przy pewnej dozie doświadczenia , już "na nosa" czuje się gdzie mogą wystąpić sytuacje krytyczne i jakie fragmenty symulować. Zmieniając obszar zainteresowania w dużym projekcie , muszę praktycznie pisać nowego testbencha. Również mogę pisać testbencza uwzględniającego wszystkie sygnały w projekcie , automatyczne powiadomienia o błędach ... , i tak mogę się chrzanić przez rok albo i lepiej.

    To w jaki sposób testowałbyś np. MACa ethernetowego, serdesy czy inne moduły komunikacyjne - rysując pakiety ręcznie??


    Cytat:
    A produktu jak nie było tak nie ma. W formie graficznej robi się to "błyskiem". A jeżeli twój wykładowca twierdzi , że graficzne generatory tesbenchów to zabawki , to śmiem twierdzić , iż jego wiedza praktyczna w układach FPGA kończy się na Evaluation-Kit'ach.

    A jeśli Kolega twierdzi, że graficzne generatory to profesjonalne narzędzia, to niech zapyta kogoś, kto robi HDL do VLSI. I jak się go testuje, żeby produkt był na rynku w rozsądnym czasie.

    Cytat:
    Patrząc na wygenerowany kod (ponad 1000 linii) , można się pogubić. Patrząc na grafy , od strzału przypominam sobie o co mi chodziło i mogę modyfikować układ.

    Patrzę na kod, który ma ze 100000 linii i jakoś się nie gubię. Nie oceniaj innych przez pryzmat swoich przyzwyczajeń. Dobry edytor, znajomość języka i dajesz rade. Poza tym większe projekty rozdziela się na moduły z dobrze zdefiniowanymi interfejsami, które są na tyle małe, żeby łatwo było je ogarnąć.

    Cytat:

    Jeżeli teoria jest w konflikcie z praktyką , to tym gorzej dla... ?? No i z tego właśnie powodu pojawia się na rynku coraz więcej softu generującego VHDL z waveform. Dlaczego WIELCY odchodzą od ludzkiej formy pewnych procesów projektowych i dlaczego wmawiają ludziom , że tak jest lepiej ??

    Przykłady?

    Pozdrawiam,
    TW
  • Poziom 9  
    1. Poniekąd dobrze , że wykładowcy posiadają porządną wiedzę teoretuczną. Jeżeli jest porządnie przekazana studentom , ci zaś nabiorą pewnego 'rzemiosła' w praktyce , dojdą do wniosku , że nie ma sensu symulowanie np. bramki AND , bądź modułów wcześniej zaprojektowanych i zweryfikowanych nie tylko na symulatorze , ale przede wszystkim w PRAKTYCE !! DZIAŁAJĄCYCH !! Nie mnie jednak , zgadzam się , iż teoria jest b. ważna , aczkolwiek ABSOLUTNIE nie może dominować nad praktyką. Niejednokrotnie (z autopsji) bywało , że symulacja jest OK , a układ 'milczy'. Z reguły wtedy , 'teoretycy' rozkładają ręce , praktycy 'wypuszczają' test-pin'a na oscyloskop , coś tam zmieniają i... DZIAŁA !!

    2. Jeden rzut oka na 'szlaczki' i wiem o co biega! Jak trochę przygmatwane , to powiedzmy max. 5 minut. Nie wmówisz mi , że szybciej się w tym połapiesz na dowolnym kodzie tekstowym >1000 linii kodu. Nieważne , czy jest to VHDL czy Verilog. Odnoszę wrażenie , że nie czujesz problemu od strony typowo inżynierskiej , a więc (pomysł na produkt)=>projekt=>symulacja(soft)=>weryfikacja+poprawki(hard) prototypu=>produkcja.
    Jak mam mieć stimulus na byle bzdetę jak chociażby CLK , kilkadziesiąt linii kodu , to dziękuję.

    3. Jak testować SERDESA ?? A po co ?? Taką duperelę ?? 32 kanały 12-to bitowe odpaliły od strzału. A może jeszcze bramki AND testować ?? A nawiasem mówiąc SERDESA też zrobiłem na przerzutnikach(shift-register). Też działa. Bez symulacji !!

    4. A jak się testuje w fazie projektowania układy VLSI , tego nie wiem. Wierzę na słowo , że właśnie tak jak piszesz. Ale to nie mój problem. Ja dziabam w FPGA...

    5. Skoro się nie gubisz w 10000 liniach kodu , to szacun !! Ja dziękuję.. Wybieram 'szlaczki'. Idę o zakład , że w dobrym środowisku projektowym (np. ACTIVE-HDL) jestem w stanie zrobić testbencha szybciej w odwrotności do jakiejś tam potęgi ilości testowanych sygnałów , niż Ty dziubiąc to tekstowo w dowolnym HDL.

    6. Pytasz o przykłady.. Od groma i trochę !! Pierwszy z brzegu :

    http://www.timingtool.com/
  • Poziom 30  
    logison napisał:
    A jeżeli twój wykładowca twierdzi , że graficzne generatory tesbenchów to zabawki , to śmiem twierdzić , iż jego wiedza praktyczna w układach FPGA kończy się na Evaluation-Kit'ach.

    Na podstawie tego:
    logison napisał:
    No i nagle wynikła potrzeba zrobienia
    czegoś bardziej pogmatwanego - Embeded System.

    To śmiem twierdzić, że czasy baroku już minęły. Ten zarzut jest chybiony na kilometr. To już nie te czasy zaściankowe, kiedy doktoratów uważa się za "czystych" teoretyków, nie mających nic wspólnego z praktyką. Dzisiaj tacy pracują w projektach na zewnętrznych kontraktach, udzielają się w prywatnych konferencjach, doradzają firmom i biorą udział w projektach, i przekazują w czasie wolnym wiedzę innym (m.in. studentom). Chcesz taki przykład proszę bardzo:
    Code:
     Projekt i realizacja zintegrowanych modułów sieci sensorowej w technologiach FPGA i ASIC do monitorowania środowiska i ruchu pojazdów w obszarach miejskich.(ps. Zapraszam do Gdańska, działa bez zarzutu)

    Są stawiane systemy Embedded, bez problemu radzą Sobie z uruchomieniem dowolnej dystrybucji (np. Petalinux), obsługa PowerPC w Virtex'ach czy implementacji sieci neuronowych i obsługi DSP (przykład wyżej).

    Świat idzie do przodu, i nikt na nikogo nie będzie czekał. Masz problemy z obsługą SDK? Przecież do skonfigurowany Eclipse z kompilatorem od Xilinx'a, żeby napisać soft np. Microblaze'a i go debugować. Każdy kto bawił się z ARM'ami (lub innymi uC) i chciał mieć profesjonalne narzędzie z OpenSource stawiał Eclipse+OCD+gcc i nawet z braku wiedzy z FPGA poradzi Sobie, a dlaczego o tym piszę? Ponieważ od "modern" inżynierów wymaga się elastyczności i wszechstronności. Kończąc inżynierkę, młody człowiek ma wiedzę od FPGA, po nowoczesne uC (np. oparte na rdzeń ARM), podstawy w projektowaniu LSI/VLSI po procesory sygnałowe DSP. Trzeba doganiać świat, już nie wykłada się "czystej teorii" jak kiedyś, stawia się na rzeczy, które mają być praktyczne i ta wiedza wynika z młodej kadry, wypychających już dawno temu zatwardziałych teoretyków. Firmy zaczęły już dawno współpracować z Politechnikami (PG z Intel'em), wymuszając "praktyczność" i stawiając na ciekawe projekty (mnożenie dużych liczb za pomocą CUDA NVIDA, proszę bardzo).
    logison napisał:
    Z reguły wtedy , 'teoretycy' rozkładają ręce , praktycy 'wypuszczają' test-pin'a na oscyloskop , coś tam zmieniają i... DZIAŁA !!

    Powodzenia sprawdzenia w ten sposób ponad 1000 pinów w Virtex'ie. No chyba, że chcesz sprawdzić co najwyżej działający PWM. Dobrze przemyślny opis w HDL'u nie wymaga takich cudów. Jak już to bierze się za ChipScope, ewentualnie montuje się na szybkiego w FPGA analizator stanów logicznych i dane wysyła się na PC, lub przemiata się z daną częstotliwością kilka sygnałów na oscyloskopie.
    logison napisał:
    Poniekąd dobrze , że wykładowcy posiadają porządną wiedzę teoretuczną. Jeżeli jest porządnie przekazana studentom , ci zaś nabiorą pewnego 'rzemiosła' w praktyce , dojdą do wniosku , że nie ma sensu symulowanie np. bramki AND , bądź modułów wcześniej zaprojektowanych i zweryfikowanych nie tylko na symulatorze ,...

    Proszę nie osądzać obecnego środowiska z pryzmatu, no nie wiem, bolesnych wspomnień z przeszłości za czasów studenckich? Opowiadaną papkę przez media, że "doktór" praktykę widział tylko w książkach?

    logison napisał:
    2. Jeden rzut oka na 'szlaczki' i wiem o co biega! Jak trochę przygmatwane , to powiedzmy max. 5 minut. Nie wmówisz mi , że szybciej się w tym połapiesz na dowolnym kodzie tekstowym >1000 linii kodu. Nieważne , czy jest to VHDL czy Verilog. Odnoszę wrażenie , że nie czujesz problemu od strony typowo inżynierskiej , a więc (pomysł na produkt)=>projekt=>symulacja(soft)=>weryfikacja+poprawki(hard) prototypu=>produkcja.

    A co to ma wspólnego z tematem generatora graficznego? Każdy pewnie obserwuje takie "szlaczki", a czy wyskrobany w HDL'u czy wygenerowany z programu, efekt końcowy taki sam :/ Ja tylko wyraziłem Swoją opinię, i nic więcej. Ten pierwszy sposób daję więcej możliwości, o których wcześniej wspomniałem, a w dodatku daje możliwość łatwiej edycji, po kod jest bardziej schludny i o komentowany (indywidualna sprawa do możliwości, pozostawienia po Sobie czytelnego testbench'a). I co mi daje taki generator, jak po czasie x lub osoba y, wie tylko że takie "szlaczki" mu się pojawią po dodaniu do projektu, a nic nie będzie wiedział o testowanych sygnałach:/ Ma Sobie nowy wygenerować, żeby przetestować inne możliwości? To załatwi kilka linijek (ba, nawet linijka) opisu w HDL'u. Sprawa indywidualna, to jest fakt.
    logison napisał:
    Jak mam mieć stimulus na byle bzdetę jak chociażby CLK , kilkadziesiąt linii kodu , to dziękuję.

    Jedna linijka... :/
    logison napisał:
    SM. Jeszcze mi się nie przytrafiło , aby implementacja z grafu (ok. 100 stanów maszynowych) nie zadziałała z przyczyn o których piszesz. Czysto teoretyczne dywagacje.. Patrząc na wygenerowany kod (ponad 1000 linii) , można się pogubić. Patrząc na grafy , od strzału przypominam sobie o co mi chodziło i mogę modyfikować układ.

    Czytam temat od początku do końca i na odwrót i nigdzie nie widzę żebym tak napisał. Po opisie w HDL'u tak samo jest + większa swoboda. Nie uzależniasz się od algorytmów implementowanych Bóg wie w jaki sposób od firmy zewnętrznej. To Ty decydujesz w jaki sposób ma optymalizację przebiegać i w którym miejscu użyć one-hot'a czy Johnons'ona.
    logison napisał:
    Odp.: BUSINESS i POLITYKA. Z tego właśnie powodu śledzie dopuszczone do obrotu muszą mieć określony wymiar , a banany określoną "krzywistość" .

    Jakby chodziło tutaj o użyte głośno hasło BUSINESS, to Xilinx by nie umieszczał wszystkich Swoich wcześniejszych wersji ISE/SDK/EDK razem z najnowszymi aktualizacjami przed wydaniem nowego ISE/SDK/EDK z pełnym supportem technicznym. I nałożył głupie blokady do 30-dni. Interesują Ciebie generatory testebench'a i FSM? Jak już pisałem wcześniej, znajdziesz je do wersji 10.3. Licencja nie jest wiążąca:/ Więc naprawdę robisz "z widły, pomidły". To nie jest polityka, tylko czyste "nowoczesne" rozwiązania inżynierskie, żeby przechodzić na zewnętrzne programy Add-on, które można podejrzeć i modyfikować do własnych potrzeb, a nie zdać się na zamknięte algorytmy, tylko dlatego że licencja nie pozwala. Powody odejścia od takiego stanu od wersji 11.x, znajdziesz na forum Xilinx'a. Sami najwięksi projektanci (zawodowcy) w FPGA, naciskali na ten fakt:/
    logison napisał:
    6. Pytasz o przykłady.. Od groma i trochę !! Pierwszy z brzegu :
    http://www.timingtool.com/

    Płatna, ograniczona wersja, o których pisałem wyżej. Istnieją też darmowe, lub użycie skryptów z Matlab'a/SciLab'a:/ Przykład z brzegu nie najlepszy.

    Pewnie niedługo znowu doczekamy się zmiany wersji lub aktualizacji, bo w ciągu dwóch lat mają wejść na rynek nowe układy FPGA (Virtex-7 i jego odmiany Kintex-7 i Artix-7), w których zmieniono wiele rzeczy. Ale komu to potrzebne, jak stanęło się na leciwym 7.x. Ciekawe czy zauważyłeś, że nie trzeba już czekać w wersji 12.x (było już od 11.x) na wygenerowanie "szlaczków" (co za niespełna nazwa:/) w Isim?
    tymon_x napisał:
    No takiego doświadczenia można pozazdrościć.

    Odwołuje to, 10 lat w zawodzie, a nie wiedzieć o istnieniu SDK/EDK. Czyli nie mieć pojęcie o PowerPC w Virtexach i Microblazie. Już nie mówię o innych peryferiach wewnętrznych jak bloki mnożące? I wykładać innym, braku inżynierskiego podejścia, jak się go samemu nie ma:/

    Lepiej w bijać gwóźdź młotkiem, niż kamieniem.

    Zgadzam się z TWI, nie dodałem "lub Verilogu" tylko z rozpędu jak pisałem posta.
  • Poziom 20  
    logison napisał:
    Niejednokrotnie (z autopsji) bywało , że symulacja jest OK , a układ 'milczy'. Z reguły wtedy , 'teoretycy' rozkładają ręce , praktycy 'wypuszczają' test-pin'a na oscyloskop , coś tam zmieniają i... DZIAŁA !!

    Dziwne. Mi się to nigdy nie zdarzyło. Nawet przy niezbyt-symulowalnych modułach, jak np. PLL z pikosekundowym przesuwnikiem fazy (nie mówię tu zasobach wewnętrznych FPGA - DCM, Alterowski PLL). Może po prostu piszę mój "trudno zrozumialny" kod w jakiś dziwny sposób, że symulacje zawsze zgadzają się ze sprzętem???

    Jeśli chodzi o testpiny, to - tak jak odpowiedział już Kolega tymon_x - jak masz kilka niezbyt szybkich sygnałów, owszem, zdebugujesz w ten sposób swój projekt. Ciekawe, czy takimi testpinami sprawdzisz niedziałający Xilinxowy GTP pędzący dane z prędkością 3.125 Gbps. Zwlaszcza, że połowa z nich będzie albo piekielnie szybka (masz oscyl o takim paśmie?), albo niemożliwa do wyprowadzenia na zewnątrz układu ze względu na ograniczenia architektury FPGA.

    Cytat:

    Odnoszę wrażenie , że nie czujesz problemu od strony typowo inżynierskiej , a więc (pomysł na produkt)=>projekt=>symulacja(soft)=>weryfikacja+poprawki(hard) prototypu=>produkcja.
    Jak mam mieć stimulus na byle bzdetę jak chociażby CLK , kilkadziesiąt linii kodu , to dziękuję.


    Odnoszę wrażenie, że za bardzo polegasz na swoich "odnoszonych wrażeniach". Może nie mam 10-ciu lat doświadczenia, ale jakoś sobie radzę. Jako teoretyk, potrafię nawet projektować PCB i przygotować produkcję :)

    A jeśli chodzi o generację byle bzdetów, jak zegary, to chyba pomyliły Ci się linie ze znakami:

    Code:

    always #(period/2) clk<=~clk;


    Cytat:

    3. Jak testować SERDESA ?? A po co ?? Taką duperelę ?? 32 kanały 12-to bitowe odpaliły od strzału.


    Miałem na myśli taką duperelę: http://www.xilinx.com/support/documentation/user_guides/ug386.pdf.


    Cytat:

    5. Skoro się nie gubisz w 10000 liniach kodu , to szacun !! Ja dziękuję.. Wybieram 'szlaczki'. Idę o zakład , że w dobrym środowisku projektowym (np. ACTIVE-HDL) jestem w stanie zrobić testbencha szybciej w odwrotności do jakiejś tam potęgi ilości testowanych sygnałów , niż Ty dziubiąc to tekstowo w dowolnym HDL.


    Dziękuję. Moje ego czuje się mile połechtane :). Jeśli chodzi o dobre środowiska projektowe, to moim skromnym zdaniem Active HDL trudno do nich zaliczyć, zwlaszcza z powodu, że kompilator rozumie tylko własny dialekt VHDLa/Veriloga i moduły działające w Modelsime/Cadence/Icarusie zwyczajnie się nie kompilują.


    Cytat:

    6. Pytasz o przykłady.. Od groma i trochę !! Pierwszy z brzegu :
    http://www.timingtool.com/


    Spoko, kolejne "narzędzie" do kupienia, kolejne 1300 $ w kieszeni mniej...

    Pozdrawiam.
    TWl