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

Symulacja Post-Route, jak w jednym czasie mieć 2 modele?

08 Kwi 2008 19:32 1563 20
  • Poziom 12  
    Witam,

    Chciałbym przetestować zgodność dwóch opisów (jeden opisany za pomocą prymitywów, drugi w sposób behawioralny). Ponieważ symulacja musi być jak najbardziej odpowiadająca rzeczywistości, chciałbym wykonać symulację Post-Route. Stworzyłem test-bench, który zawiera 2 komponenty, na które podawane są jednakowe sygnały wejściowe i sprawdzam czy stan wyjść się zgadza. Niestety jak tworzę model do symulacji Post-Route, to drugi wcześniej już utworzony model znika i koło się zamyka. Nie wiem jak w jednym czasie mieć do dyspozycji 2 modele.

    Od razu odpowiem dlaczego w taki sposób chce to testować. Ponieważ jeden komponent jest opisany za pomocą prymitywów i już zawiera czasy propagacji sygnałów między np. LUTami, a drugi jest opisany w sposób behawioralny i niestety nie zawiera tych czasów. Ponieważ chciałbym zbadać zgodność tych dwóch opisów, chce uzyskać jak najbardziej odające rzeczywistość sygnały.

    Pozdrawiam
  • PCBwayPCBway
  • Pomocny post
    Poziom 19  
    hmm, jakoś nie widzę problemu, przecież opis Post - place and route jest tworzony jako zwykły plik vhdl. wystarczy że w swoim testbenchu dołączysz ten opis jako komponent a jak drugi opis behawioralny i powinno grać.
  • Poziom 12  
    Dziękuje za szybką odpowiedź.

    Mam jeszcze jedno pytanie, jak już wygeneruje te modele (z tego co widzę zawierają wszystkie czasy) i stworzę test-bench zawierające te opisy, to jak wykonam symulację "behavioral simulation" będzie ona zawierała najbardziej odpowiadające rzeczywistości czasy?
  • Poziom 19  
    nie do końca cię rozumiem, z jakich programów korzystasz z ISE i ModelSima? a jeśli ModelSima to w jakiej wersji SE czy XE?
  • Poziom 12  
    Używam ISE i ModelSim XE.

    Chodzi mi o to że ISE na podstawie opisu generuje model (Post-Place & Route Simulation Model). Ten opis jest dostępny później na zakładce Post-Route Simulation. Ja go kopiuje i tworze nowy plik ("Module") i przypisuje do niego test-bench. Później symuluje.

    Cały ten zabieg potrzeby jest po to aby mieć dostępne na raz dwa modele Post-Place&Route.

    Czy takie zabiegi będą odpowiadały symulacji Post-Route ?

    Mam nadzieje, że teraz jest trochę jaśniej napisane.
  • PCBwayPCBway
  • Poziom 28  
    Lukee napisał:
    Witam, Chciałbym przetestować zgodność dwóch opisów
    (jeden opisany za pomocą prymitywów, drugi w sposób behawioralny).

    obawiam sie, ze to jakies nieporozumienie;
    jesli juz wybrales metode testowania taka, ze porownujesz odpowiedz
    2 roznych modulow, robiacych teoretycznie to samo [co jako metoda
    testowania jest dla mnie lekko dyskusyjne] to mieszanie roznych
    opisow kompletnie nic ci nie da, nie mowiac juz o tym, ze twozenie
    algorytmu za pomoca 'prymitywow' nie jest zalecana metoda;

    Lukee napisał:
    Ponieważ symulacja musi być jak najbardziej odpowiadająca
    rzeczywistości, chciałbym wykonać symulację Post-Route.


    jest 'najbardziej odpowiadająca rzeczywistości' ale nie w tym sensie,
    o ktory ci chodzi na tym etapie, na ktorym najwyrazniej teraz jestes;
    metodologia w twoim przypadku powinna [moim zdaniem] byc taka:
    tworzysz top-level z dwoma roznymi modulami i testbench, ktory podaje
    te same wymuszenia na kazdy z nich i porownuje wyjscia;
    jesli jestes zadowolony z wynikow, kompilujesz jeden modul,
    tworzysz netliste post place&route i ponownie symulujesz, tym razem
    porownujac wyniki z wynikami symulacji rtl;

    rzecz w tym, ze zachowanie twojej post p&r netlisty zalezy od
    rozmieszczenia logiki i uzytych polaczen, dodanie do kompilacji
    drugiego modulu 'referencyjnego' zmienia to rozmieszczenie, a wiec
    i zmienia zachowanie czesci ktora chcesz testowac;

    mozna sobie wyobrazic sytuacje, ze twoj uklad testowy:
    modul testowany-modul referencyjny dziala poprawnie,
    potem kompilujesz juz sam projekt docelowy bez testowych
    dodatkow i nie dziala;
    mozna sobie tez wyobrazic sytuacje odwrotna;

    J.A
  • Poziom 12  
    Dziękuje za odpowiedź. Chyba problem leżał w metodologii testowania. Moduł opisany za pomocą prymitywów nie jest mój, tylko został stworzony przez inną osobę. Ja mam uzyskać moduł identyczny pod względem działania, opisany w sposób behawioralny. Wynikiem tych prac ma być stwierdzenie, czy narzędzie do syntezy dało sobie radę i utworzyło porównywalne struktury , czy też nie. Dotychczas porównywałem oba opisy ręcznie, porównując "Technology Schematic".

    Chyba tak zrobię jak napisałeś.

    Problem mój wynikał z tego że już na etapie symulacji rtl modułu opisanego za pomocą prymitywów był uwzględniany czas propagacji sygnału, natomiast w przypadku opisu behawioralnego niestety nie.

    Szczerze nadal nie wiem czy się dobrze zabieram do tego zadania. Porównując "Technology Schematic" dwóch modułów często uzyskuje bardzo podobne struktury lub nawet identyczne.
  • Poziom 18  
    Lukee napisał:
    Dziękuje za odpowiedź. Chyba problem leżał w metodologii testowania. Moduł opisany za pomocą prymitywów nie jest mój, tylko został stworzony przez inną osobę. Ja mam uzyskać moduł identyczny pod względem działania, opisany w sposób behawioralny. Wynikiem tych prac ma być stwierdzenie, czy narzędzie do syntezy dało sobie radę i utworzyło porównywalne struktury , czy też nie. Dotychczas porównywałem oba opisy ręcznie, porównując "Technology Schematic".


    To temat raczej akademicki. Istnieje cała dziedzina poświęcona temu zagadnieniu (ang. Formal Verification) i zdaje się że istnieje też software automatyzujący ten proces, kojarzę nazwę Verify czy jakoś tak.

    Lukee napisał:
    Problem mój wynikał z tego że już na etapie symulacji rtl modułu opisanego za pomocą prymitywów był uwzględniany czas propagacji sygnału, natomiast w przypadku opisu behawioralnego niestety nie.


    Opóźnienia zależą od modeli primitywów jakich używasz w czasie symulacji. Możesz wykomentować opóźnienia ze źródeł modeli. Możesz też uwzględnić opóźnienia projektu Post-Route (w flow Xilinx-a słuzy do tego plik typu *.sdf generowany opcjonalnie). Ale chyba nie tędy droga.

    Tak czy inaczej opóźnienia zawsze mogą się trochę różnić. Dlatego należy ustalić z jaką dokładnością sprawdzamy wyniki:

    - do "delty symulacyjnej"
    - do chwili czasowej
    - do taktu zegara
    - do poprawności przesyłanych danych
    - albo i mniejsza

    i odpowiednio zapisywać/porównywać wynik.

    Nie wiem jakie kryterium przyjąłeś przy porównywaniu wyników, ale biorą pod uwagę że jeden opis jest behawioralna a drugi raczej strukturalny to kryterium nie może być zbyt ostre.
  • Poziom 12  
    To w takim razie będę musiał coś poczytać na temat "Formal Verification". Wydaje mi się że znalazłem odpowiednią książke "D.Perry - Applied Formal Verification".
  • Poziom 12  
    Niestety tą oprogramowanie jest pewnie bardzo drogie. Z tego co widzę nie ma wersji "student" lub podobnej.
  • Poziom 12  
    Niestety widzę, że takiego oprogramowania nie zdobędę (ceny to kilkadziesiąt tys $). Znalazłem kilku producentów, niestety nikt nie udostępnia wersji "Student" lub podobnej. Może ktoś wie, czy istnieje darmowe oprogramowanie.
  • Poziom 18  
    Lukee napisał:
    Niestety widzę, że takiego oprogramowania nie zdobędę (ceny to kilkadziesiąt tys $). Znalazłem kilku producentów, niestety nikt nie udostępnia wersji "Student" lub podobnej. Może ktoś wie, czy istnieje darmowe oprogramowanie.

    Gdybym nie musiał się udzielać w pracy zawodowej to bym się właśnie czymś takim zajął. Jakbyś znalazł jakiś projekt Open Source to daj znać.
  • Poziom 28  
    Lukee napisał:
    /.../Może ktoś wie, czy istnieje darmowe oprogramowanie

    daj sobie spokoj, proba uzycia narzedzia do formalnej weryfikacji w twoim
    przypadku to troche przesada;
    co ty wlasciwie robisz - to sa cwiczenia na studiach, prowadzacy zajecia
    dal wam schemat czy tez ascii file wykorzystujacy prymitywy, a wy macie
    stworzyc taki sam funkcjonalnie rtl ?
    nie powiem, co mysle o takich cwiczeniach ...

    zrob top level, w ktorym bedzie implementacja twojej wersji
    i tej wersji 'prymitywnej';
    oba moduly podlacz 'rownolegle' do tych samych wejsc top-level;
    wyjscia 'twoje' i 'prymitywne' zatrzaskuj w rejestrze, oba rejestry
    na komparator;
    skompiluj i zrob symulacje post place&route;
    jesli komparator bedzie mial staly poziom wyjscia 'rowne',
    bedziesz mial dowod, ze twoj opis rtl jest zgodny ze wzorcem;

    J.A
  • Poziom 12  
    W podobny sposób robiłem. Tylko, że w test-benchu, do porównywania użuwałem "assert".

    Co robię - piszę PicoBlaze.
    W jaki sposób - wyciągam kolejne jednostki (entity), analizuje jak działają (opis, dostępna dokumentacja) i opisuje je w sposób behawioralny.

    Dotychczas sprawdzałem porównując "technology schematics" mojego opisu i opisu Kena Chapmana. Dokładnie tego jeszcze nie wiem, ale chyba Top-Level zostanie jego, tylko wszystkie jednostki opisane przez niego za pomocą prymitywów zostaną zastąpione moim opisem. Z tego co widzę w dużej części modułów uzyskuje identyczne wyniki (czasami różnica to tylko zamienione wejścia LUTów, albo FDE (CE podciągniete do 1) zamiast FD). Znacznie większe struktury uzyskuje jeśli chodzi o operacje arytmetyczne, ale tego się spodziewałem. W jednym przypadku udało mi się uzyskać w opisie o 1 LUT mniej (sprawdzałem kilka razy - technology schematics) i wszystko wygląda, że działa tak samo (choć na 100% to nie jestem pewien). Tak wygląda co robię.

    Chciałem to jakoś zautomatyzować, jeszcze raz się upewnić, że uzyskane wyniki sobie odpowiadają.
  • Poziom 18  
    Lukee napisał:
    Co robię - piszę PicoBlaze.

    A wiesz może po co? Zastanawiałeś się co zyskujesz przepisując ogólnie dostępny kod? Jedyne co mi przychodzi na myśl to przenoszenie do innej technologii. Czyżby prowadzący chciał przenieść istniejące oprogramowanie na inna platformę kosztem syzyfowej pracy studentów?

    Jak już będziesz miał zaliczenie(ewentualnie absolutorium) to napisz kto i na jakiej uczelnii kazał w ramach zajęć przepisywać PicoBlaze-a, ja chętnie sam bym się dowiedział i przekazał swoim znajomym.

    Pamięci też przepisujesz? czy masz zrobić wrapper na jakiś ogólny model pamięci?

    Dodano po 5 [minuty]:

    J.A napisał:

    daj sobie spokoj, proba uzycia narzedzia do formalnej weryfikacji w twoim
    przypadku to troche przesada;

    Tak jak pisał J.A daj sobie spokój z narzędziami do formal verification, to "armata na muchy" i nie daje odpowiedzi jak to trzeba napisać. Jakbyś miał problem z przepisaniem(zinterpretowaniam) czegoś to wrzuć do wątku albo jakby można było Ci jakoś pomóc to wal śmiało :|
  • Poziom 12  
    Raczej z interpretacją nie mam problemu. Pisze się łatwo i przyjemnie :-).

    Według mnie są 2 powody:
    - przenoszenie na FPGA innych producentów
    - sprawdzenie, czy faktycznie, konieczne było opisanie układu na takim niskim poziomie - z tego co widzę narzędzie do syntezy w większości przypadków daje sobie doskonale radę.


    Cytat:
    Pamięci też przepisujesz? czy masz zrobić wrapper na jakiś ogólny model pamięci?


    Nie wiem czy o to chodzi :). Pamięci także opisuję w sposób behavioralny.
    Po syntezie dostaje Distributed RAM, więc tak samo jak w PicoBlaze.

    Cytat:
    Jak już będziesz miał zaliczenie(ewentualnie absolutorium) to napisz kto i na jakiej uczelnii kazał w ramach zajęć przepisywać PicoBlaze-a, ja chętnie sam bym się dowiedział i przekazał swoim znajomym.


    Dziwnie się poczułem ;) .... tylko nie wiem dlaczego chcesz opowiadać znajomym ? :)

    Narzędzie do "formal verification" chciałem poznać także z ciekawości.
  • Poziom 18  
    Lukee napisał:

    Dziwnie się poczułem ;) .... tylko nie wiem dlaczego chcesz opowiadać znajomym ? :)

    Jako ciekawostkę, przestrogę. :D Jeśli taki jest model kształcenia na polskich uczelniach to wymaga to napiętnowania. :D

    Lukee napisał:
    - sprawdzenie, czy faktycznie, konieczne było opisanie układu na takim niskim poziomie - z tego co widzę narzędzie do syntezy w większości przypadków daje sobie doskonale radę.

    Kompilator C też w wolnych chwilach testujesz czy sobie radzi?;)

    Staram się sobie tłumaczyć że PicoBlaze nie jest taki duży i może coś z tego wyniesiesz, ale bardziej twórcze byłoby stworzenie jakiegoś sytemu w oparciu o PicoBlaze. A tak to nie wiem czy to przejaw dręczenia studentów czy ktoś próbuje doktorat realizować w ramach laboratorium. :D

    Dodano po 5 [minuty]:

    Lukee napisał:
    Cytat:
    Pamięci też przepisujesz? czy masz zrobić wrapper na jakiś ogólny model pamięci?


    Nie wiem czy o to chodzi :). Pamięci także opisuję w sposób behavioralny.
    Po syntezie dostaje Distributed RAM, więc tak samo jak w PicoBlaze.


    O.K. akurat PicoBlaze to nie jest najlepszy przykład :D m.in. pamięci są zależne od technologii, choć obecne narzędzia radzą sobie i z tym, Distributed RAM to generalnie porażka, ale akurat do PicoBlaze-a wystarcza.
  • Poziom 19  
    PicoBlaze został napisany na tak niskim poziomie, żeby być jak najbardziej dopasowanym do architektury. Myślę że przy okazji zniechęca to innych do przenoszenia tego na inne platformy, no za wyjątkiem Ciebie.
  • Poziom 18  
    Lukee napisał:
    Raczej z interpretacją nie mam problemu. Pisze się łatwo i przyjemnie :-).

    O.K., niepotrzebnie się nakręcam, bo widzę że ty to lubisz ;)

    Pozdrawiam słonecznie :idea:
  • Poziom 12  
    Coś tam zawsze się wyniesie :)

    Poziom na uczelniach jaki jest, taki jest i myślę, że to nie jest problem jednej uczelni. O modelu kształcenia się nie będę wypowiadał, bo odnoszę wrażenie, że go nie ma, a dużo rzeczy robiona jest w sposób chaotyczny.

    Szczerze to bym wolał popracować dla kogoś i robić naprawdę ciekawe projekty (FPGA), ale firm zajmujących się tym tematem jakoś w Polsce jest mało.

    Lubię FPGA - ale czasami, trzeba motywacji, aby iść dalej, czasami ktoś coś musi ci pokazać i takie tam ;)