1. Wstęp

1. Wstęp

Urządzenia elektroniczne od wielu lat są wykorzystywane jako aparatura do wykonywania pomiarów, przy czym poziom skomplikowania tej aparatury zależy od problemu postawionego w eksperymencie oraz poziomu technologicznego jakim dysponujemy. Stąd wykorzystanie aparatury może sięgać od niedokładnego multimetru, aż do rozproszonej sieci systemów pomiarowych, składających się urządzeń najwyższej klasy, wykonujących ogromne ilości zautomatyzowanych oraz zsynchronizowanych pomiarów.

W niniejszej pracy został opisany proces budowania aparatury pomiarowej, obsługiwanej komputerowo, służącej do mierzenia i wytwarzania przebiegów sygnału napięciowego. Proces ten obejmuje wykorzystanie zarówno nietrywialnych narzędzi projektowych dostępnych na dzisiejszym rynku jak i również wykorzystanie rozwiązań sprzętowych i programistycznych typu open-source. Tak przygotowane środowisko projektanta umożliwiło integrację dostępnych jednostek funkcjonalnych w pełny system pomiarowy.

 

1.1. Systemy rozproszone

Systemy Rozproszone (z ang. distributed systems) są to systemy składające się z wielu samodzielnych jednostek funkcjonalnych, połączonych w jedną całość przy pomocy sieci komunikacyjnej i rozproszonego oprogramowania. Trzema wyróżniającymi cechami takich systemów są:

1. Przezroczystość – system nie jest obsługiwany przez użytkownika jako zbiór pojedynczych jednostek lecz jako jednolita całość,

2. Skalowalność/Odwracalność – do zaprojektowanego systemu można w łatwy sposób dołączać/odłączać jednostki funkcjonalne,

3. Współbieżność – system jest zdolny do wykonywania wielu zadań w tym samym czasie.

Pewną klasę takich systemów tworzą Rozproszone Systemy Pomiarowe (RSP [1]). Elementy takiego systemu (węzły) rozmieszczane są terytorialnie i są ze sobą połączone przewodami (sieci komputerowe, przemysłowe etc.) lub bezprzewodowo (podczerwień, radio, Bluetooth [2]). Jednostkami systemu są typowo urządzenia pomiarowe (jednostki wykonawcze) i sterujące (kontrolery). RSP mogą być sklasyfikowane według stopnia zapotrzebowania na obsługę:

• Wymagana sporadyczna kontrola i sporadyczne sterowanie. W takich systemach jednostki funkcjonalne są zdolne do podejmowania większości decyzji niezależnie, a wyniki ich pomiarów są odczytywane okresowo. Takimi systemami mogą być stacje meteorologiczne, których pomiary są odczytywane jedynie okresowo ze względu na względnie powolny charakter zmian warunków pogodowych.

• Wymagana ciągła kontrola i sporadyczne sterowanie. W takich systemach, podobnie jak powyżej, jednostki podejmują w większość decyzji niezależnie, ale wyniki ich pomiarów są odczytywane w sposób ciągły. Takime systemy może stanowić aparatura medyczna, pod którą podłączani są pacjenci, gdy ich stan wymaga ciągłej kontroli, a decyzja np. o wyłączeniu aparatury jest podejmowana rzadko.

• Wymagana ciągła kontrola i ciągłe sterowanie - Systemy Czasu Rzeczywistego (z ang. Real Time Computiing [3]). Są to systemy, których wyniki pomiarów mają decydujący wpływ na pracę innych jednostek funkcjonalnych, a decyzję o działaniu (na podstawie wyników pomiarów) należy podjąć w możliwe najkrótszym czasie.Tego typu systemy wykorzystuje się np. w myśliwcach do precyzyjnego sterowania lotem.

Podstawowymi strukturami RSP są:

• Struktura multiplekserowa, charakteryzująca się topologią gwiazdy, gdzie wymiana informacji przekazywana jest jednokierunkowo,

• Struktura sieciowa, charakteryzującą się topologią magistralową, gdzie komunikacja zachodzi dwukierunkowo.

Rozproszonym systemem pomiarowym typu sieciowego jest Modularny System Fotoniczny (MSF [4]) opracowany w laboratorium PERG/ELHEP.

1.2. Modularny System Fotoniczny

Celem opracowania MSF było zespolenie różnych czujników fotonicznych w węzłach. Zadaniami MSF są m. in.:

• Sterowanie procesami pomiarowymi z poziomu sprzętowego i programistycznego,

• Zautomatyzowane przetwarzanie i akwizycja danych,

• Ciągła kontrola i diagnozowanie w celu utrzymania jakości pomiarów.

Węzły mogą pracować w konfiguracjach pojedynczej jednostki lub jako element struktury rozproszonej. Na rys. 1.1 przedstawiono powyżej opisane konfiguracje.

 

Rysunek 1.1. MSF - konfiguracje [5] (VME - Versa Module European [6], krata VME [7])

W ramach prac badawczo-rozwojowych w laboratorium PERG został opracowany węzeł systemu MSF oraz jednostki funkcjonalne rozszerzające jego możliwości. Wspólnie tworząc, tzw. Pełny Węzeł Modularnego Systemu Fotonicznego (PWMSF).

1.3. Pełny Węzeł Modularnego Systemu Fotonicznego

Podstawowym węzłem MSF jest płyta bazowa o nazwie "Universal Module Controller" (UMC [8]) przedstawiona w rozdziale 1.3.1. W celu rozszerzenia funkcjonalności UMC zostały wykonane 2 karty PMC (PCIMezzanine Card [9]) nazwane "Data Acqusition Card" (DAC [10]) oraz "Digital Interface Card" (DIC [11]), które zostały opisane kolejno w rozdziałach 1.3.2 i 1.3.3. Opis kompletnego PWMSF i środowiska jego pracy został przedstawiony w rozdziale 1.3.4.

 

1.3.1. Płyta UMC

 

Płyta UMC, prezentowana na rys. 1.2, została wykonana w standardzie mechanicznym EURO-6HE [12] o rozmiarze B (6U - Size B) i jest zgodna elektrycznie ze standardem VME/VXI (VXI - VME eXtensions for Instrumentation [13]).

 

Rysunek 1.2. Płyta UMC [5]

Elementami płyty bazowej UMC są interfejsy komunikacyjne, układ FPGA (Field Programmable Gate Array [14]) mogący pełnić funkcję translacji protokołów (Glue-logic), oraz złącza PMC. Na rys. 1.3 prezentowane są w formie blokowej zasoby płyty.

 

Rysunek 1.3. Schemat blokowy UMC [15]

UMC wyposażono w Ethernet [16] i gigabitowe łącza światłowodowe. Dodatkowo UMC obsługuje magistrale CAN_BUS (Controler Area Netwoek Bus [17]), RS232 (Recommended Standard 232 [18]), USB (Universal Serial Bus [19] ) oraz port drukarkowy EPP (Enhanced Parallel Port [20]). UMC zawiera system automatycznej konfiguracji uruchamiany po włączeniu zasilania (bootowania). Użytkownik może wybrać odpowiedni tryb konfiguracji:

• SystemACE (System Advanced Configuration Environment [21]) i karty Compact Flash,

• EEPROM konfiguracyjny,

• programator wpięty w łańcuch JTAG (dawniej Joint Test Action Group, - dziś Standard - Test Access Port and Boundary-Scan Architecture[22])

Centralnym elementem UMC jest układ FPGA Virtex II Pro [23](XC2VP30) firmy Xilinx. Układ ten zawiera 30816 komórek LCELL2, 2448 Kb pamięci wbudowanej Block SelectRAM+ [24] o podwójnym dostępie (DUAL-PORT SRAM), 8 układów DCM (Digital Clock Manager [25]), 136 wbudowanych układów mnożących 18x18 bitów, 8 modułów RocketIO [26] pozwalających na bezpośrednią integrację z konwerterami optycznymi, dwa wbudowane 32-bitowe procesory Power-PC 405a klasy RISC (Reduced Instruction Set Computers [27]). Na płycie znajdują się również dwa układy pamięci SD-RAM MT48LC32M16A2 [28] o pojemności 512Mb połączone wspólną szyną adresową w 1024Mb podzielone na 16-bitowe słowa. Całość taktowana jest zegarem 20MHz.

PWMSF posiada również dwa złącza IEEE 1386 Mezzanine Connector umożliwiające rozszerzanie funkcjonalności węzła poprzez dołączanie kart nakładkowych wykonanych w standardzie PMC.

 

1.3.2. Płyta nakładkowa DAC

 

Karta DAC, pokazana na rys. 1.4, została wyposażona przetworniki Analogowo/Cyfrowe (A/C, z ang. Analog-Digital A/D [29]) o maksymalnej częstotliwości próbkowania 100MHz oraz przetworniki Cyfrowo/Analogowe (C/A, z ang. Digital-Analog D/A [29]) generujące sygnały z pasma 0–20MHz.

 

Rysunek 1.4. Płyta DAC [10]

Elementami płyty nakładkowej DAC, poza przetwornikami A/C oraz C/A, są układ FPGA mogący pełnić funkcję Glue-logic oraz sterowania i konfiguracji przetworników oraz układy dystrybucji zegara oraz złączę PMC. Poniżej na rys. 1.5 prezentowane są ideowo zasoby płyty.

 

Rysunek 1.5. Schemat blokowy DAC [10]

DAC wyposażono w dwa jednokanałowe przetworniki A/C (LTC2207 [30]) oraz jeden dwukanałowy przetwornik C/A (AD9777 [31]). Podstawowe parametry przetworników zestawiono w tabeli 1.1.

 

Tabela 1.1. Podstawowe parametry przetworników [10]

Przetworniki posiadają następujące opcje konfiguracyjne;
LTC2207 :

• możliwość pracy w trybie wewnętrznego ditheru,

• możliwość randomizacji danych wyjściowych za pomocą operacji: out[15..1] = XOR(out[15..1], out[0]),

• stabilizator współczynnika wypełnienia zegara,

• wskaźnik przepełnienia zakresu.

AD9777 :

• filtr interpolujący próbki wyjściowe (obieralny stopień interpolacji: 2x/4x/8x),

• programowalne wzmocnienie oraz składowa stała dla każdego kanału,

• wewnętrzny powielacz zegara z pętlą fazową,

• programowalny wewnętrzny podzielnik zegara.

W celu dystrybucji sygnału zegarowego taktującego przetworniki zostały wykorzystane układy AD9512 [32] oraz MAX9452 [33]. Zadaniem AD9512 jest translacja standardu elektrycznego LVDS wejściowego sygnału zegarowego, na standardy obsługiwane przez przetworniki (A/C–LVDS, C/A–LVPECL). Dodatkową możliwością tego układu jest między innymi skonfigurowanie dzielnika częstotliwości dla każdego wyjścia oddzielnie (czyli dla obu kanałów C/A, dla 1 kanału A/C i osobno dla 2 kanału A/C). Zadaniem MAX9452 jest minimalizacja jitteru sygnału zegarowego (pochodzącego z układu FPGA). Wyjściowy sygnał z MAX9452 jest wprowadzany na układ AD9512 w celu translacji standardu elektrycznego i może być doprowadzony do przetworników. Wadą układu MAX9452 jest maksymalna częstotliwość wyjściowa, wynosząca 11MHz ze względu na wykorzystany na płycie DAC oscylator do którego jest podłączony MAX9452. Elementem zespalającym wszystkie układy jest układ FPGA Cyclone (EP1C20F324C6) firmy Altera [34]. Podstawowe parametry układy Cyclone zestawiono w tabeli 1.2. Całość może być taktowana dostępnym na płycie zegarem 100MHz.

 

Tabela 1.2. Podstawowe parametry Cyclone EP1C20F324C6 [10]

1.3.3. Płyta nakładkowa DIC

 

Karta DIC, pokazana na rys. 1.6, rozszerza możliwości węzła o funkcje komunikacji poprzez takie interfejsy jak GPIB (General Purpose Interface Bus [35]), I2C (Inter-Integrated Circuit [36]), JTAG oraz dwa dodatkowe interfejsy RS-232C. Interfejsy te są typowymi interfejsami licznych urządzeń pomiarowych.

 

Rysunek 1.6. Płyta DIC [11]

Wszystkie interfejsy podłączone są poprzez odpowiednie bufory [11] do układu FPGA Cyclone (EP1C20F324C6) firmy Altera. Poniżej na rys. 1.7 prezentowany jest schemat ideowy płyty DIC i połączeń interesów z układem FPGA.

 

Rysunek 1.7. Płyta DIC [11]

 

1.3.4. Konfiguracja sprzętowa PWMSF

 

PWMSF może być umieszczony w kracie Eurocard (VME), co umożliwia komunikację z innymi płytami w kracie oraz z innymi urządzeniami wykorzystując cały zbiór peryferii z samego PWMSF. Komunikacja z innymi węzłami MSF odbywa się za pośrednictwem łącz optycznych. Dodatkowo PWMSF może zostać dołączony do sieci lokalnej lub internetowej dzięki interfejsowi Ethernet na płycie UMC. Poniżej od góry prezentowane jest połączenie płyt w PWMSF (rys. 1.8) wraz z wyprowadzeniami JTAG oraz włożony węzeł do kraty VME wraz z kluczowymi dla systemu pomiarowego interfejsami.

 

Rysunek 1.8. PWMSF w kracie VME (na górze). Węzeł w kracie VME (na dole) [5]

 

---------------------------

1. Wiesław Winiecki. Rozproszone Systemy Kontrolno Pomiarowe – wykład, 2008.

2. Bluetooth SIG. Specification of the Bluetooth System. http://www.bluetooth.com/Bluetooth/ Technology/Building/Specifications/, Listopad 2004.

3. Krzysztof Sacha. Systemy czasu rzeczywistego. Oficyna Wydawnicza Politechniki Warszawskiej, 1999.

4. Artur Dybko, Rafał Graczyk, Krzystof T. Po´zniak, Ryszard S. Romaniuk. Modularny system fotoniczny z programowalną warstwą sterowania i komunikacji w układzie FPGA, 2006.

5. Samer Bou Habib, Ryszard Romaniuk. Opracowanie Mostu PCI dla Węzła Modularnego Systemu Fotonicznego. Politechnika Warszawska, 2008.

6. Wade D. Peterson. The VMEbus Handbook 2nd edition. VITA.

7. WIENER. Series 6000 VME, -64x, -64xC, -64xP, VXI User’sManual. http://www.wiener-d/com/documents/contentdocuments/7.pdf.

8. Rafał Graczyk, Krzysztof T. Poźniak, Ryszard S. Romaniuk. FPGA based, modular, configurable controller with fast synchronous optical network. Proc of SPIE vol. 6347 part one, 2006.

9. IEEE Standard Physical and Environmental Layers for PCI Mezzanine Cards (PMC). ieeexplore.ieee.org/iel5/7509/20428/00944007.pdf, 2001.

10. Łukasz Dymanowski. Projekt i wykonanie modułu akwizycji danych z wykorzystaniem standardu PMC. Politechnika Warszawska, 2007.

11. Kamil Lewandowski. Projekt i wykonanie karty PMC z interfejsami komunikacyjnymi. Politechnika Warszawska,  2007.

12. VMEbus Card Form Factors. http://www.interfacebus.com/Design_VME_Card_size.html.

13. VME eXtensions for Instrumentation. http://www.vxibus.org/.

14. PartMiner, Inc. FPGA (FIELD-PROGRAMMABLE GATE ARRAY). http://www.partminer.com/glossaryhtml/fpga_field_programmable_gate_array..., 2005.

15. Rafał Graczyk, Krzystof T. Poźniak. Projekt i uruchomienie uniwersalnego kontrolera szyny VME: ”Universal Module Controller”. Praca magisterska, Politechnika Warszawska, 2009.

16. IEEE. IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements. http://standards.ieee.org/getieee802/802.3.html, 2008.

17. BOSCH. CAN Specification Version 2.0. www.semiconductors.bosch.de/pdf/can2spec.pdf, Czerwiec 1991.

18. Peter L. B. Johnson. Summer 2004 Laboratory Notes: Computer Engineering II. http://courses.ece.illinois.edu/ece390/books/labmanual/serial-comm-standards.html.

19. USB Implementers Forum, Inc. Universal Serial Bus Revision 2.0 specification. http://www.usb.org/developers/docs/usb_20_122909-2.zip.

20. Clark L. Buxton, Robert A. Kohtz. Enhanced Parallel Port, US Patent number: 5636348. http://v3.espacenet.com/textdocfiDB=EPODOC&IDX=EP0640229.

21. Xilnix. System ACE. http://www.xilinx.com/support/documentation/system_ace_solutions. htm.

22. Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. http://focus.ti.com/lit/an/ssya002c/ssya002c.pdf, 1997.

23. Xilinx. Xilinx virtex ii pro platform fpga : Complete data sheet. www.xilinx.com/support/documentation/data_sheets/ds083.pdf, 2007.

24. Xilnix. Block SelectRAM+. http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/products/xaw/memory/embedded/blockram.htm.

25. Xilnix. Digital Clock Manger. http://www.xilinx.com/itp/xilinx7/books/data/docs/s3edl/s3edl0021_13.html.

26. Xilinx. RocketIOTM Transceiver User Guide. www.ee.ucla.edu/~herwin/ocdma/afx-300/ug024.pdf.

27. Jan Ogrodzki. Wst˛ep do systemów komputerowych, rozdział 8. Oficyna Wydawnicza Politechniki Warszawskiej, 2005.

28. MICRON. MT48LC32M16A2 - Synchronous DRAM . http://www.datasheetcatalog.com/datasheets_pdf/M/T/4/8/MT48LC32M16A2.shtml.

29. Walt Kester. Analog-Digital Conversion. Analog Devices, Inc., 2004.

30. Linear Technology. LTC2207/LTC2206 Datasheet. http://www.linear.com/pc/downloadDocument.dofinavId=H0,C1,C1155,C1001,C1150,P13913,D9837.

31. Analog Devices. AD9777 Datasheet Rev Ct. http://www.analog.com/UploadedFiles/Data_Sheets/AD9777.pdf, Styczeń 2006.

32. Analog Devices. AD9512 Datasheet. http://www.analog.com/UploadedFiles/Data_Sheets/AD9512.pdf, Czerwiec 2005.

33. Maxim. MAX9450-MAX9452 Datasheet. http://datasheets.maxim-ic.com/en/ds/MAX9450-MAX9452.pdf.

34. Altera. Cyclone Device Handbook. http://www.altera.com/literature/hb/cyc/cyc_c5v1.pdf, 2006.

35. The Institute of Electrical and Electronic Engineers. GPIB : ANSI/IEEE Std 488.1-1987, IEEE Standard Digital Interface for Programmable Instrumetation, New York 1988.

36. Philips. THE I2C-BUS SPECIFICATION Version 2.1. http://www.nxp.com/acrobat/literature/9398/39340011.pdf, Styczeń 2000.

2. Geneza, cel i założenia pracy

2. Geneza, cel i założenia pracy

Po zakończeniu projektu aparaturowego [8], [10], [11], zaistniała potrzeba opracowania systemu pomiarowego zespalającego funkcjonalności płyt UMC, DAC oraz DIC w jeden węzeł PWMSF oraz wykonanie aplikacji użytkownika wspomagającej akwizycję oraz analizę danych. Dlatego opracowanie, wdrożenie i przetestowanie pełnego systemu, w skład którego wchodzą sprzętowe moduły i aplikacja użytkownika, stało się celem niniejszej pracy.

Cel podzielono na 3 etapy:

1. Wykonanie lub zaadoptowanie* niezbędnych modułów sprzętowych na potrzeby systemu akwizycji i analizy sygnałów

2. Zintegrowanie modułów sprzętowych akwizycji i analizy sygnałów w pełny i sprawnie działający system

3. Wykonanie aplikacji graficznej użytkownika (z ang. Graphical User Interface-GUI) wspomagającej w użytkowaniu systemu akwizycji i analizy sygnałów Pracę zrealizowano z następującymi założeniami początkowymi:

• Wykorzystanie blokowej transmisji danych,

• Wykorzystanie istniejącej wersji PWMSF,

• Wykorzystanie zasobów sprzętowych i narzędzi CAD dostępnych w pracowni PERG,

• Wykorzystanie oprogramowania typu open-source oraz bibliotekiWinApi do tworzenia GUI.

---------------------
* Przez zaadoptowanie rozumiane jest wykorzystanie gotowych lub zmodyfikowanych rozwiązań, albo wykorzystanie koncepcji zaczerpniętych z innych prac.

8. Rafał Graczyk, Krzysztof T. Po´zniak, Ryszard S. Romaniuk. FPGA based, modular,configurable controller with fast synchronous optical network. Proc of SPIE vol. 6347 part one, 2006.

10. Łukasz Dymanowski. Projekt i wykonanie modułu akwizycji danych z wykorzystaniemstandardu PMC. Politechnika Warszawska, 2007.

11. Kamil Lewandowski. Projekt i wykonanie karty PMC z interfejsami komunikacyjnymi. Politechnika Warszawska, 2007.

3. Koncepcja systemu pomiarowego

3. Koncepcja systemu pomiarowego

Koncepcja systemu pomiarowego została podzielona na dwie warstwy: sprzętową (firmware) oraz programową (software). W pierwszej kolejności została opracowana koncepcja warstwy sprzętowej, przedstawiona w roz. 3.1, gdyż rzutowała na kształt koncepcji warstwy programowej, przedstawionej w roz. 3.2.

 

3.1. Warstwa sprzętowa

Koncepcję warstwy sprzętowej podzielono na trzy części:

• konfigurację systemu i metodę komunikacji,

• sposób sterowania systemem,

• wykorzystanie i rozplanowanie zasobów FPGA.

3.1.1. Konfiguracja i metoda komunikacji

Rysunek 3.1 ideowo pokazuje konfigurację systemu oraz metodę komunikacji, które następnie zostały krótko opisane.

Rysunek 3.1. Konfiguracja systemu i sposób komunikacji [5]

 

Przyjęto konfiguracje systemu w formie master/slave (bez systemu przerwań). Rozwiązanie to jest proste w realizacji i wystarczające przy przetwarzaniu blokowym. Do realizacji systemu został wybrany sposób komunikacji Wishbone [37] (patrz dodatek A) z następujących powodów:

• prostoty implementacji,

• dostępności licznych modułów sprzętowych, wykorzystujących sposób Wishbone do komunikacji (tzw. moduły "Wishbone Compilant"), w bibliotece elementów Altium Designer 6.3 oraz na sieci internetowej (tzw. moduły open-core),

• braku ograniczeń na częstotliwość zegara,

• braku multipleksowanej szyny danych i adresowej.

Komunikacja Wishbone nie jest jednak rozwiązaniem standardowym. Komunikacja ta jest jednak szeroko wykorzystywana w modułach sprzętowych, zwłaszcza wśród projektantów związanych ze społecznościami open-source, dowodem tego jest powstawanie coraz większej ilości rozwiązań opartych o metodologię Wishbone, dostępnych między innymi na stronach www.opencores.org .

3.1.2. Sposób sterowania systemem

Na rysunku 3.2 pokazano ogólnie sposób sterowania systemem.

Rysunek 3.2. Sposób sterownia [5]

Ustalona z góry topologia połączeń (magistralowa) między UMC, a płytami nakładkowymi DAC i DIC, oraz fakt iż płyta UMC dysponuje licznymi cyfrowymi interfejsami wej/wyj, spowodowała wykorzystanie jej układu FPGA jako mostu systemowego. Zadaniem mostu jest odpowiednia translacja poleceń, wysyłanych z aplikacji użytkownika i wykonywanie ich na magistrali Wishbone. Do celów komunikacji GUI z UMC wykorzystano interfejsy szeregowe płyty UMC: RS232 i USB. Są one dostatecznie szybkie do celów blokowego przetwarzania danych.

3.1.3. Wykorzystanie i rozplanowanie zasobów

Rysunek 3.3 przedstawia wykorzystanie i rozplanowanie zasobów PWMSF i laboratorium PERG.

 

Rysunek 3.3. Wykorzystanie i rozplanowanie zasobów PWMSF i laboratorium PERG

Ustalono następujące wykorzystanie zasobów:

• Wykorzystanie przetworników A/C i C/A, znajdujących się na płycie DAC, realizujących odpowiednią konwersję sygnałów. W celu obsłużenia przetworników, zostały im przydzielone bloki pamięci RAM układu FPGA, oraz układy konfiguracji. Do uzyskania konwersji sygnałów, zostały wykorzystane układy konfiguracji (MAX9452) i dystrybucji (AD9512) zegara próbkującego. Dodatkowo, w celach rozszerzenia możliwości konfiguracyjnych sygnałów zegarowych, zaimplementowano programowalny dzielnik.

• Wykorzystanie interfejsu GPIB, znajdującego się na płycie DIC. Interfejs ten umożliwił komunikację z innymi urządzeniami, takimi jak dostępny w laboratorium oscyloskop TDS7404B firmy Tektronix. Pozwoliło to na przeniesienie zadania analizy sygnałów na TDS7404B, który ma możliwości analiz czasowej i widmowej.

• Wykorzystanie interfejsu RS232C oraz I2C, znajdujących się na płycie DIC. Interfejs ten umożliwił komunikację z licznymi urządzeniami nie wymagającymi dużych szybkości transferu, takimi jak przetworniki czy mikrokontrolery Wszystkie bloki sprzętowe, na poszczególnych płytach, zostały dołączone do dekodera adresowego. Liczba dostępnych adresów określona została przez sposób komunikacji Wishbone: wykorzystano 24-bitową szynę adresową. Ostateczne przydzielenie adresów odpowiednim blokom nastąpiło podczas realizacji systemu (patrz. roz. 4).

3.2. Warstwa programowa

Struktura aplikacji użytkownika prezentowana jest na rysunku 3.4.

 

Rysunek 3.4. Struktura programu powiązana z funkcjami

Aplikacja została podzielona na odpowiednie części. Fizycznie tymi częściami są odrębne pliki źródłowe. Każdy osobny plik zawiera funkcje, które dostępne są dla użytkownika w odrębnych zakładkach po uruchomieniu aplikacji. Zakładki zostały dobrane tak by logicznie dzieliły funkcjonalności systemu. Dzięki takiemu podejściu uzyskano strukturę modularną aplikacji ułatwiającą jej tworzenie i testowanie.
Utworzono następujący podział funkcjonalności:

Zakładka 1
Użytkownik konfiguruje port szeregowy do transmisji pomiędzy PC a UMC. Dodatkowo została przewidziana implementacja funkcji debugingu, ułatwiająca opracowywanie modułów sprzętowych.

Zakładka 2
Użytkownik konfiguruje układ MAX9452 oraz pierwszy zegar podchodzący z układu FPGA. Ustawienia te mają wpływ na wartości częstotliwości ustawianych w zakładce trzeciej, czwartej oraz piątej. Niezbędne parametry przekazywane są do tych zakładek poprzez zmienne globalne i strukturę przechowującą bieżące ustawienia systemowe.

Zakładka 3
Użytkownik konfiguruje układ AD9512 oraz drugi zegar pochodzący z układu FPGA. Ustawienia te mają wpływ na częstotliwość próbkowania przy generacji oraz akwizycji sygnałów. Niezbędne parametry przekazywane są do zakładki czwartej i piątej poprzez zmienne globalne i strukturę przechowującą bieżące ustawienia systemowe.

Zakładka 4
Użytkownik konfiguruje i steruje układem AD9777. Przewidziano możliwość wstępnej (mniej dokładnej) analizy generowanego sygnału dzięki jego graficznej interpretacji w oknie podglądu sygnału. Graficzna interpretacja sygnału przechowywana jest w tablicy, której wartości odpowiadają odpowiednim koordynatom (w pikselach) na ekranie.

Zakładka 5
Użytkownik konfiguruje i steruje układami LTC2207. Przewidziano możliwość wstępnej (mniej dokładnej) analizy spróbkowanego sygnału dzięki jego graficznej interpretacji w oknie podglądu sygnału. Graficzna interpretacja sygnału przechowywana jest w tablicy, której wartości odpowiadają odpowiednim koordynatom (w pikselach) na ekranie. Dodatkowo zakładka ta korzysta z tablicy, w której zapisywane są wartości spróbkowanego sygnału. Wartości te mogą następnie zostać zapisane do pliku, co daje przenośność wykonanego pomiaru na inne oprogramowanie w celach ewentualnej dalszej analizy lub dokładniejszego podglądu.

Zakładka 6
Użytkownik steruje interfejsem GPIB pisząc odpowiedni kod sterujący napisany w zaimplementowanym języku skryptowym, dając przez to możliwość tworzenia procedur pomiarowych. Dodatkowo przewidziano możliwość podglądu odebranych danych z urządzeń docelowych.

Zakładka 7
Użytkownik steruje interfejsem I2C pisząc odpowiedni kod sterujący. Dodatkowo, przy odczytach z urządzeń, w oknie podglądu widoczne są zwracane wartości.

Zakładka 8
Użytkownik steruje interfejsem RS232C. Przewidziano dwa tryby przesyłania danych: tekstowy oraz binarny. W trybie tekstowym wpisywana jest odpowiednia treść, a w trybie binarnym wpisywana są wartości heksadecymalne każdego bajtu. Tryb przesyłania danych jednocześnie ustala tryb odbierania danych. Opis działania programu przedstawiono krokowo poniżej:

1. Program rozpoczyna się w funkcjimain(), skąd przechodzi do załadowania biblioteki "Common Controls" [38], a następnie do tworzenia okien (zakładek i kontrolek)

2. Po stworzeniu okien program przechodzi do głównej pętli dekodowania komunikatów, czekając na reakcję użytkownika. Stąd skok zachodzi do jednej z ośmiu zakładek.

3. Po zareagowaniu na reakcję użytkownika (wykonaniu wskazanej przez użytkownika funkcji) dochodzi w większości przypadków do transmisji pomiędzy UMC a PC poprzez port szeregowy. Sposób transmisji oraz programowej metody wymuszania poprawności transmisji został opisany również w oddzielnym zbiorze plików. Typowo po zakończeniu transmisji program przechodzi z powrotem do głównej pętli dekodowania komunikatów.

---------------------

 

5. Samer Bou Habib, Ryszard Romaniuk. Opracowanie Mostu PCI dla Węzła Modularnego Systemu Fotonicznego. Politechnika Warszawska, 2008.

37. WISHBONE System-on-chip (SoC) Interconnection Architechture for Portable IP Cores Revision B.3, Septmeber 2002.

38. Microsoft. About Common Controls. http://msdn.microsoft.com/en-us/library/bb775493(VS.85,loband).aspx, 2009.

4. Realizacja modułów sprzętowych

4. Realizacja modułów sprzętowych

Do poprawnej komunikacji w systemie została zadeklarowana przestrzeń adresowa dla każdej z płyt. Ze względów opisanych w rozdziale 7.4.1, a dotyczących błędnie działających połączeń elektrycznych, wykorzystano jedynie 16 (z 24) linii adresowych magistrali Wishbone. Przestrzeń adresowa dla każdej z płyt została rozdzielona na następujące moduły sprzętowe:

• DAC: od 0x0000h do 0x7FFFh;
  - ADC1_RAM : 0x0000h do 0x1003h,
  - ADC2_RAM: 0x2000h do 0x3003h,

  - DAC_RAM: 0x4000h do 0x6FFFh,
  - SPI : 0x7000h do 0x7003h,
  - CLK_DIV : 0x7004 do 0x7007h,
  - DAC_ID_REG : 0x7008h,
  - CLK_DISTRIBUTION_REG : 0x7009h.

• DIC: od 0x8000h do 0x8FFFh;
  - GPIB_CORE : 0x8000h do 0x8001h,
  - WS_UART : 0x8010h do 0x801Fh,
  - I2C_MASTER_TOP : 0x8020h do 0x8027h,
  - LEDSS : 0x8060h,
  - DIC_ID_REG : 0x8061h.

 

4.1. Zestaw modułów po stronie UMC

Zestaw modułów składa się z 2 części:

• kontrolera,

• "przekładni" (HOST_PCI_PLUG) wraz z buforami wej/wyj.

Zestaw został opracowany w dwóch wersjach. Wersja pierwsza wykorzystuje kontroler interfejsu RS232, a wersja druga interfejs USB znajdujące się na płycie UMC. Obie wersje przedstawiono na rysunkach 4.1 i 4.2.

 

Rysunek 4.1. Zestaw modułów po stronie UMC wraz z kontrolerem RS

 

4.1.1. Kontroler systemowy RS

Jako kontroler systemowy, obsługujący interfejs RS232 na płycie UMC, wykorzystano "RS232 system controller" (rs_syscon [39]). Jego działanie opiera się na dekodowaniu trzech instrukcji wysłanych od strony komputera i wykonywaniu ich na magistrali Wishbone:

• • Zapis: "w aaaaaa dddddddd xx\r"1
  zapis od adresu 24-bitowego aaaaaa, 32-bitowych danych dddddddd, w liczbie xx, zwiększając adres o jeden przy każdym zapisie. Pole liczby odczytów jest opcjonalne i może zostać pominięte wraz z wcześniej występującą spacją, co skutkuje wykonaniem pojedynczego zapisu.
  Każda z liter ‘a’, ‘d’ i ‘x’ oznacza cyfrę zapisaną heksadecymalnie 0..F, a znak \r oznacza znak powrotu karety,

• Odczyt: "r aaaaaa xx\r" – odczyt danych od adresu 24-bitowego aaaaaa, w liczbie xx słów 32-bitowych, zwiększając adres o jeden przy każdym odczycie. Pole liczby odczytów jest opcjonalne i może zostać pominięte wraz z wcześniej występującą spacją, co skutkuje wykonaniem pojedynczego odczytu,

• Reset: "i\r" – moduł resetuje urządzenia podłączone podłączone do magistrali Wishbone.

Użyta konfiguracja modułu rs_syscon oraz wartości wraz z krótkim opisem parametrów przedstawiono w tabeli 4.1.

 

Tabela 4.1. Konfiguracja rs_syscon

 

Została wykorzystana możliwość zwracania "echa". Każda komenda uzyskuje potwierdzenie zwrotne w formie swojej kopii, co umożliwiło wyeliminowanie błędów w transmisji poleceń. Błędnie potwierdzona komenda jest wysyłana ponownie w celu uzyskania jej prawidłowego wykonania i potwierdzenia. Przyczynami błędów w transmisji mogą być m.in.:

• niedokładnie zsynchronizowane zegary wytwarzające tzw. "baudrate",

• chwilowe zakłócenie transmisji na złączu RS232,

• niepoprawne podłączenie do złącza.

 

4.1.2. Kontroler systemowy USB

 

Opracowano moduł "virtual_com_usb_syscon" (VCusb) jako kontroler systemowy obsługujący interfejs USB na płycie UMC . Jego działanie opiera się na dekodowaniu trzech instrukcji wysłanych od strony komputera i ich wykonywaniu na magistrali Wishbone. Składnia instrukcji jest podobna do składni dla kontrolera "rs_syscon" (patrz. roz. 4.1.1) z tą różnicą, że nie są dostępne pola liczby odczytów/zapisów. Moduł VCusb składa się z dwóch automatów przedstawionych blokowo na rysunku 4.3.

 

Kontroler steruje układem FT245BM [40], który pełni następujące funkcje na płycie UMC:

• działa analogicznie do układu UART, zamieniając szeregową transmisję na pojedyncze bajty, umieszczane w kolejce fifo,

• układ "widziany" jest jako wirtualny port szeregowy COM, co znacznie upraszcza obsługę portu USB od strony programisty.

 

Rysunek 4.3. Schemat blokowy kontrolera USB

 

Zadania automatu "usb_to_wsh" obejmują obsługę linii układu FT245BM oraz dekodowanie instrukcji (wysłanych od strony PC). Po zdekodowaniu instrukcji, sterowanie zostaje przekazanie automatowi "wsh_to_usb", którego zadaniem jest wykonanie zdekodowanej instrukcji na magistrali Wishbone. Po wykonaniu instrukcji sterowanie jest przekazane z powrotem do "usb_to_wsh". Konfiguracja modułu VCusb, użyte wartości i którki opis paramterów, zostały przedstawione w tabeli 4.2.

 

Tabela 4.2. Konfiguracja VCusb

 

 

Algorytm działania automatu "usb_to_wsh" zaprezentowano na rysunku 4.4.

 

Rysunek 4.4. Algorytm działania

 

Z uwagi na zachowanie przejrzystości grafu stanów i warunków przejść, rysunek opisuje pogrupowane stany automatu; np. grupa stanów "read_cmd" składa się z kilku stanów: "read_cmd_state_0", "read_cmd_state_1" itd, a grupa stanów "read_adress" składa się z: "read_adress_state_0", "read_adress_state_1" itd. Stany automatu pogrupowano według pełnionej funkcji:

read_cmd odpowiada za oczekiwanie na poprawna komendę w kodzie ASCII: "w", "r" oraz "i". Litery oznaczają odpowiednio zapis na magistrali Wishbone, odczyt na magistrali Wishbone, wykonanie resetu na magistrali Wishbone. Jeżeli znak nie jest poprawny, to następuje przejście do grupy stanów "command_failure". Poszczególne stany grupy odpowiadają za odpowiednie obsłużenie linii RXF oraz RD (odczyt). Wymagane stany na liniach RD oraz RXF wraz z rygorami czasowymi zostały przedstawione w dokumentacji układu FT245BM,

read_cmd_space odpowiada za odczyt znaku spacji. Jeżeli odczytany znak jest inny, to następuje przejście do grupy stanów "commad_failure". Poszczególne stany grupy odpowiadają za obsłużenie linii RXF oraz RDz,

read_addres odpowiada za odczyt pól adresowych. Jeżeli odczytany znak jest inny niż cyfra heksadecymalna w kodzie ASCII, znak spacji (w przypadku dekodowania komendy zapisu) albo znak powrotu karetki (w przypadku dekodowania komendy odczytu), to następuje przejście do grupy stanów "command_failure". Jeżeli została odczytana maksymalna liczba wymaganych pól adresowych, to przejście automatu zależy od dekodowanej komendy – odczytywanie znaku spacji dla komendy zapisu, odczytywanie znaku powrotu karetki dla komendy odczytu. Kolejne odczytywane pola adresowe są dekodowane z kodu ASCII na liczby binarne za pomocą układu kombinacyjnego i wpisywane (pół-bajtami) do rejestru przesuwnego od strony młodszych bitów.
Poszczególne stany grupy odpowiadają za obsłużenie linii RXF oraz RD,

read_adress_space odpowiada za odczyt znaku spacji. Jeżeli odczytany znak jest inny, to następuje przejście do grupy stanów "commad_failure". Poszczególne stany grupy odpowiadają za obsłużenie linii RXF oraz RD, read_data odpowiada za odczyt pól danych. Jeżeli odczytany znak jest inny niż cyfra heksadecymalna w kodzie ASCII albo znak powrotu karetki, to następuje przejście do grupy stanów "command_failure". Jeżeli została odczytana maksymalna liczba wymaganych pól danych, to następuje przeskok do odczytywania znaku powrotu karetki. Kolejne odczytywane pola danych są dekodowane z kodu ASCII na liczby binarne za pomocą układu kombinacyjnego i wpisywane (pół-bajtami) do rejestru przesuwnego od strony młodszych bitów.
Poszczególne stany grupy odpowiadają za obsłużenie linii RXF oraz RD,

read_return_carret odpowiada za odczyt znaku powrotu karetki. Jeżeli odczytany znak jest inny, to następuje przejście do grupy stanów "commad_failure". Poszczególne stany grupy odpowiadają za obsłużenie linii RXF oraz RD,

start_wishbone odpowiada za przekazanie sterowania automatowi "wsh_to_usb" i oczekiwanie na potwierdzenie zakończenia operacji przez automat "wsh_to_usb" na magistrali Wishbone. Jeżeli operacja nie zakończy się w maksymalnym czasie oczekiwania, to operacja ta zostaje anulowana i następuje przejście do grupy stanów "wsh_busy".
Poszczególne stany grupy "start_wishbone" nie odpowiadają za obsługę układu FT245BM, a za obsługę wewnętrznych sygnałów modułu VCusb (takich jak rdy oraz rec),

wsh_busy odpowiada za wysłanie znaku "!" w kodzie ASCII do PC, informując użytkownika, iż wykonywana instrukcja nie została potwierdzona po stronie Wishbone (linia ack_i nigdy nie została ustawiona w stan aktywny).
Poszczególne stany grupy odpowiadają za obsłużenie linii TXE oraz WR. Wymagane stany na liniach WR oraz TXE, wraz z wymaganiami czasowymi zostały przedstawione w dokumentacji układu FT245BM,

wsh_ack odpowiada za wysłanie znaku "@" w kodzie ASCII do PC, informując użytkownika, iż wykonywana instrukcja została potwierdzona po stronie Wishbone (linia ack_i została ustawiona w stan aktywny przez co najmniej jeden cykl zegarowy).
Poszczególne stany grupy odpowiadają za obsłużenie linii TXE oraz WR,

recive odpowiada za wysyłanie danych do PC, w przypadku gdy została zdekodowana komenda odczytu ("r"). Dane odczytane z magistrali Wisbone są konwertowane z postaci binarnej do heksadecymalnej w kodzie ASCII, a następnie wysyłane. Poszczególne stany grupy odpowiadają za obsłużenie linii TXE oraz WR,

command_failure odpowiada za wysłanie znaku "fi" w kodzie ASCII do PC, informując użytkownika, iż instrukcja nie została poprawnie przez niego wpisana. Po wysłaniu znaku "fi" następuje przejście do grupy stanów "read_cmd" i ponowne oczekiwanie na dalsze komendy.
Poszczególne stany grupy odpowiadają za obsłużenie linii TXE oraz WR.

 

4.1.3. Host_PCI_plug oraz bufory wej/wyj

 

Z powodu problemów sprzętowych zaistniała potrzeba opracowania "przekładni" sygnałów opisanych w specyfikacjiWishbone na sygnały połączeń PMC wykorzystywane w systemie. Wynikało to z faktu, iż nie wszystkie linie sygnałowe (w miejscu połączenia PMC) działały prawidłowo. "Przekładnia" sygnałów została zamieszczona w tabeli 4.3.

 

Tabela 4.3. Przekładnia sygnałów

 

W układzie "HOST_PCI_PLUG" wykorzystano 23 (z 24) linii adresowych. Karty DAC i DIC wykorzystują jedynie pierwsze 16 spośród nich, a pozostałe są programowo ustawiane na logiczne zera.

 

Drugą funkcją modułu "Host_PCI_plug" jest ustawianie na odpowiednich liniach stanu wysokiej impedancji (ukl. wej/weyj typu otwarty dren). Liniami tymi są dwukierunkowe linie PCI_AD[31..] oraz linia PCI_CBE3. Liniami PCI_AD[31..0] przesyłane są dane, a linią PCI_CBE3 propaguje się sygnał "we" (a ang. write enable).

 

4.2. Zestaw modułów po stronie DAC

 

Zestaw modułów po stronie DAC składa się z 9 części:

1. "Przekładni" (SLAVE_PCI_PLUG) wraz z buforami wej/wyj, do której dołączony jest dodatkowy dekoder adresu (ze względu na złożony sposób działania dekodera Wishbone-Interconnect z biblioteki Altium Designer),

2. Dekodera adresów Wishbone-Interconnect [41],

3. ADC1_RAM, sterującego pierwszym przetwornikiem A/C oraz obsługującym przypisaną pamięć temu przetwornikowi,

4. ADC2_RAM, sterującego drugim przetwornikiem A/C oraz obsługującym przypisaną pamięć temu przetwornikowi,

5. DAC_RAM, sterującego dwoma przetwornikami C/A oraz obsługującym przypisaną im pamięć,

6. SPI, kontrolującego interfejs SPI, dzięki któremu konfigurowane są układy dystrybucji zegarów i przetworniki C/A,

7. CLK_DIV, wstępnie dzielący zegar, który wchodzi na układy dystrybucji zegarów,

8. DAC_ID_REG, rejestr tylko-do-odczytu zawierającego kod identyfikacji 0x00444143h (3 młodsze bajty posiadają interpretację w kodzie ASCII: "DAC"),

9. CLK_DISTR_REG, rejestr sterującego równoległymi liniami interfejsu układów konfiguracji i dystrybucji zegarów (układów MAX9452 i AD9512).

Pełny zestaw zaprezentowano na rysunku 4.5.

 

Rysunek 4.5. Zestaw modułów po stronie DAC

 

4.2.1. Slave_PCI_plug oraz bufory wej/wyj

 

Implementacja przekładni Host_PCI_plug po stronie UMC wymagała opracowania przekładni po stronie płyty DAC. Przekładnia Slave_PCI_plug pełni dwie funkcje:

• "przekłada" sygnały w odwrotną stronę, niż w tabeli 4.3, od strony złącz PMC na sygnały wymagane do komunikacji Wishbone na płycie DAC,

• steruje buforami wej/wyj od stron płyty DAC.

Po stronie płyty DAC wykorzystano 16 bitów szyny adresowej. Pozostałe linie zadeklarowano jako porty wejściowe w celu wymuszenia stanów wysokiej impedancji na odpowiadających im liniach.

 

Moduł Slave_PCI_plug, podobnie jak Host_PCI_plug na płycie UMC, ustawia odpowiednio stany wysokiej impedancji na liniach dwukierunkowych PCI_AD[31..0]. Dodatkowo stan wysokiej impedancji jest ustawiany na linii PCI_CBE2. Do tej linii, zgodnie z tab. 4.3, jest podpięty sygnał "ack_i", a dla płyty DAC jest to "ack_o" (z ang. acknowledge output). Sygnał "ack_o" jest sygnałem zwrotnym potwierdzenia i wychodzi on z dwóch płyt DAC i DIC. Stąd, w celu uniknięcia kolizji, na linii PCI_CBE2 wymagana jest obsługa bufora 3-stanowego (realizowana w układzie FPGA jako bufor z otwartym drenem). Buforem steruje dodatkowy dekoder adresowy,który zapewnia, że jeśli następuje odwołanie do płyty DIC, to wyjście na linię PCI_CBE2 od strony płyty DAC przechodzi w stan wysokiej impedancji.

 

4.2.2. Kontrolery pamięci i przetworników A/C

 

Kontrolery pamięci i przetworników A/C (ADC1_RAM i ADC2_RAM) zostały zaadoptowane z [10]. Dodano możliwość wyzwalania (z ang. trigger) akwizycji warunkami logicznymi nałożonymi na próbkowany sygnał. Oba kontrolery zostały wykonane podobnie. Niewielkie różnice opisano dalej w tekście. Moduł ADC1_RAM zaprezentowano na rysunku 4.6.

 

Rysunek 4.6. Kontroler pamięci i pierwszego przetwornika A/C – ADC1_RAM

 

Kontroler składa się z 2 głównych części.

• Pamięci, widzianej od adresu 0x0000h do 0x0FFFh, zorganizowanej w 4096 16-bitowych słów. Do obsługi pamięci zostały użyte gotowe moduły "WB_MEM_CTRL" [42] oraz "RAMDEB" [43] z biblioteki Altium Designer. Pożądaną cechą modułu "RAMDEB" jest dualny dostęp (z ang. Dual-port), co umożliwia łatwe dołączenie jednocześnie od strony kontrolera systemowego i od strony samego przetwornika,

• Czterech 32-bitowych rejestrów konfiguracji i sterowania układem wyzwalania widzianych od adresu 0x1000h do 0x1003h (0x3000h do 0x3003h dla ADC2_RAM).

Działanie poszczególnych bitów zostało zestawione w tabelach od 4.4 do 4.6 i krótko opisane.

 

Tabela 4.4. Rejestr 0x1000h (0x3000h dla ADC2_RAM)

 

Bit 15 informuje, czy przetwornik podczas konwersji nie uległ przepełnieniu lub niedopełnieniu. Wynik przepełniony i niedopełniony ulega nasyceniu do wartości granicznych w kodzie U2,

Bit 14 informuje, czy układ wyzwalania zakończył operację zbierania wyników. Zbieranie wyników polega na inkrementacji adresu o jeden, wraz z kolejnym cyklem zegarowym ,aż do momentu przepełnienia pamięci. Pod adres ten następuje zapis zebranej przez przetwornik danej. Inkrementacja adresu zaczyna się od momentu spełnienia warunku logicznego, ustawianego przy pomocy bitów 19..16 rejestru spod adresu 0x1002h (0x3002h dla ADC2_RAM). Warunkami logicznymi są porównywania typu >=, >, =, < i <= między wartością chwilową a wartością ustawioną przy pomocy bitów 15..0 rejestru spod adresu 0x1002h
(0x3002h dla ADC2_RAM),

Bity 11..0 (10..0 dla ADC2_RAM) informują jaka jest obecna wartość licznika adresu,

Bit 5 ustawia wew. wzmocnienie przetwornika na 1 albo 1.5. Ustawienie wzmocnienia na 1.5 zmniejsza wartość maksymalnego napięcia wejściowego, przy którym konwerter jeszcze nie nasyca wyników, do 1.5Vp-p,

Bit 4 ustawia wew. randomizację wyników wg. algorytmu Dn := xor(Dn,D0), gdzie n jest numerem bitu z przedziału 15 do 1,

Bit 3 ustawia wew. dither przetwornika,

Bit 2 włącza/wyłącza obwody analogowe przetwornika (odpowiadające za konwersję) oraz włącza/wyłącza cyfrowy interfejs równoległy wprowadzając jego linie w stan wysokiej impedancji,

Bit 1 resetuje licznik adresu,

Bit 0 włącza/wyłącza (sygnał start/stop) układ wyzwalania. Układ wyzwalania jest automatycznie wyłączany w przypadku przepełnienia licznika adresu, powodując iż pojedyncze wyzwolenie akwizycji zbiera 4096 próbek 16-bitowych (2048 dla ADC2_RAM).

 

Tabela 4.5. Rejestr 0x1002h (0x3002h dla ADC2_RAM)

 

Bit 19 potwierdza zakończenie pracy układu wyzwalania. Zakończenie pracy sygnalizowane jest przez bit 14 rejestru spod adresu 0x1000h (0x3000h dla 36ADC2_RAM). Po zakończeniu pracy układu wyzwalania należy pod bit 19 zapisać jedynkę logiczną, a następnie zero logiczne (gdyż bez tego nie będzie możliwe ponowne uruchomienie układu wyzwalania),

Bity 18..16 ustawiają warunek logiczny jaki jest wykorzystywany przy porównywaniu wartości wyzwalania (ww) z chwilową wartością (cw) akwizycji. Wartości od 0x0h do 0x5h kolejno ustawiają warunek: cw >= ww, cw > ww, cw = ww, cw < ww, cw <=. Wartość 0x6h ustala brak warunku, powodujący natychmiastowe uruchomienie licznika adresu w przypadku uruchomienia układu wyzwalania,

Bity 15..0 ustawiają wartość wyzwalania.

 

Tabela 4.6. Rejestr 0x1003h (0x3003h dla ADC2_RAM)

 

Bity 15..0 informują o chwilowej wartości akwizycji, która jest zapamiętywana do rejestru w momencie odczytu tych bitów.

Wszystkie bity w omawianych powyżej rejestrach ustawiane są na zero logiczne wraz z resetemi wraz ze startemsystemu (wgrania strumienia konfiguracyjnego do układu FPGA).

Kontroler drugiego przetwornika oraz jego pamięci (ADC2_RAM) wykonany został podobnie z tą różnicą, iż zostało mu przypisane, ze względu na ograniczoną pamięć układu FPGA, 2k słów 16-bitowych.

 

4.2.3. Kontrolery pamięci i przetworników C/A

 

Kontroler pamięci i przetworników C/A (DAC_RAM) został zaadoptowany z [10]. W zaadoptowanym rozwiązaniu zostały:

• dodane możliwości resetowania (sprzętowego) przetworników, bez konieczności resetowania całego systemu,

• dodane możliwości resetowania liczników adresu obu przetworników; obu naraz, wymaganego jeśli należy zsynchronizować sygnały w obu kanałach, oraz każdego z osobna.

Moduł DAC_RAM prezentowany jest na rysunku 4.7.

 

Rysunek 4.7. Kontrolery pamięci i przetworników C/A - DAC_RAM

 

Kontroler składa się z 3 głównych części:

• Pamięci pierwszego przetwornika, widzianej od adresu 0x4000h do 0x4FFFh, zorganizowanej w 4096 16-bitowych słów. Do obsługi pamięci zostały użyte gotowe moduły "WB_MEM_CTRL" oraz "RAM_DEB" z biblioteki Altium Designer,

• Pamięci drugiego przetwornika, widzianej od adresu 0x6000h do 0x6FFFh, zorganizowanej i kontrolowanej identycznie jak dla pierwszego przetwornika,

• 32-bitowych rejestrów konfiguracji i sterowania zarówno układem inkrementacji adresu jak i resetem (sprzętowym) przetworników. Rejestry te widziane są od adresu 0x5000h do 0x5003h. Działanie poszczególnych bitów zostało zestawione w tabelach od 4.7 do 4.8 i krótko opisane.

 

Tabela 4.7. Rejestr 0x5000h

 

Bit 15 jest bitem startu/stopu generacji sygnału na wyjściu przetwornika (pod warunkiem nie włączonego resetu). Generacja sygnału polega na inkrementacji licznika adresu w górę o jeden, wraz z każdym taktem zegara. Adres ten wskazuje na wartość w zadeklarowanej dla przetwornika pamięci. Licznik jest licznikiem modulo, gdzie modulo jest ustalane przez wartość górną licznika adresu,

Bit 14 jest bitem resetującym licznik adresu,

Bity 11..0 ustawiają wartość górną licznika adresu.

Rejestr pisany w tabeli 4.7 zawiera ustawienia dla pierwszego przetwornika. Rejestr spod adresu 0x5001h zawiera identyczne ustawienia dla drugiego przetwornika.

 

Tabela 4.8. Rejestr 0x5003h

 

Bit 1 jest bitem resetu obu liczników adresu. Funkcja taka jest wymagana jeśli należy zsynchronizować generowane sygnały,

Bit 0 jest bitem resetującym przetworniki sprzętowo. Reset sprzętowy resetuje również wew. rejestry konfiguracyjne przetworników.

Wszystkie bity w omawianych powyżej rejestrach ustawiane są na zero logiczne wraz z resetemi wraz ze startemsystemu (wgrania strumienia konfiguracyjnego do układu FPGA).

 

4.2.4. Kontroler SPI

 

Kontroler SPI został zaczerpnięty z [10] i przedstawiony na rysunku 4.8. Zawiera gotowy moduł kontrolera SPI "SPI_W" [44] z biblioteki Altium Designer.

 

Rysunek 4.8. Kontroler SPI

 

Do kontrolera SPI podłączono 3 układy scalone (MAX9452, AD9512 oraz AD9777). Wybór aktywnego urządzenia realizowany jest na podstawie sygnałów SPI_MODE i SPI_CS za pośrednictwem multipleksera zgodnie z tab. 4.9.

 

Tabela 4.9. Tablica prawdy multipleksera [10]

 

Transmisja danych polega na wykonaniu 5 kroków:

1. Wyzerowaniu rejestru CSR,

2. Wpisaniu 0xFFh do rejestru CDIV,

3. Wpisaniu do rejestru CSR:
   - 0x06h w celu komunikacji z AD9777,
   - 0x04h w celu komunikacji z AD9512,
   - 0x02h w celu komunikacji z MAX9452,

4. Wykonaniu jednej z dwóch możliwości:

   - W przypadku nadawania: na wpisaniu bajtu do rejestru DATAOUT - bajt ten zostanie wysłany,

   - W przypadku odbioru: na wysłaniu dowolnego bajtu, powodując wytworzenie sygnału taktującego urządzenie docelowe. Bajt ten zostanie zignorowany przez urządzenie docelowe. Jeżeli urządzenie docelowe było przygotowane na nadawanie, to odebrany bajt należy odczytać z rejestru DATAIN. Jeżeli wymagane jest zapisanie/odczytanie większej ilości bajtów, to krok 4 należy powtarzać

5. Wyzerowaniu rejestru CSR

 

4.2.5. Dzielnik Zegarów CLK_DIV

 

Blok dzielnika zegarów został zaczerpnięty z [10] i został przedstawiony na rysunku 4.9.

 

Rysunek 4.9. Schemat bloku CLK_DIV

 

Głównym elementem tego bloku są 32-bitowe rejestry konfiguracyjne widziane od adresu 0x7004h do 0x7007h. Wartości rejestrów spod adresów 0x7005h i 0x7007h konfigurują dzielniki kolejno zegara wejściowego do układu MAX9452 oraz zegara wejściowego układu AD9512. Dzielenie częstotliwości opisuje zależność:

4.2.6. Blok CLK_DISTR_REG

 

Blok CLK_DISTR_REG, prezentowany na rysunku 4.10, został zaczerpnięty z [10]. Blok odpowiada za sterowanie równoległym interfejsem układów dystrybucji zegara (układów MAX9452 i AD9512).

 

Rysunek 4.10. Blok CLK_DISTR_REG

 

Układ składa się z pojedynczego 32-bitowego rejestru widzianego pod adresem 0x7009h. Sterowanymi liniami, zgodnie z powyższym rysunkiem, są "FUNC" i "STAT" układu AD9512, oraz linie "CMON", "SEL0", "SEL1", "LOCK" i "INT" układu MAX9452. Znaczenia wartości logicznych na tych liniach zostały opisane w dokumentacji układów scalonych (MAX9452 w [33], AD9512 w [32]).

 

4.3. Zestaw modułów po stronie DIC

 

Zestaw modułów składa się z 7 części:

1. "Przekładni" (SLAVE_PCI_PLUG), identycznej jak w przypadku płyty DAC,

2. Dekodera adresów Wishbone-Interconnect,

3. Kontrolera GPIB, podłączonego do Wishbone-Interconnect poprzez moduł podłączający 32-bitową szynę danych do szyny 8-bitowej,

4. Kontrolera UART, podłączonego do Wishbone-Interconnect poprzez moduł podłączający 32-bitową szynę danych do szyny 8-bitowej,

5. Kontrolera I2C, podłączonego doWishbone-Interconnect poprzezmoduł podłączający 32-bitową szynę danych do szyny 8-bitowej,

6. Rejestru sterującego diodami na karcie DIC,

7. Rejestru tylko-do-odczytu DIC_ID_REG, zawierającego kod identyfikacji 0x00444943h (3 młodsze bajty posiadają interpretację w kodzie ASCII: "DAC").

Zestaw modułów zamieszczono na rysunku 4.11.

 

Rysunek 4.11. Zestaw modułów po stronie DIC

 

4.3.1. Kontroler GPIB

 

Kontroler GPIB został zaadoptowany z [11]. Zmodyfikowaną wersję zamieszczono na rysunku 4.12 w formie blokowej.

 

Rysunek 4.12. Schemat blokowy kontrolera GPIB [11]

 

Dokonano następujących modyfikacji:

1. Została dodana możliwość sprawdzania fiag "empty" oraz "full" kolejek fifo. Ich stan jest odczytywany spod adresu 0x8001h kontrolera według tabeli podanej poniżej:

 

Tabela 4.10. Odczyt stanów fiag kolejek fifo: 0x8001h

 

2. Została dodana możliwość ustalania adresu kontrolera, wymaganego w protokole GPIB, poprzez równoległe linie CONN_ADD[7..0]. Adres ustawiany jest przez 5 najmłodszych bitów (starsze 3 są ignorowane). Zakres adresu jaki można ustalić przewiduje sam protokół i mieści się on pomiędzy 0x00h, a 0x1Eh. Jeżeli zostanie podany adres 0x1Fh, to adresem kontrolera będzie jednocześnie instrukcja rozadresowania wszystkich urządzeń - do czego nie można dopuścić.

3. Została wprowadzona zmiana przejść oraz zredukowana liczba stanów (o jeden) automatu "state_machine_r" kontrolera:
   - zredukowano stan "NADRSD" (mnemonik z ang. od "Not adressed"),
   - zmieniono warunek przejścia ze stanu "IDLEr" do stanu "RDY2RCV" na:
   ATN_I_reg fi [(SPE_flag fi ADR2LST_flag) fi (!wbrfifo_full_i)]   .

Modyfikacje te spowodowały:

• poprawne (nie przypadkowe) działanie automatu w przypadku chęci odczytu stanu linii "SRQ" (komenda "TST_SRQ"),

• automat nie przechodzi do odbierania danych w przypadku, gdy kolejka odbioru jest zapełniona, co powoduje że dane nie są nadpisywane i może zostać odebrana duża (ponad rozmiar kolejki odbioru) ilość danych z urządzenia docelowego.

W celu używania tego modułu został on odpowiednio skonfigurowany. Parametry konfiguracyjne, użyte wartości oraz krótki opis ustawień znajdują się w tabeli 4.11 poniżej.

 

Tabela 4.11. Konfiguracja kontrolera GPIB

 

Kontroler steruje liniami interfejsu za pośrednictwem zapisu/odczytu bajtów pod/z adres/u 0x8000h:

• zapis/odczyt wartości z przedziału 0x00h : 0x7Fh kontroluje szynę DIO (odpowiednio zapis – nadawanie, odczyt – odbieranie),

• zapis 0x81 wprowadza stan linii IFC w aktywny, co resetuje również kolejki odbioru i zapisu,

• zapis 0x82 wprowadza stan linii ATN w aktywny (przesyłanie komend),

• zapis 0x83 wprowadza stan linii ATN w nieaktywny (przesyłanie danych),

• zapis 0x84 wprowadza stan linii EOI w aktywny,

• zapis 0x85 wywołuje sprawdzanie linii SRQ (wynik sprawdzenia jest umieszczany w kolejce odbioru w postaci 0xFFh, gdy SRQ jest aktywne, w przeciwnym wypadku 0x00h).

4.3.2. Kontroler RS232C

 

Do realizacji zadań interfejsu RS232 wykorzystano gotowy moduł "WB_UART" [45] z biblioteki Altium Designer.

 

Do transmisji zostały wykorzystane linie RxD i TxD, a nie wykorzystywana (w samej transmisji) linia RTS służy do sterowania multiplekserem. Zadaniem multipleksera jest, tylko w przypadku wysyłania danych, odłączenie linii TxD od portu TX1 na czas 8 wysyłanych pierwszych bajtów, które mają wartość przypadkową. Bajty te biorą się z faktu, iż przy początku transmisji kolejka fifo modułu "WB_UART" jest opróżniana.

 

W celu wykorzystania tego modułu należy go odpowiednio skonfigurować. Konfiguracja ta polega na dwóch czynnościach:
• zapisu odpowiednich liczb, zgodnie ze wzorem prezentowanym poniżej, do 3 rejestrów BRG, odpowiadających za generowanie baudrate:

 

 

Po konfiguracji moduł jest gotowy do nadawania i odbioru. Nadawanie polega na wpisaniu bajtu do rejestru SBUF, po ówczesnym sprawdzeniu fiagi "txfull", a odebranie bajtu na odczycie rejestru SBUF, po ówczesnym sprawdzeniu fiagi "rxempty". Flagi "txfull" oraz "rxempty" znajdują się w rejestrze STATUS.

 

4.3.3. Kontroler I2C

 

Do realizacji zadań interfejsu I2C użyto komponentu "I2C controller core" [46]. Kontroler ten został podłączony zgodnie z jego dokumentacją, z tą różnicą, iż na karcie DIC wyjścia tego kontrolera sterują odwracającymi buforami typu otwarty dren, stąd inwertery na jego wyjściach.

W celu wykorzystania modułu należy go odpowiednio skonfigurować. W tym celu należy najpierw wyzerować rejestr CTR, a następnie wprowadzić do rejestrów PRERlo i PRERhi wartości preskalera częstotliwości według podanego poniżej wzoru:

 

Obliczoną wartość należy zamienić na reprezentację szesnastkową i wprowadzić do rejestrów - starszy bajt do rejestru PRERhi, a młodszy do PRERlo. Następnie należy ustawić bit EN w rejestrze CTR. Działanie kontrolera prezentowane jest w postaci algorytmu blokowego na rysunku 4.13. Na rysunku wykorzystano oznaczenia wykorzystywane w dokumentacji tego modułu [46].

 

Rysunek 4.13. Algorytm blokowy kontrolera I2C

 

Wysyłanie danych polega na wpisaniu 7-bitowego adresu docelowego adresu,do rejestru TXR na pozycje 7 starszych bitów. Przy zapisie najmłodszy bit musi być wyzerowany. Następnie należy ustawić bity STA oraz WR w rejestrze komend, po czym należy sprawdzać fiagę TIP. Jeśli fiaga TIP przez długi czas jest ustawiona użytkownik musi zadecydować czy dalej czekać czy przerwać transmisję. Jeśli fiaga TIP jest zdjęta, to należy sprawdzić czy urządzenia docelowe potwierdziło odbiór. Jeśli zaistniał brak potwierdzenia adresu, to znaczy że urządzenie docelowe o takim adresie nie jest podłączone do magistrali I2C.

Kolejnym krokiem jest wpisanie pierwszego bajtu danych do rejestru TXR i ustawienie bitu WR. Po każdym wysłaniu sprawdzana jest fiaga TIP. Jeśli fiaga TIP jest przez długi czas ustawiona użytkownik musi podjąć decyzję czy czekać dłużej czy przerwać transmisję. Jeśli fiaga TIP jest zdjęta, to kontroler zakończył przesyłanie bajtu.

Następnie sprawdzane jest potwierdzenie odbioru. W tym przypadku brak potwierdzenie odbioru może oznaczać, że urządzenie docelowe odebrało ostatni bajt i samo kończy transmisję, ale bajt został przesłany poprawnie. Przed wysłaniem ostatniej danej należy ustawić bity STO oraz WR na, co kończy transmisję.

Sposób odczytywania danych jest podobny i wymaga wpisania 7 bitowego adresu na pozycje starsze pozycje rejestru TXR oraz ustawienia ’1’ na najmłodszym bicie.

Następnie ustawiane są bity STA i WR w rejestrze rozkazów. Podobnie jak w przypadku zapisu, należy sprawdzić potwierdzenie odbioru adresu. Jeśli odbiera się tylko jeden bajt, należy ustawić STO, RD oraz NACK (ACK=1) w rejestrze komend, w przeciwnym wypadku, bity STO oraz NACK należy ustalić przed ostatnim przesłaniem. Po każdym ustawieniu RD i sprawdzeniu fiagi TIP odebrany bajt jest dostępny w rejestrze RXR. Po ustawieniu RD i NACK przez kontroler urządzenie docelowe przesyła ostani bajt i zwalnia magistralę I2C.

 

4.3.4. Diody Led

 

Obsługę diod LED zaimplementowano w celach testowych. Ułatwiają one wykrywanie ewentualnych usterek przy uruchamianiu nowych modułów. Diody sterowane są przy pomocy rejestru 8-bitowego i mogą być używane jako prosty wskaźnik stanów logicznych.

 

------------------------

10. Łukasz Dymanowski. Projekt i wykonanie modułu akwizycji danych z wykorzystaniem standardu PMC. Politechnika Warszawska, 2007.

11. Kamil Lewandowski. Projekt i wykonanie karty PMC z interfejsami komunikacyjnymi. Politechnika Warszawska, 2007.

32. Analog Devices. AD9512 Datasheet. http://www.analog.com/UploadedFiles/Data_Sheets/AD9512.pdf, Czerwiec 2005.

33. Maxim. MAX9450-MAX9452 Datasheet. http://datasheets.maxim-ic.com/en/ds/MAX9450-MAX9452.pdf.

39. John Clayton. RS232 system controller. http://www.opencores.org/project,rs232_syscon, 2005.

40. FTDI Chip. FT245BM USB FIFO ( USB - Parallel ) I.C. http://www.ftdichip.com/Documents/DataSheets/DS_FT245BM.pdf.

41. Altium. CR0150 WB_INTERCON Configurable Wishbone Interconnect. http://www2.altium.com/files/AltiumDesigner6/LearningGuides/CR0150%20WB_INTERCON%20Configurable%20Wishbone%20Interconnect.pdf.

42. Altium. CR0152 WB_MEM_CTRL Configurable Wishbone Memory Controller. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0152%20WB_MEM_CTRL%20Configurable%20Wishbone%20Memory%20Controller.pdf.

43. Altium. CR0118 FPGA Generic Library Guide. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0118%20FPGA%20Generic%20Library%20Guide.pdf.

44. Altium. CR0153 SPI_W Serial Peripheral Interface Controller. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0153%20SPI_W%20Serial%20Peripheral%20Interface%20Controller.pdf.

45. Altium. CR0157 WB_UART8 Serial Communications Port. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0157%20WB_UART8%20Serial%20Communications%20Port.pdf.

46. Richard Herveille. I2C-Master Core Specification. http://www.opencores.org/project,i2c, Lipiec 2003.

5. Realizacja aplikacja użytkownika

5. Realizacja aplikacja użytkownika

 

Aplikacja użytkownika została wykonana przy użyciu bibliotek WinApi [47] w środowisko programistycznym Code::Blocks 8.02 [48]. Aplikacja od strony użytkownika 48jest widoczna jako zbiór zakładek, w których zostały umieszczone poszczególne funkcjonalności systemu (por. roz. 3.2).

 

5.1. Konfiguracja portów

 

Pierwszą widoczną po uruchomieniu programu zakładką jest zakładka konfiguracji połączenia z płytą UMC. Zakładka prezentowana jest na rysunku 5.1.

 

Rysunek 5.1. Konfiguracja portów

 

Zakładka ta wzorowana jest na popularnym programie do obsługi portów szeregowych "HyperTerminal". W oknie użytkownik ma możliwość otwarcia odpowiedniego portu COM i skonfigurowania go do transmisji ustawiając odpowiedni baudrate, bity stopu, bity danych oraz bity parzystości.

W celu wysłania tekstu należy wpisać go w pole "Transmit" i wcisnąć przycisk "Send". Historia wysyłania pojawia się w oknie poniżej. W celu odbioru danych należy wcisnąć przycisk "Start listening", wówczas odbierane dane pojawiają się w polu "Recive".

Po wciśnięciu "Start listening" użytkownik niemoże przejść do innych zakładek jeżeli nie zakończy nasłuchiwania portu tj. nie wciśnie "Stop listening".
Użytkownik może dodatkowo zmienić tryb wyświetlania odbieranych danych, dzięki zaznaczeniu "Hex" albo "String", wybierając kolejno pomiędzy reprezentacją heksadecymalną, a ASCII.

Zakładka ta spełnia dodatkowo funkcje debugingu dając jednocześnie możliwość ręcznej konfiguracji dowolnych rejestrów układów MAX9452, AD9512 i AD9777 w sposób dowolny.

Po prawidłowym skonfigurowaniu portów i wciśnięciu "Connect" odpytywane są płyty UMC, DAC i DIC w celu ustalenia ich obecności w systemie. Jeżeli płyta DAC lub DIC nie jest widoczna w systemie, to użytkownik jest o tym informowany w polu "Recive", a zakładki spełniające funkcję odpowiedniej płyty stają się niedostępne.

 

5.1.1. Konfiguracja zegarów oraz układów dystrybucji sygnału zegarowego

 

W skład konfiguracji zegarów oraz układów dystrybucji sygnału zegarowego wchodzą dwie zakładki, za których pomocą konfigurowane są układy MAX9452 i AD9512. Zakładki te prezentowane są na rysunkach 5.2 i 5.3.

 

Zakładka MAX9452 ’n CLK1

 

Rysunek 5.2. Konfiguracja układu MAX9452.

 

W widocznych grupach ustawień użytkownik ma możliwość skonfigurowania dwóch zegarów: wewnętrznego "Internal CLK1", oraz opcjonalnego zewnętrznego"Ref. frequency Hz".
Zegar wewnętrzny jest zegarem wychodzącym z układu FPGA do układu MAX9452, a zegar zewnętrzny może zostać podłączony do wejścia CON8 na płycie DAC.
W dalszej pracy został wykorzystany zegar wewnętrzny.

W grupach ustawień "Frequency Outputs" widoczne są bieżące ustawienia częstotliwości zegarów CLK0 oraz CLK1. Zegar CLK0 wchodzi do układu FPGA i może zostać wykorzystany do dowolnych celów. Zegar CLK1 wchodzi do układu AD9512, gdzie może następnie zostać wybrany jako zegar który będzie wprowadzony na układy przetworników.

W grupie ustawień MAX9452 użytkownik konfiguruje wewnętrzne rejestry układu. Ustawienia te zostały opisane bardziej szczegółowo w Dodatku B.

Wysłanie konfiguracji, sprawdzenie stanu zamknięcia pętli PLL i stanów wejść układu odbywa się poprzez wciśniecie przycisku "Apply". Użytkownik jest odpowiednio informowaniu o stanie PLL, jeśli zaświeci się kontrolka "PLL Locked", oraz jeśli wystąpił błąd na wejściach do układu, to zaświeci się kontrolka "Input Error".

Zakładka AD9512 ’n CLK2

 

Rysunek 5.3. Konfiguracja układu AD9512

 

W widocznych grupach ustawień użytkownik ma możliwość skonfigurowania drugiego zegara wewnętrznego (pochodzącego z układu FPGA), który może zostać wybrany jako sygnał transmitowany dalej na układy przetworników.

Kolejnymi ustawieniami są ustawienia układu AD9512, które zostały opisane szerzej w Dodatku C. Głównym zadaniem odpowiedniego skonfigurowania układu AD9512 jest ustawienie częstotliwości dla przetworników C/A (DAC) oraz przetworników A/C (ADC1 oraz ADC2), przez ustawianie odpowiednich dzielników częstotliwości.
Dodatkowo zostały zaimplementowane ustawienia wykorzystujące inne możliwości układu AD9512 jak:

• wprowadzanie przesunięć w fazie dla sygnałów wyjściowych,

• wprowadzanie opóźnień dla sygnału wyjściowego, wchodzącego na przetwornik ADC2,

• dołączanie/odłącznie różnych sekcji, co pozwala na ograniczanie pobieranego prądu,

• ustawianie napięć/wydajności prądowych wyjść układu AD9512,

• możliwość wyboru standardu napięć (CMOS, LVDS) sygnałów zegarowych przetworników ADC1 i ADC2.

Funkcje te zostały zaimplementowane dla użytkowników, którzy są zainteresowani wpływem powyżej opisanych parametrów na jakość przetwarzania.
Dla typowego użytkownika interesującą opcją może okazać się odłączanie nie wykorzystywanych sekcji układu AD9512 w celu ograniczania pobieranej mocy.

 

5.2. Konfiguracja i sterowanie przetwornikami C/A

 

Użytkownik konfiguruje i steruje przetwornikami C/A za pośrednictwem zakładki prezentowanej na rysunku 5.4.

 

Rysunek 5.4. Konfiguracja i sterowanie przetwornikami C/A (układem AD9777)

 

W widocznych grupach ustawień użytkownik ma możliwość skonfigurowania układu AD9777 oraz wygenerowania przebiegu sygnału napięciowego, którego podgląd również widoczny jest w oknie. Szerszy opis poszczególnych ustawień został zaprezentowany w dodatku D.

W oknie widoczne są bieżące ustawienia poziomu napięcia na podziałkę oraz odstępu czasu na podziałkę/próbkę, ułatwiające podgląd sygnału oraz analizę zgodności sygnału wytworzonego i mierzonego.
Główną funkcjonalnością zakładki jest wygenerowanie sygnału, które może odbyć się na dwa sposoby:

• wyrysowanie pożądanego sygnału w oknie podglądu,

• wgranie sygnału określonego numerycznie z pliku o odpowiednim formacie.

Następnie należy skonfigurować wzmocnienia oraz liczniki adresu i je uruchomić. Dodatkowo została zaimplementowana obsługa innych możliwości układu AD977 takich jak:

• możliwość wprowadzenia układu w stan niskiego pobierania mocy, poprzez odłączenie wyjść

• obsługa wewnętrznej pętli PLL,

• obsługa filtrów; interpolacja, modulacja,

• możliwość zsynchronizowania wytwarzanych przebiegów.

Funkcje zostały zaimplementowane dla użytkowników obytych z przetwarzaniem
sygnałów. Dla typowego użytkownika interesującą opcją może okazać się wprowadzanie układu AD9777 w stan niskiego pobierania mocy, gdy wytwarzanie sygnałów napięciowych nie leży w jego zainteresowaniu.

 

5.3. Konfiguracja i sterowanie przetwornikami A/C

 

Rysunek 5.5. Konfiguracja i sterowanie przetwornikami A/C (układami LTC2207)

 

Użytkownik konfiguruje i steruje przetwornikami A/C za pośrednictwem zakładki prezentowanej na rysunku 5.4. W widocznych grupach ustawień użytkownik ma możliwość skonfigurowania:

Poszczególnych kanałów (układów LTC2207)

• włączenie trybu wewnętrznego ditheru,

• włączenie trybu randomizacji wynikowych próbek,

• włączenie sprzętowego resetu, który jednocześnie odłącza wejścia układu, co w efekcie ogranicza pobieraną moc,

• wybranie wewnętrznego wzmocnienia.

Poszczególnych układów wyzwalania

• określenie warunku (logicznego) uruchomienia akwizycji,

• określenie wartości napięcia porównywanego z chwilowym wynikiem akwizycji.

Wykonanie akwizycji polega na wybraniu odpowiedniego bufora (programowego) do którego dane zostaną zapisane, następnie skonfigurowaniu lub wyłączeniu układu wyzwalania i ostatecznie na wciśnięciu przycisku "Download". Wyniki akwizycji wyświetlane są w polach podglądu, gdzie sygnał może być wstępnie analizowany dzięki polom pokazującym użytkownikowi wartości napięć na podziałkę i odstępu czasu na podziałkę/próbkę. Wyniki analizy mogą ponadto zostać zapisane do pliku w jednym z 3 formatów:

• Binarnie : [8bit][8bit]...[8bit][8bit], w konwencji starszy-młodszy bajt,

• Liczby całkowite ze znakiem : [int], [int], ..., [int]  np. 1255,-253, 2346

• Liczby zmienno-przecinkowe : [float], [float], ..., [float]  np. 2.00e - 001,-2.54e - 001, 6e - 001

Dodatkowo zaimplementowano:

• możliwość wykonania pojedynczego pomiaru wciskając przycisk "Check",

• możliwość skonfigurowania czy podglądany sygnał ma wartość taką jakby rezystancje wejściowe przetworników miały powyżej 1Mfi, co ułatwia późniejsze porównywanie sygnałów z wynikami uzyskanymi oscyloskopami z takimi właśnie wejściami.

5.4. Sterowanie interfejsem GPIB

 

Użytkownik steruje interfejsem GPIB za pośrednictwem zakładki prezentowanej na rysunku 5.6.

 

Rysunek 5.6. Sterowanie interfejsem GPIB

 

W oknie użytkownik wpisuje komendy zaimplementowanego języka skryptowego, którego opis składni znajduje się w Dodatku E. Funkcjonalność języka pozwala użytkownikowi na tworzenie procedur pomiarowych, gdzie dane wysłane z urządzeń pomiarowych mogą być podglądane w polu podglądu lub mogą być zapisywane prosto do pliku. Linie kodu procedury, które są syntaktycznie niepoprawne lub podczas wykonywania wystąpił błąd transmisji, zostaną wskazane użytkownikowi.

Dodatkowo każda uruchomiona procedura może zostać przerwana przez użytkownika wciskając przycisk "Kill". Ponadto zaimplementowano możliwości podglądania zmiennych oraz podglądania wyników (na wykresie), które zostały zapisane do pliku w formacie zmienno-przecinkowym (format zmienno-przecinkowy jest używany przez większość urządzeń pomiarowych obsługiwanych poprzez interfejs GPIB).

W celu podglądania wyników należy otworzyć plik z danymi i tylko z danymi, w  przeciwnym razie podgląd nie będzie dostępny. Następnie użytkownik może określić z jakimi wartościami na podziałkę ma być przedstawiany wykres.

 

5.5. Sterowanie interfejsem I2C

 

Użytkownik steruje interfejsem I2C za pośrednictwem zakładki prezentowanej na rysunku 5.7.

 

Rysunek 5.7. Sterowanie interfejsem I2C

 

W celu sterowania interfejsem użytkownik musi wykonać 3 kroki:

1. W widocznym oknie użytkownik musi ustawić szybkość transmisji:Normal – 100kb/s, Fast – 400kb/s,High – 3.5Mb/s,

2. Napisać prosty kod sterujący w interpretowanym języku, którego składnia i przykład prezentowane są poniżej oraz krótko omówione dalej w tekście:

• [Field1], [Field], ..., [Field];

• [Field] = {S w||r n} [s hex]||[g]

• [Field1] = [S w||r s hex] {n}

• przykad : ”S w 12 s, 3e s, 8d s, S w r 12 s, s g, g n; ”

  Poszczególne pola całej komendy oddzielane są znakiem spacji, a cała komenda zakończona średnikiem generującym sekwencję stopu. Pole pierwsze "Field1" musi zawierać fiagi "S", "w" lub "r", "s" oraz liczbę w postaci heksadecymalnej, a parametrem opcjonalnym jest fiaga "n". Pozostałe pola winny zawierać przynajmniej fiagę "s" wraz liczbą heksadecymalną, albo tylko fiagę "g", reszta fiag jest opcjonalna, przy czym istnieje zasada, że ostatnia fiaga jest fiagą "aktywną".

  Poszczególne fiagi odpowiadają za:
  S – sekwencja startu lub wznowienia startu.
  Jeżeli ta fiaga występuje, to należy określić fiagę "w" lub "r" oraz fiagę "s", a wartość "hex" jest adresem urządzenia docelowego,
  w – określenie kierunku transmisji› zapis,
  r – określenie kierunku transmisji‹ odczyt,
  s – wysłanie bajtu. Jeżeli ta fiaga występuje, to należy również podać wartość "hex", która zostanie wysłana,
  g – odebranie bajtu,
  n – fiaga określa, że nie będzie generowana sekwencja potwierdzenia do urządzenia docelowego, co typowo informuje urządzenie docelowe, że transmisja dobiegła końca.

  3. Nacisnąć przycisk "Send". Jeżeli kod sterujący jest syntaktycznie niepoprawny albo podczas transmisji powstał błąd, to użytkownik jest informowany która linia kodu jest błędna lub nie wykonała się poprawnie.
  Typowym błędem transmisji może być nierozpoznanie adresu przez urządzenie docelowe. Jeżeli użytkownik wydawał komendy odczytu, to wyniki odczytu są wyświetlane w oknie podglądu na bieżąco podczas wykonywania kodu.

Dodatkowo zostały zaimplementowane możliwości zapisu/odczytu kodu sterującego oraz zapisu wyników odczytu do pliku. Funkcjonalności te pozwalają na wgranie kodu sterującego, wygenerowanego przez odpowiednie programy, w przypadku gdy intencją użytkownika jest np. wgranie dużego bloku danych do pamięci fiash oraz pozwalają na przenoszenie wyników pomiarów, które mogą zostać zapisane w formacie ASCII, gdzie kolejne bajty zapisywane są w formie liczb heksadecymalnych oddzielonych znakiem spacji.

 

5.6. Sterowanie interfejsem RS232C

 

Użytkownik steruje interfejsem RS232 za pośrednictwem zakładki prezentowanej na rysunku 5.8.

 

Rysunek 5.8. Sterowanie interfejsem RS232C

 

W widocznym oknie użytkownik konfiguruje moduł UART zaimplementowany w układzie FPGA przez ustawienie odpowiedniego buadrate. Po czymmoże wysłać wpisany tekst w formie znaków ASCII lub w formie liczb heksadecymalnych oddzielonych znakiem spacji. Zaimplementowanie wysyłania danych w formie heksadecymalnej służy do wysyłania plików binarnych.

 

Cheć odbierania (nałsuchiwania portu RS232) jest zaznaczana przez użytkownika poprzez wciśniecie "Listen". Odbieranie danych dzieje się automatycznie i również może być widoczne w formie heksadecymalnej.

 

Dodatkowo zaimplementowano możliwość zapisu kodu odbieranego do pliku, co pozwala na np. przesyłanie niedużych plików graficznych, w przypadku transmisji w formie binarnej (widzianej w oknie podglądu odbieranych danych jako bajty w kodzie heksadecymalnym oddzielone znakiem spacji)

 

6. Testy

6. Testy

 

W celu sprawdzenia poprawnego przygotowania modułów sprzętowych oraz działania aplikacji wykonano serię podstawowych testów.

 

6.1. Testy kontrolerów

 

Zostały wykonane testy kontrolerów RS i USB zaimplementowanych na płycie UMC. Testy polegały na 100-krotnym wykonaniu zapisu/odczytu 4096 słów 16-bitowych do/z pamięci przetworników zaimplementowanych na płycie DAC. W ten sposób każdy zapis został zweryfikowany. Wyniki testu dla kontrolera RS i USB są przedstawiane kolejno w tabelach 6.1 oraz 6.2.

 

Tabela 6.1. Wyniki testu kontrolera RS

 

Tabela 6.2. Wyniki testu kontrolera USB

 

Na łączną liczbę zapisywanych bajtów składają się: 12 bajtów komendy zapisu nadanych 409600 oraz 7 bajtów komendy odczytu również nadanych 409600 razy.

Na łączną liczbę odczytywanych bajtów składają się:
W przypadku kontrolera RS: 8 bajtów wyniku komendy odczytu oraz 2 bajty dodatkowe (znak spacji i powrotu karetki). Razem 10 bajtów odebranych 409600 razy. Odbieranie echa komend następuje równolegle z ich nadawaniem, stąd nie wchodzą one w skład łącznie odbieranych bajtów.

W przypadku kontrolera USB: 8 bajtów wyniku komendy odczytu oraz 2 bajty potwierdzenia komendy zapisu i odczytu. Razem 10 bajtów odebranych 409600 razy. Zwarzywszy na zaimplementowaną metodę ponawiania transmisji, w przypadku nie uzyskania prawidłowej informacji zwrotnej, to przewidywania odnośnie wyników testów zostały spełnione, co jednocześnie dowodzi efektywności tej metody.

 

6.2. Testy generacji i akwizycji sygnałów

 

Przedstawiane testy generacji i akwizycji sygnałów przy pomocy przetworników LTC2207 i AD9777 zostały przedstawione w [10]. W niniejszej pracy zostały przetestowane jedynie dodane funkcje oraz poprawność działania aplikacji użytkownika.

 

6.2.1. Test generacji

 

W ramach testu generacji zostały przetestowane:

• poprawność konfigurowania częstotliwości próbkowania,

• poprawność generowanych wyników z sygnałami mierzonymi doświadczalnie przy pomocy oscyloskopu TDS7404B.

 

 

1. Test poprawności konfiguracji częstotliwości polegał na konfiguracji układów MAX9452 oraz AD9512, i porównaniu uzyskiwanej doświadczalnie częstotliwości z wyliczoną przez aplikację użytkownika.

   Sygnałem testowym był sygnał prostokątny o wypełnieniu 50% składający się z 4096 próbek. Mierzona doświadczalnie częstotliwość próbkowania powinna wynosić tyle ile częstotliwość sygnału pomnożona 4096 razy.

   Wybrane konfiguracje układów MAX9452 i AD9512i, wraz z wynikami, zostały przedstawione kolejno w tabelach 6.3 i 6.4. W przepadku testowania zgodności częstotliwości konfigurując układ MAX9452, układ AD9512 został skonfigurowany tak by nie dzielił sygnału zegarowego.

Tabela 6.4. Test konfiguracji AD9512

 

2. Test poprawności generacji przebiegów sygnału polegał na skonfigurowaniu częstotliwości próbkowania na 25MHz oraz wykorzystania kanału drugiego układu AD9777.

   Następnie zmierzony sygnał porównano z wygenerowanym sygnałem w oknie podglądu wewnątrz aplikacji użytkownika.

   Wyniki porównywania kształtów zostały przedstawione na rysunkach od 6.1 do 6.6, a wyniki porównania uzyskanych wartości międzyszczytowych sygnału prostokątnego dla różnych ustawień wzmocnienia dalej w tabeli 6.5.

Sygnał prostokątny

 

Rysunek 6.1. Sygnał generowany: Vpp = 919mV, czst. = 6.1kHz

 

Rysunek 6.2. Sygnał zmierzony TDS7404B: Vpp = 917mV, czst. = 6.1kHz

Sygnał sinusoidalny

 

Rysunek 6.3. Sygnał generowany: Vpp = 919mV, czst. = 24.4kHz

 

Rysunek 6.4. Sygnał zmierzony TDS7404B: Vpp = 913mV, czst. = 24.4kHz

Sygnał schodkowy

 

Rysunek 6.5. Sygnał generowany: Vpp = 919mV, czst. = 6.1kHz

Rysunek 6.6. Sygnał zmierzony TDS7404B: Vpp = 915, czst. = 6.1kHz

Tabela 6.5. Wyniki porównania wartości międzyszczytowych sygnałów

 

Przedstawione wyniki, odnośnie konfiguracji układów MAX9452 i AD9512 pokazują, iż użytkownik ma możliwość ustawienia częstotliwości próbkowania z dużą dokładnością. Wyniki odnośnie generacji sygnałów wykazały jednak, iż użytkownik powinien brać pod uwagę niedokładność sygnału w oknie podglądu względem rzeczywiście wygenerowanego sygnału.
Z tabeli 6.5 widać, że różnica może osiągnąć nawet ok. 12mV. Różnica ta jest spowodowana nieliniową charakterystyką przetwornika AD9777.

 

6.2.2. Test akwizycji

 

W ramach testu akwizycji zostały przetestowane:

• moduł odpowiedzialny za układ wyzwalania,

• poprawność odbieranych sygnałów z sygnałami mierzonymi doświadczalnie przy pomocy oscyloskopu TDS7404B.

 

1. Test wyzwalania polegał na uruchomieniu akwizycji z ustawionym na pewną wartość poziomu wyzwalania. Wybrane ustawienia wraz z otrzymanymi sygnałami prezentowane są na rysunkach od 6.7 do 6.11.

Rysunek 6.7. Sygnał odebrany. Ustawione wyzwolenie na 76.25mV

 

Rysunek 6.8. Sygnał odebrany. Ustawione wyzwolenie na 152.5mV

 

Rysunek 6.9. Sygnał odebrany. Ustawione wyzwolenie na 208.75mV

 

Rysunek 6.10. Sygnał odebrany. Ustawione wyzwolenie na 295.0mV

 

Rysunek 6.11. Sygnał odebrany. Ustawione wyzwolenie na 457mV

 

2. Test poprawności odbieranych sygnałów polegał na porównaniu kształtu, częstotliwości oraz wartości międzyszczytowych sygnałów: zmierzonego doświadczalnie z sygnałem otrzymywanym w podglądzie wew. aplikacji.

   W tym celu wykorzystano generator sygnałów, generujący sygnał trójkątny, oraz drugi kanał akwizycji, w którym częstotliwość próbkowania została ustalona na 12.5MHz. Kanałowi temu została przydzielona pamięć wystarczająca na 2048 próbek, stąd wynika, iż sygnał którego k okresów jest widoczne w oknie podglądu jest o częstotliwości około 6, 1 · k [kHz].

   Wyniki testu umieszczono na rysunkach począwszy od 6.12 do 6.15.

Pierwszy pomiar

Rysunek 6.12. Sygnał zmierzony TDS7404B: Vpp = 912, czst. = 12.18kHz

Rysunek 6.13. Sygnał odebrany: Vpp = 915, czst. = 12.2kHz
 

Drugi pomiar

Rysunek 6.14. Sygnał zmierzony TDS7404B: Vpp = 903, czst. = 42.78kHz

Rysunek 6.15. Sygnał odebrany: Vpp = 915, czst. = 42.7kHz

Prezentowane testy odnośnie układu wyzwalania, począwszy od rysunku 6.7, pokazują prawidłowe wyzwalanie akwizycji. Dalsze testy, począwszy od rysunku 6.12, odnośnie poprawności otrzymywanych sygnałów w oknie podglądu pokazują, iż ustawiana przez użytkownika częstotliwość próbkowania jest dobrym przybliżeniem rzeczywistej częstotliwości próbkowania.

Różnice w prezentowanych wynikach wynikają głównie z niedokładności oszacowania części pełnych okresów w oknie podglądu sygnału. Widoczne są również różnice w wartościach międzyszczytowych między sygnałem zmierzonym a odebranym. Wynikają one głównie z niedokładności oszacowania punktów szczytowych w oknie podglądu sygnału.

Otrzymane wyniki testów akwizycji i generacji sygnałów, pokazały prawidłowe działanie aplikacji użytkownika oraz modułów sprzętowych. Należy nadmienić, iż na bazie wyników testów, podgląd sygnału generowanego nie powinien być uznawany jako dokładne odzwierciedlenie sygnału.

 

6.3. Test sterowania interfejsem GPIB

 

W ramach testów sterowania interfejsem GPIB zostały wykonane następujące procedury pomiarowe.

• Wykonanie prostej procedury, w której urządzenie zaadresowane i dołączone do interfejsu GPIB zwraca swój kod indentyfikacyjny. Plik z procedurą został umieszczony w katalogu "testGpib" pod nazwą "testTektronix.gpib",

• Wykonanie prostego pomiaru częstotliwości. Plik z procedurą został umieszczony w katalogu "testGpib" pod nazwą "MeasFreqTestTektronix.gpib",

• Wykonanie procedury wysyłającej numeryczną formę sygnału do oscyloskopu TDS7404B. Sygnał ten został wygenerowany przez przetworniki DAC, a następnie został spróbkowany przez przetwornik ADC i zapisany do pliku. Plik z procedurą został umieszczony w katalogu "testGpib" pod nazwą "ToOscWfmTestTektronix.gpib".

6.3.1. Wyniki procedury identyfikacji

Wynik procedury identyfikacji został zaprezentowany na rysunku 6.16 – w oknie podglądu wykonywanego kodu.

 

Rysunek 6.16. Identyfikacja TDS7404B

 

Jak widać z powyższego rysunku zwróconym kodem identyfikacji jest słowo "TEKTRONIX,TDS7404B,B020487,CF:91.1CTFV:4.0.4", co jest prawidłowym kodem oscyloskopu TDS7404B znajdującym się w laboratorium PERG.

 

6.3.2. Wyniki procedury pomiaru częstotliwości

Do procedury pomiaru częstotliwości został wygenerowany sygnał z przetwornika DAC1. Następnie została wykonana procedura pomiaru częstotliwości tego sygnału. Sygnał oraz wynik procedury są prezentowane kolejno na rysunkach 6.17 i 6.18.

Sygnał przedstawiany na rysunku 6.17 (kanał 1) został zbadany oscyloskopem TDS7404B. Odczyt częstotliwości sygnału wynosił ok 44.9 kHz. Następnie została wykonana procedura, której wynik widoczny jest na rysunku 6.18 – w oknie podglądu wykonywanego kodu.

 

Rysunek 6.17. Sygnał referencyjny (kanał 1)

Rysunek 6.18. Pomiar częstotliwości

 

Jak widać z powyższego rysunku zwróconą wartością częstotliwości sygnału jest "44.927E+3", co zgadza się w dobrym przybliżeniu z pomiarem.

 

6.3.3. Wynik procedury transmisji sygnału do TDS7404B

 

Sygnał prezentowany na rysunku 6.17 (kanał 1) w poprzednim podrozdziale został spróbkowany przez przetwornik ADC1. Wynik spróbkowana widoczny jest na rysunku 6.19 (kanał 1 ADC).

 

Rysunek 6.19. Spróbkowany sygnał

 

Spróbkowany sygnał został zapisany do pliku "data.aint". Do pliku została dopisana na początku komenda oscyloskopu "curve" pozwalająca na wysłanie sygnału do oscyloskopu TDS7404B. Nie jest to wymagane i zostało dodane tylko jako test sterowania interfejsem GPIB z pliku.

Po pełnej transmisji danych otrzymano wynik na ekranie oscyloskopu TDS7404B, który prezentowany jest na rysunku 6.20. Oscylogram ten zgadza się z wytworzonym sygnałem, co ostatecznie dowodzi prawidłowości transmisji danych. Dodatkowo test ten pokazuje, że zadania analizy sygnałów mogą zostać przeprowadzane z wykorzystaniem oscyloskopu TDS7404B, co podsumowuje ostatecznie założenie koncepcyjne o przełożeniu zadań analizy sygnałów na oscyloskop cyfrowy.

Wykonane testy dowodzą również poprawności działania modułu sprzętowego kontrolera GPIB oraz działania kodu sterującego napisanego w zaimplementowanym języku skryptowym.

 

Rysunek 6.20. Oscylogram sygnału

 

6.4. Test sterowania interfejsem I2C

Test interfejsu I2C opierał się na skonfigurowaniu i odebraniu serii próbek sygnału z przetwornika analogowo-cyfrowego MAX1037 [49] zaimplementowanego w NanoBoardzie NB1. Wyniki wartości próbek odebranych z przetwornika przy zadanym sygnale wejściowym zostały zaprezentowane w tabeli 6.6.

Widoczne różnice w próbkach oczekiwanych i odebranych są wynikiem niestabilnego sygnału próbkowanego. Różnice te są jednak niewielkie, co dowodzi poprawnego działania sprzętowych modułów i aplikacji.

 

Tabela 6.6. Wyniki odebranych próbek

 

6.5. Test sterowania interfejsem RS232C

W ramach testów sterowania interfejsem RS232C zostały wykonane następujące
testy:

• Wysłanie/odebranie niedużego zdjęcia zapisanego w formacie .bmp,

• Użyto interfejs wraz z możliwościami aplikacji jako komunikator, gdzie przeprowadzono rozmowę pomiędzy użytkownikiem jednego komputera a użytkownikiem drugiego komputera.

W obu testach sprawdzono poprawność nadanego i odebranego bajtu. Do testów interfejsu jako komunikatora wykorzystano program "Terminal v1.9b 20040204" [50] po stronie drugiego komputera (nie podłączonego do płyty UMC). Wyniki testów pokazane
są w tabeli 6.7.

 

Tabela 6.7. Wyniki nadawania/odbierania

 

Testy te wykazały poprawność każdego nadanego bajtu z bajtem odebranym, co dowodzi poprawności działania sprzętowych modułów oraz aplikacji.

--------------------

1. Łukasz Dymanowski. Projekt i wykonanie modułu akwizycji danych z wykorzystaniem standardu PMC. Politechnika Warszawska, 2007.

49. Maxim. MAX1036-MAX1039. http://www.datasheetcatalog.com/datasheets_pdf/M/A/X/1/MAX1037.shtml.

50. Terminal v1.9. http://www.port80h.com.pl/articles.phpfilng=pl&pg=276.

7. Podsumowanie

7. Podsumowanie

 

7.1. Zrealizowane cele

 

Zaadoptowano niezbędne moduły do obsługi przetwarzania A/C oraz C/A (w tym do obsługi pamięci układów FPGA), zaadoptowano moduły kontrolujące interfejsy I2C, RS oraz GPIB, zaadoptowano moduł RS oraz wykonano moduł USB kontrolujące system.

Powyżej opisane moduły połączono w system o konfiguracji master-slave o magistralowej topologii połączeń, który następnie przetestowano napisaną aplikacją użytkownika. Testy wykazały iż system działa prawidłowo w większości przypadków. Przypadki kiedy cały system nie działa prawidłowo zostały opisane w podrozdziale 7.4.2.

 

7.2. Możliwości wykorzystania

 

Stworzona aplikacja użytkownika w ramach zaimplementowanych funkcji pozwala na:

• badanie wpływu parametrów sygnału zegarowego taktującego przetworniki na otrzymywane wartości próbek sygnału w przypadku akwizycji oraz na wytwarzane sygnały w przypadku generacji sygnału,

• zarówno sterowanie urządzeniami dołączonymi do interfejsu GPIB jak i tworzenie zaawansowanych procedur pomiarowych,

• zarówno konfigurowanie urządzeń przy wykorzystaniu interfejsu RS232C jak i wykorzystanie tego interfejsu jako komunikator lub do przesyłania niedużych plików, • konfigurowanie urządzeń przy wykorzystaniu interfejsu I2C, który nie jest zazwyczaj dostępnym interfejsem w komputerach PC,

• wykorzystanie aplikacji podobnie jak popularnych programów "HyperTerminal" czy "Terminal v1.9" dzięki zaimplementowanej funkcjonalności debugingu.

Zaimplementowane funkcje mogą zostać wykorzystane w zarówno jako pomoc dydaktyczna jak i również mogą okazać się pomocne w do celów prototypowania innych urządzeń.

Pierwszym wykorzystaniem opracowanych w niniejszej pracy funkcjonalności było użycie interfejsu I2C, w celach testowania zaimplementowanego kodu na ATmega8-16U, realizującego Glue-Logic pomiędzy interfejsem I2C a SPI.

Projekt ten wykonywany był na łamach zadania o tytule Projekt Stabilizowanego Zasilacza na Wysokie Napięcie w którym uczestniczyli: Schodowski Łukasz, Radosław Rybaniec, Tomasz Janicki.

 

7.3. Możliwości dalszego rozwoju

 

Wykonane prace pozwoliły na głębsze przemyślenie zrealizowanego systemu pomiarowego, co pozwala na zaproponowanie pewnych rozwiązań przyszłym edytorom niniejszego systemu pomiarowego. Propozycje zostały wypunktowane poniżej:

1. Wykorzystanie interfejsów szeregowych jest dostatecznym rozwiązaniem w przypadku wolnych transmisji takich jak konfiguracja, gdyż typowo nie istnieje potrzeba częstej rekonfiguracji urządzeń. Problemem jest natomiast transmisja dużych bloków danych zarówno pomiędzy PC a UMC, ale i także pomiędzy DAC i DIC.

   Przypadkiem dłuższej transmisji danych pomiędzy DAC i DIC byłoby: przesłanie zawartości pamięci z przetwornika analogowo-cyfrowego, odpowiednie przetworzenie tych danych, a następnie przesłanie ich dalej do kontrolera GPIB.

   Propozycją rozwiązującą taki problem jest stworzenie prostego kontrolera na płycie UMC, któremu kontroler szeregowy (rs_syscon lub VCusb) oddawałby sterowanie na czas pełnego przesyłu bloku danych, z pamięci przypisanej przetwornikom do kontrolera GPIB. Przy takim rozwiązaniu transmisja zachodziłaby z maksymalną możliwą szybkosćią określoną przez zegar na płycie UMC.

   W przypadku transmisji dużej ilości danych pomiędzy PC a UMC takiej jak: przesłanie sygnału wcześniej zapisanego w pliku - nie jest efektywne stosowanie interfejsów szeregowych (nawet tak szybkich jak USB).

   Propozycją rozwiązującą ten problem byłoby stworzenie jednego z dwóch kontrolerów: kontrolera Ethernet albo kontrolera VME/VXI. Pierwsze rozwiązanie dawałoby dodatkowo możliwość komunikacji z UMC poprzez internet, natomiast drugie dawałoby możliwość wykorzystania programów takich jak LAbView do tworzenia interfejsu użytkownika.

   Oba rozwiązania dają znacznie większą przepustowość niż interfejsy szeregowe i być może dzięki nim dawałoby się stworzyć system pomiarowy przetwarzający dane nawet w czasie rzeczywistym.

2. Wykorzystanie biblioteki WinApi pomimo prostego wykorzystania posiada znaczącą wadę – nie przenosńość na inne systemy operacyjne. Jedyną możliwosćią uruchomienia aplikacji pod innymi systemami operacyjnymi jest emulacja taką jak w przypadku systemu Linux daje program Wine. Rozwiązanie to jednak nie gwarantuje prawidłowosći funkcjonowania aplikacji.
   Jedynym rozwiązaniem jest przepisanie aplikacji z wykorzystaniem innych bibliotek takich jak popularne WxWidgets.

7.4. Niezrealizowane dodatki, znane Bugi i troubleshooting

 

7.4.1. Niezrealizowane dodatki

 

• System posiada możliwość (mechaniczną, elektryczną) do komunikacji protokołem PCI [4], który mógłby zostać użyty zamiast Wishbone, co podniosłoby rangę zaproponowanych rozwiązań do rangi standardowych, co umożliwiłoby stosowanie płyt DIC oraz DAC wszędzie tam, gdzie istnieje interfejs PMC. Niestety z powodów wadliwych połączeń nie udało się przetestować takiej komunikacji.

• Z racji ograniczonych zasobów układów FPGA, a w tym pamięci RAM, zostały przypisane pewne skończone bloki pamięci do przetworników C/A oraz A/C na płycie DAC. Pomysłem było skonstruować dodatkowe moduły sprzętowe, które średnio-zaawansowany użytkownik mógłby dobrać (przy tworzeniu projektu systemu) i niniejszym w ten sposób zmieniać pojemność pamięci dla poszczególnych przetworników. Niestety nie zostało to wykonane. Aby zmieniać pojemności przypisanej pamięci należy ręcznie w projekcie sprzętowym oraz w aplikacji użytkownika zmienić odpowiadające im wartosći oraz przekompilować oba projekty zwracając na uwagi kompilatora.

7.4.2. Znane Bugi i troubleshooting

 

 

• Podczas wyłączania aplikacji lub odłączania portu COM, gdy wczesńiej próbowano dokonać transmisji na portach COM w przypadku komunikacji przez interfejs którego moduł kontrolera systemu nie jest wgrany na FPGA płyty UMC, to aplikacja ma wysokie prawdopodobieństwo zawiesić się w oczekiwaniu na zakończenie transakcji po porcie COM, której w rzeczywistości nie było:

  "A small caveat: closing the last handle to a file object counts as a synchronous I/O operation, and it will synchronize with other synchronous I/O operations if the file wasn’t opened with FILE_FLAG_OVERLAPPED. Closing the last handle to a pipe, socket or other device that’s being currently used in a synchronous I/O operation will block until the operation completes. This is due to a small design oversight in the Windows I/O subsystem: the synchronous I/O lock of a file object isn’t dropped before entering the wait for the operation’s completion, causing the nesting of two locks and the potential for deadlocks. In Windows Vista and later, CancelSynchronousIo can be used to interrupt and cancel stuck I/O operations" --  Zródło MSDN

  Aby ominąć powyższy problem należy, jeżeli wystąpi to zrestartować komputer (zabicię procesu nic nie daje!) albo uważnie konfigurować połączenie portu COM w pierwszej fazie konfiguracji systemu poprzez aplikację użytkownika.

 

• Podczas włączania oscyloskopu, gdy jest on podłączony do interfejsu GPIB a do układu FPGA na płycie DIC nie został wgrany jeszcze strumień konfiguracyjny, to zauważono częstą niepoprawną inicjalizację oscyloskopu TDS7404B, co powoduję iż należy z restartować oscyloskop. Czynność wykonywać aż do skutku. W przypadku wcześniej wgranej konfiguracji do układu FPGA na płycie DIC nie zauważono takiego zachowania.

 

• Podczas przełączania zegara (zakładka konfiguracji AD9512) z CLK2 na MAX9452, gdy wczesńiej CLK2 był włączony, lub podczas przełączenia z MAX9452 na CLK2, gdy wczesńiej MAX9452 był włączony, to pamięć przypisana przetwornikom może ulec przypadkowym zmianom, co całkowicie dyskwalifikuje wcześniejsze zgromadzone w niej informacje. Aby temu zapobiec należy wczesńiej wyłączyć aktywny zegar, następnie dokonać zmiany na nieaktywny pożądany sygnał zegarowy i ostatecznie włączyć go.

8. Literatura

8. Literatura

 

1. Wiesław Winiecki. Rozproszone Systemy Kontrolno Pomiarowe – wykład, 2008.

2. Bluetooth SIG. Specification of the Bluetooth System. http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/, Listopad 2004.

3. Krzysztof Sacha. Systemy czasu rzeczywistego. Oficyna Wydawnicza Politechniki Warszawskiej, 1999.

4. Artur Dybko, Rafał Graczyk, Krzystof T. Poźniak, Ryszard S. Romaniuk. Modularny system fotoniczny z programowalnąwarstwą sterowania i komunikacji w układzie FPGA, 2006.

5. Samer Bou Habib, Ryszard Romaniuk. Opracowanie Mostu PCI dla Węzła Modularnego Systemu Fotonicznego. Politechnika Warszawska, 2008.

6. Wade D. Peterson. The VMEbus Handbook 2nd edition. VITA.

7. WIENER. Series 6000 VME, -64x, -64xC, -64xP, VXI User’s Manual. http://www.wiener-d.com/documents/contentdocuments/7.pdf.

8. Rafał Graczyk, Krzysztof T. Poźniak, Ryszard S. Romaniuk. FPGA based, modular, configurable controller with fast synchronous optical network. Proc of SPIE vol. 6347 part one, 2006.

9. IEEE Standard Physical and Environmental Layers for PCI Mezzanine Cards (PMC). ieeexplore.ieee.org/iel5/7509/20428/00944007.pdf, 2001.

10. Łukasz Dymanowski. Projekt i wykonanie modułu akwizycji danych z wykorzystaniem standardu PMC. Politechnika Warszawska, 2007.

11. Kamil Lewandowski. Projekt i wykonanie karty PMC z interfejsami komunikacyjnymi. Politechnika Warszawska, 2007.

12. VMEbus Card Form Factors. http://www.interfacebus.com/Design_VME_Card_size.html.

13. VME eXtensions for Instrumentation. http://www.vxibus.org/.

14. PartMiner, Inc. FPGA (FIELD-PROGRAMMABLE GATE ARRAY). http://www.partminer.com/glossaryhtml/fpga_field_programmable_gate_array..., 2005.

15. Rafał Graczyk, Krzystof T. Poźniak. Projekt i uruchomienie uniwersalnego kontrolera szyny VME: ”Universal Module Controller”. Praca magisterska, Politechnika Warszawska, 2009.

16. IEEE. IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements.http://standards.ieee.org/getieee802/802.3.html, 2008.

17.  BOSCH. CAN Specification Version 2.0.  www.semiconductors.bosch.de/pdf/can2spec.pdf, Czerwiec 1991.

18. Peter L. B. Johnson. Summer 2004 Laboratory Notes: Computer Engineering II. http://courses.ece.illinois.edu/ece390/books/labmanual/serial-comm-standards.html.

19. USB Implementers Forum, Inc. Universal Serial Bus Revision 2.0 specification. http://www.usb.org/developers/docs/usb_20_122909-2.zip.

20. Clark L. Buxton, Robert A. Kohtz. Enhanced Parallel Port, US Patent number: 5636348. http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP0640229.

21.  Xilnix. System ACE. http://www.xilinx.com/support/documentation/system_ace_solutions.htm.

22. Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. http://focus.ti.com/lit/an/ssya002c/ssya002c.pdf, 1997.

23. Xilinx. Xilinx virtex ii pro platform fpga : Complete data sheet. www.xilinx.com/support/documentation/data_sheets/ds083.pdf, 2007.

24. Xilnix. Block SelectRAM+. http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/products/xaw/memory/embedded/blockram.htm.

25. Xilnix. Digital Clock Manger. http://www.xilinx.com/itp/xilinx7/books/data/docs/s3edl/s3edl0021_13.html.

26. Xilinx. RocketIOTM Transceiver User Guide. www.ee.ucla.edu/~herwin/ocdma/afx-300/ug024.pdf.

27. Jan Ogrodzki. Wstęp do systemów komputerowych, rozdział 8. Oficyna Wydawnicza Politechniki Warszawskiej, 2005.

28. MICRON. MT48LC32M16A2 - Synchronous DRAM . http://www.datasheetcatalog.com/datasheets_pdf/M/T/4/8/MT48LC32M16A2.shtml.

29. Walt Kester. Analog-Digital Conversion. Analog Devices, Inc., 2004.

30. Linear Technology. LTC2207/LTC2206 Datasheet. http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1001,C1150,P13913,D9837.

31. Analog Devices. AD9777 Datasheet Rev Ct. http://www.analog.com/UploadedFiles/Data_Sheets/AD9777.pdf, Styczeń 2006.

32. Analog Devices. AD9512 Datasheet. http://www.analog.com/UploadedFiles/Data_Sheets/AD9512.pdf, Czerwiec 2005.

33. Maxim. MAX9450-MAX9452 Datasheet. http://datasheets.maxim-ic.com/en/ds/MAX9450-MAX9452.pdf.

34. Altera. Cyclone Device Handbook. http://www.altera.com/literature/hb/cyc/cyc_c5v1.pdf, 2006.

35. The Institute of Electrical and Electronic Engineers. GPIB : ANSI/IEEE Std 488.1-1987, IEEE Standard Digital Interface for Programmable Instrumetation, New York 1988.

36. Philips. THE I2C-BUS SPECIFICATION Version 2.1. http://www.nxp.com/acrobat/literature/9398/39340011.pdf, Styczeń 2000.

37. WISHBONE System-on-chip (SoC) Interconnection Architechture for Portable IP Cores Revision B.3, Septmeber 2002.

38. Microsoft. About Common Controls. http://msdn.microsoft.com/en-us/library/bb775493(VS.85,loband).aspx, 2009.

39. John Clayton. RS232 system controller. http://www.opencores.org/project,rs232_syscon, 2005.

40. FTDI Chip. FT245BM USB FIFO ( USB - Parallel ) I.C. http://www.ftdichip.com/Documents/DataSheets/DS_FT245BM.pdf.

41. Altium. CR0150 WB_INTERCON Configurable Wishbone Interconnect. http://www2.altium.com/files/AltiumDesigner6/LearningGuides/CR0150%20WB_INTERCON%20Configurable%20Wishbone%20Interconnect.pdf.

42. Altium. CR0152 WB_MEM_CTRL Configurable Wishbone Memory Controller. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0152%20WB_MEM_CTRL%20Configurable%20Wishbone%20Memory%20Controller.pdf.

43. Altium. CR0118 FPGA Generic Library Guide. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0118%20FPGA%20Generic%20Library%20Guide.pdf.

44. Altium. CR0153 SPI_W Serial Peripheral Interface Controller. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0153%20SPI_W%20Serial%20Peripheral%20Interface%20Controller.pdf.

45. Altium. CR0157 WB_UART8 Serial Communications Port. http://www.altium.com/files/altiumdesigner/s08/learningguides/CR0157%20WB_UART8%20Serial%20Communications%20Port.pdf.

46. Richard Herveille. I2C-Master Core Specification. http://www.opencores.org/project,i2c, Lipiec 2003.

47. Microsoft. Online MSDN documentation. http://msdn.microsoft.com/en-us/default.aspx, 2009.

48. Code::Blocks. http://www.codeblocks.org/downloads.

49. Maxim. MAX1036-MAX1039. http://www.datasheetcatalog.com/datasheets_pdf/M/A/X/1/MAX1037.shtml.

50. Terminal v1.9. http://www.port80h.com.pl/articles.php?lng=pl&pg=276.

9. Dodatki

9. Dodatki

 

9.1. Dodatek A:

 

Wishbone System-on-Chip InterConnection Przez Wishbone rozumiana jest metodologia połączeń pomiędzy modułami sprzętowymi (pomiędzy tzw. IP-CORE’ami). Polega ona na wspólnym interfejsie pomiędzy nimi. Moduły kompatybilne z interfejsem są dzielone na dwa typy widoczne na rysunku 9.1:

• Wishbone-Master (WB-Master) — jest to moduł który inicjuje transakcje (steruje innymi modułami),

• Wishbone-Slave (WB-Slave) -– jest to moduł odpowiadający na transakcje (moduł wykonawczy).

Rysunek 9.1. Wishbone-Master i Wishbone-Slave [5]

Interfejs ten nie definiuje magistrali ale tylko protokół komunikacyjny pomiędzy modułami. Magistrala tworzona jest typowo jako moduł pośredni pomiędzy modułami typu WB-Master a WB-Slave który pełni role dekodera adresu. Moduł taki typowo nazwany jest Wishbone-InterConnect, który został pokazany na rysunku 9.2.

 

Rysunek 9.2. Wishbone Interconnect [5]

9.1.1. Sygnały i transakcja

Zestaw sygnałów niezbędnych do przeprowadzenia komunikacji Wishbone został przedstawiony i krótko omówiony poniżej:

• STB – (z ang. strobe) oznacza rozpoczęcie transakcji przez WB-Master,

• CYC – (z ang. cycle) oznacza rozpoczęcie cyklu jednej lub kilku transakcji,

• ACK – (z ang. acknowledge) wystawiany przez WB-Slave jako koniec pojedynczej transakcji,

• ADR – (z ang. adress) linie adresowe,

• DAT – (z ang. data) linie danych wejściowych lub wyjściowych (w niektórych urządzeniach jest to jeden zestaw linii dwu-kierunkowych),

• SEL – (z ang. select) pokazuje na które bajty danych sąważne,

• WE – (z ang. write enable) w stanie 1 oznacza zapis a 0 odczyt,

• CLK – (z ang. clock) zegar taktujący moduł,

• RST – (z ang. reset) reset modułu (zwykle synchroniczny).

Na rysunku 9.3 przedstawiono operacje odczytu (po lewej) i zapisu (po prawej):

 

Rysunek 9.3. Transakcje Wishbone [37]

 

9.2. Dodatek B : Opis zakładki "MAX9452 ’n CLK1"

 

Rysunek 9.4. Zakładka MAX9452 ’n CLK1

 

Konfiguracja układu MAX9452 oraz została podzielona na 4 części:

1. Grupa Control Reg5

   Disable OUT.
   Ustawienie powoduje, iż wyjsćia układu sąwprowadzane w stan niski

   En. CLK0 OUT.
   Ustawienie powoduje, iż wyjsćie CLK0 układu jest włączane - unieważnia to ustawienie "Disable OUT."

   En. CLK1 OUT.
   Ustawienie powoduje, iż wyjsćie CLK1 układu jest włączane - unieważnia to ustawienie "Disable OUT."

   En. Def. CLK1.
   Ustawienie powoduje, iż zegar wewnętrzny zostanie wybrany domyślnie1 jako referencyjny. W przeciwnym razie będzie to zegar zewnętrzny.

   En. Internal IN.
   Ustawienie powoduje włączenie wejsćia wewnętrznego zegara

   En. External IN.
   Ustawienie powoduje włączenie wejsćia zewnętrznego zegara

   En. Revert. func.
   Ustawienie powoduje włączenie funkcji automatycznego wybierania domyslego zegara w przypadku wyjścia układu ze stanu "Input Error"

   Monitor RST
   Ustawienie resetuje monitor wejść układu - wymagane przy wymuszeniu wyjścia układu ze stanu "Input Error"

2. Grupa Control Reg6

   En. Holdover
   Ustawienie włącza funkcję Holdover, dzięki której układ ustala częstotliwość nominalnąw momencie pojawienia się błędu na obu wejsćiach

   Force Holdover
   Ustawienie powoduje wymuszenie uruchomienia funkcji Holdover

   Acquire VCOX
   Ustawienie powoduje zapamiętanie częstotliwości nominalnej

   Reset
   Ustawienie powoduje, że użytkownik wprowadza układ w stan resetu.

   N1 Div. CLK1 OUT.
   Ustawienie powoduje, iż współczynniki N0 oraz N2 konfigurują niezależnie kolejno CLK0 i CLK1. W przypadku nie ustawienia, oba wyjścia konfigurowane są przez N0.

   Acquire Select
   Ustawienie powoduje, iż częstotliwość jest ustalana przy wykorzystaniu zapamiętanej nominalne częstotliwości. W przypadku nie ustawienia częstotliwość kontrolowana jest poprzez wewnętrzną pętlę PLL.

3. Ustalanie częstotliwości wyjściowej
   Ustalanie częstotliwości polega na wpisaniu odpowiednich wartości w pola N, P i M zgodnie z poniższym wzorem:

 

• Częstotliwość maksymalna 11MHz jest spowodowana tym, iż do układu podłączony jest oscylator o częstotliwosći 11MHz. Istnieje możliwość podłączenia oscylatora o wyższej częstotliwości (do 160MHz), wówczas należy uwzględnić tę poprawkę we wzorze.

 

4. Interfejs równoległy
   Użytkownik steruje liniami SEL0, SEL1, CMON oraz RST poprzez kontrolki o tych samych nazwach co linie. Poprzez ustawienie SEL0 i SEL1, gdy kontrolki "En. Internal IN." i "En. External In." nie są ustawione, to użytkownik konfiguruje jakie wejsćia zegarowe mają zostać włączone. Liną tym odpowiadają zegar zewnętrzny (SEL0) i zegar wewnętrzny (SEL1).

   Poprzez ustawienie linii RST użytkownik wprowadza układ w stan resetu. Poprzez ustawienie linii CMON użytkownik włącza tryb monitorowania wejść układu. Niezbędne do ustawienia, gdy chcemy uzyskać informację o błędzie wejść "Input
   Error". Gdy pojawia się błąd "Input Error", to na wyjsćiach układu pojawia się sygnał 11MHz.

 

9.3. Dodatek C : Opis zakładki "AD9512 ’n CLK2"

 

Rysunek 9.5. Zakładka AD9512 ’n CLK2

 

Konfiguracja układu AD9512 została podzielona na 2 główne części:

1. Grupa AD9512

   Soft Reset
   Ustawienie powoduje programowy reset układu AD9512, wszystkie rejestry poza rejstrem z wewnętrznego adresu 0x00h układu,

   Hard Reset
   Ustawienie powoduje sprzętowy reset układu AD9512, który różni się od programowego tym, że wszystkie rejestry układu sąwprowadzane w znany stan,

   Soft Synch
   Ustawienie powoduje wprowadzenie wyjść układu AD9512 w stan synchronizmu tj. wyrównania faz,

   Synch. Power-Down
   Ustawienie odłącza sekcję synchronizacji wyjść układu AD9512,

   Power-Down input from MAX9452
   Ustawienie odłącza sekcję wejsćia do którego podłączone jest wyjsćie układu MAX9452,

   Power-Down input from CLK2
   Ustawienie odłącza sekcję wejsćia do którego podłączony jest CLK2 (wewnętrzny zegar z układu FPGA),

   Power-Down all input
   Ustawienie odłącza sekcję wejść sygnałów zegarowych układu AD9512,

   Distr. Ref Power-Down
   Ustawienie nie jest dostępne ze względu na możliwość uszkodzenia układu (por. [32] str. 31),

   Input Clock Select
   Ustawia jaki zegar jest wprowadzany na układy przetworników:

   - ustawienie "CLK2", pochodzący z układu FPGA,

   - ustawienie "MAX9452", pochodzący z wyjsćia układu MAX9452.

2. Grupa Clock Output

   Poszczególne okna konfigurują zegary poszczególnych wyjść układu AD9512:
   - "DAC Clock Output" zmienia ustawienia zegara wchodzącego na układ AD9777 (DAC),
   -  "Interal Clock Output" zmienia ustawienia zegara wchodzącego z powrotem do układu FPGA, który można następnie wykorzystać do dowolnych celów,
   - "External Clock Output" zmienia ustawienia zegara wychodzącego na zewnętrzne złącze CON9,
   -  "ADC1 Clock Output zmienia ustawienia zegara wchodzącego na układ LTC2207 (ADC1), czyli pierwszego przetwornika analogowo-cyfrowego,
   -  "ADC2 Clock Output zmienia ustawienia zegara wchodzącego na układ LTC2207 (ADC2), czyli drugiego przetwornika analogowo-cyfrowego.

Ustawieniami wspólnymi dla wszystkich okien "Clock Output" są:

• Ustawienie dzielników częstotliwości albo ich brak,

• Ustawienie przesuwnika fazy,

• Ustawienie odpowiednich poziomów napięć albo prądów wyjść zegarowych,

• Ustawienie ignorowania stanu linii FUNCTION dla poszczególnych wyjść (w przypadku skonfigurowania linii FUNCTION jak funkcję SYNCB),

• Odłączenie danego wyjsćia – ustawienie "force idle" wraz z "No synch.",

• Możliwość ustawienia stanu początkowego sygnałów zegarowych wyjść – stan niski albo stan wysoki.

Ustawieniami dodatkowym dla zegarów wychodzących na układy ADC są:

• Ustawienie standardu wyjść – LVDS albo CMOS,

• Bezpośrednie (i zarazem dodatkowe) wyłączenie wyjść,

• Ustawienie "odwróconego" sygnału CMOS, w przypadku wybrania standardu wyjść CMOS.

Ustawieniami dodatkowymi tylko dla sygnału zegarowego wychodzącego na drugi układ ADC (ADC2) są ustawienia opózńienia, realizowane dzięki ustawieniom "Ramp Capicators", "Delay Adjust" oraz "Ramp Current". Ustawione opóźnienie wyświetlane jest oknie "Delay [ns]". Ustawianie opóźnienia jest możliwe tylko jeśli zostało ustawione "Delay Enable".

Wszystkie wyżej wymienione ustawienia są wprowadzane do układu AD9512 poprzez naciśnięcie przycisku "Apply" w poszczególnych grupach ustawień.

 

9.4. Dodatek D : Opis zakładki "DAC"

 

Rysunek 9.6. Zakładka DAC

 

Konfiguracja układu AD9777 została podzielona na 5 głównych części:

1. Grupa General Settings

   Soft Reset
   Ustawienie powoduje programowy reset układu AD9777, powodujący wprowadzenie wszystkich rejestrów konfiguracyjnych w znany stan, poza rejestrem spod wewnętrznego adresu 0x00h układu AD9777,

   Hard Reset
   Ustawienie powoduje programowy reset układu AD9777, powodujący wprowadzenie wszystkich rejestrów konfiguracyjnych w znany stan,

   Power Down
   Ustawienie powoduje odłączenie częsći analogowych i cyfrowych układu AD9777, poza częsćią odpowiedzialną za komunikację po SPI,

   Sleep Mode
   Ustawienie powoduje odłączenie wyjść układu AD9777,

   Data Clk +200mV
   Ustawienie zwiększa wydajność prądową wyjsćia zegarowego DATACLK z układu AD9777, co zwiększa amplitudę sygnału o około 200mV,

   Inv. DataClk
   Ustawienie odwraca sygnał zegarowy na wyjściu DATACLK,

   Data Type Input
   Ustawienie interpretacji danych wejściowych:
   - U2,
   - binarnie bez znaku.

   Current Mode
   Ustawienie prądu referencyjnego IRef :
   - R ustawia ok 1.2mA, które jest rozdzielane na dwa kanały po połowie,
   - 2R ustawia dla kanału pierwszego ok 1.2mA, a dla drugiego ok 0.6mA.

 

2. Grupa PLL Settings

   Enable PLL
   Ustawienie włącza pętlę PLL,

   PLL Divide
   Ustawienie podzielnika pętli PLL,

   Pump Control
   Ustawienie kontroli prądowej pętli PLL:
   - Auto – prąd jest dostosowywany automatycznie,
   - Manual – prąd jest ustawioany przez użytkownika w polu "Pump Charge".

 

3. Grupa Interpolation ’n modulation

   Interpolation
   Ustawienie mnożnika interpolacji: 1x, 2x, 4x, 8x, gdzie 1x oznacza brak interpolacji,

   Modulation
   Ustawienie podzielnika modulacji: brak, /2, /4, /8,

   Type
   Ustawienie typu modulacji: rzeczywista albo zespolona,

   Form
   Ustawienie modulacji za pomocą funkcji: exp(−j!t), exp(+j!t)

   Stuff 0’s
   Ustawienie powodujące "wstawianie zer", w przypadku interpolacji i modulacji, powodujcie poprawienie odpowiedzi częstotliwościowej układu (por. [31] str. 38).

4. Grupy Channel Settings

   Fine Gain, Coarse Gain, Offset, Direction
   Ustawienie maksymalnych prądów wyjsćiowych wg. wzoru podanego poniżej:

   

   Timer Counts
   Ustawienie wartości modulo liczników adresu,

   Reset
   Ustawienie powoduje zresetowanie licznika adresu,

   Count Enable
   Ustawienie powoduje start inkrementacji licznika, pod warunkiem nie ustawianego resetu i nie ustawionego pola "Timers Synch",

   Timers Synch
   Ustawienie powoduje zresetowanie liczników adresu dla obu kanałów, dzięki czemu możliwe jest uzyskanie synchronizacji wytwarzanych sygnałów,

   50Ohm, 1MOhm
   Ustawienie powodujące zmianę jedynie w obliczaniu pola "Volt/Div". Dla ustawienia 50Ohm wartość jest odpowiednio mniejsza, tak jakby rezystancja wejściowa woltomierza, który mierzymy wartości napięć wytwarzanego sygnału, miała wartość 50.

5. Grupy Channel Signal

   Upload Screen
   Wciśnięcie powoduje wgranie do przetwornika sygnału widocznego na przebiegu. Próbki sygnału wgrane w ten sposób są wynikiem odpowiedniej liniowej aproksymacji wartości pozycji pikseli. Jest to spowodowane tym, iż rozdzielczość okienka podglądu sygnału jest mniejsza zarówno od rozdzielczosći przetwornika jak i pojemności pamięci (przypisanej kanałów przetwornika DAC),

   Upload File
   Wciśniecie powoduje wgranie do przetwornika sygnału określonego numerycznie w pliku. Możliwe są 3 formaty:
   Binarnie
   Format : [8bit][8bit]...[8bit][8bit]
   – słowa 16-bitowe zapisane na kolejnych parach 8-bitowych, gdzie starszy bajt zapisywany jest jako pierwszy od lewej,

   Liczby całkowite ze znakiem
   Format : [int], [int], ..., [int]
   – przecinki oddzielają liczby, bez spacji,

   Przykład: 12,−34, 100, 85

   Liczby zmienno-przecinkowe
   Format : [float], [float], ..., [float]
   – przecinki oddzielają liczby, bez spacji.

   Przykład: 0.1,−0.3, 1.04 lub 1e − 001,−3e − 001, 1.04e − 000

9.5. Dodatek E : Składnia języka skryptowego zakładki GPIB

 

Składnia języka składa się z funkcji, gdzie każda winna być zakończona znakiem średnika (poza instrukcjami pętli "while" i skoku "if"). Zaimplementowano obliczanie prostych wyrażeń matematycznych i tworzenie zmiennych, co pozwala na tworzenie bardziej złożonych procedur pomiarowych. Została dodana również możliwość komentowania pojedynczej linii kodu przy pomocy znaku "#".

Pełne przykłady wykorzystania języka zostały przedstawione w przykładach znajdujących się w plikach (o rozszerzeniu .gpib) w katalogu "testGpib"

Przy obliczaniu wyrażeń dostępne są operatory i funkcje (przedstawione w kolejności pierwszeństwa wykonywania):

• checksrq() – funkcja sprawdza aktualny stan linii SRQ.
  Jeśli stan jest aktywny, to zwracana jest wartość 0xffh, w przeciwnym wypadku 0x00h.
  Funkcja ta musi występować sama (bez innych operatorów i funkcji) w pojedynczym wyrażeniu,

  Przykład : $Wzmienna=checksrq();
  Przykład : if( checksrq() ) {$Wzmienna2 = 34;}
   

• readbyte() – funkcja odczytuje pojedynczy bajt z kolejki wyjściowej kontrolera GPIB i zwraca jego wartość.
  Jeśli kolejka wyjsćiowa jest pusta zwracaną wartosćią jest -1. Funkcja ta musi występować sama (bez innych operatorów i funkcji) w pojedynczym wyrażeniu,

  Przykład : $Wzmienna=readbyte();
   

• Operatory:
  - mnożenie i dzielenie: "*", "/",
  - dodawanie i odejmowanie: "+", "-",
  - operacje na bitach AND oraz OR: "&", "|",
  - operacje porównywania, gdzie zwracanąwartosćią porównania jest 1 albo 0: ">", ">=", "==", "<=", "<", !=,
  - operacje logiczne AND oraz OR, gdzie zwracaną wartosćią operacji logicznych jest 1 albo 0: "&&", "||".

  Przykład : $zmienna= ((12 + 4) | 34 ) <= 0;

• Ponadto:
  - Zwarzywszy na wykorzystany algorytm iteracyjny obliczania wyrazów dostępna jest nieograniczona ilość poziomów  nawiasów "(", "),
  - Wartości obliczanych wyrażeń i zmiennych są typu całkowitego,
  - Deklarowanie zmiennych odbywa się przy wpisaniu nazwy zmiennej poprzedzonej znakiem "$",
  - Nazwa zmiennej powinna zawierać małe litery, poza pierwszą opcjonalną literą (wielką) "W", która ustawia flagę "watch" dla danej zmiennej. Ustawienie tej flagi pozwala na podglądanie wartosći zmiennej w oknie, po wcisńięciu "Enable". Zmienna i jej nowa wartość wyświetlane są za każdym razem, gdy zmienna zmienia wartość.

  Przykład : $Wzmienna= 23 + (22 > 3);
  – spowoduje wyświetlenie w oknie podglądu zmienna=24

Do sterownia interfejsem GPIB zostały zaimplementowane następujące funkcje:

• runifc() – funkcja wprowadza linię ATN w stan aktywny na czas określony przez moduł sprzętowy kontrolera GPIB,

• sendtext(string, expression) – funkcja wysyła tekst (string) programujący do urządzeń docelowych. Przez wyrażenie (expression) użytkownik określa czy wraz z ostatnim znakiem linia EOI ma być wprowadzona w stan aktywny, pod warunkiem że wyrażenie jest logicznie prawdziwe,

  Przykład : $sendtext("text\"cytat\" drugi text", 1);
   

• sendcommand(string, expression) – funkcja wysyła komendy (string) uniwersalne do urządzeń docelowych. Zbiór zaimplementowanych komend: GTL, SDC, PPC, GET, TCT, LLO, DCL, PPU, SPE,SPD, LAD, UNL, TAD, UNT.
  W przypadku komend TAD i LAD wyrażeniem (expresion) jest adres urządzenia (z zakresu od 0 do 30),

  Przykład : sendcommand("TAD", 3);
   

• setatn(expression) – funkcja ustawia linę ATN w odpowiedni stan w zależności od wyrażenia. Jeśli wyrażenie jest prawdziwe, to ATN wprowadzane jest w stan aktywny. Jeśli wyrażenie jest nieprawdziwe, to ATN staje się nieaktywne,

• openfile(string, expression) – funkcja w zależności od wyrażenia (expression) tworzy lub otwiera plik o ścieżce dostępu string. Plik ten jest dalej wykorzystywany przy wykonywaniu funkcji "getdata" i "setdata". W wyrażeniu użytkownik precyzuje:
  - otwarcie pliku do odczytu, gdy wyrażenie jest mniejsze lub równe 0,
  - stworzenie pliku do zapisu, gdy wyrażenie jest równe 1,
  - otwarcie pliku do zapisu na końcu tego pliku, gdy wyrażenie jest większe niż 1.

  Przykład : openfile("moj_plik.txt", 0);
   

• getdata(expression) – funkcja odbiera dane przesłane z urządzeń pomiarowych i wpisuje je do pliku otwartego za pomocą funkcji "openfile". W wyrażeniu (expression) użytkownik precyzuje:
  - gdy wyrażenie jest większe od 0, to wyrażenie określa ile bajtów należy odczytać,
  - gdy wyrażenie jest równe 0, to odczyt ma trwać dopóki nie zostanie napotkany terminator (LF),
  - gdy wyrażenie jest mniejsze od 0, to odczyt ma trwać dopóki nie nastąpi limit czasu odpowiedzi.

  Typowo przez ustawienie wyrażenia na mniej niż 0, z urządzenia docelowego jest odbierana cała przewidywana transmisja.

  Przykład : getdata(-1);
   

• setdata(expression, expression, expression) – funkcja nadaje dane zapisane w pliku, otwartego za pomocą "openfile", do urządzeń docelowych. W kolejnych wyrażeniach użytkownik precyzuje:

  Wyrażenie 1:
  - gdy wyrażenie jest większe od 0, to wyrażenie określa ile bajtów należy nadać,
  - gdy wyrażenie jest równe 0, to nadawanie ma trwać dopóki nie zostanie napotkany terminator (LF) w pliku,
  - gdy wyrażenie jest mniejsze od 0, to nadawanie ma trwać dopóki nie nastąpi koniec pliku lub limit czasu na odebranie danych przez urządzenia docelowe.

  Wyrażenie 2:
  - podaje od jakiej pozycji pliku zaczynają się dane do przesłania;
  - podanie wartosći dodatniej spowoduje ustawienie pozycji względem początku pliku.
  - podanie wartości ujemnej spowoduje ustawienie względem końca pliku.
  - podanie wartosći 0 ustawia pozycję na początek pliku,

  Wyrażenie 3:
  – gdy jest prawdziwe, to wraz z ostatnim przesyłanym bajtem ustawiana jest linia EOI w stan aktywny.

  Przykład : setdata(-1,0,1);

   

• readout(expression, expression) – funkcja powoduje odebranie danych z urządzeń pomiarowych. W kolejnych wyrażeniach użytkownik precyzuje:

  Wyrażenie 1:
  - gdy wyrażenie jest większe od 0, to wyrażenie określa ile bajtów należy odebrać,
  - gdy wyrażenie jest równe 0, to odbiór ma trwać dopóki nie zostanie napotkany terminator (LF) w pliku,
  - gdy wyrażenie jest mniejsze od 0, to odbiór ma trwać dopóki nie nastąpi limit czasu odpowiedzi.

  Wyrażenie 2:
  – gdy jest prawdziwe i został wciśnięty przycisk "Enable", to odebrane dane widoczne sąw oknie podglądu wykonywania kodu.

  Przykład : readout(-1,1);
   

• wait(expression, expression, expression, expression, expression) – funkcja powoduje wstrzymanie wykonywania kodu na określony odstęp czasu oraz zmiany ustawień limitów czasowych.
  W kolejnych wyrażeniach użytkownik precyzuje:

  Wyrażenie 1:
  – powoduje odczekanie odstępu czasowego,

  Wyrażenie 2:
  – powoduje zmiany ilości prób odebrania danej,

  Wyrażenie 3
  – powoduje zmiany ilości prób nadania danej,

  Wyrażenie 4:
  – powoduje zmiany odstępu czasowego pomiędzy próbami nadawania/odbierania i wraz z ilosćią prób stanowi limit czasowy odpowiedzi/nadawania,

  Wyrażenie 5:
  – powoduje zmianę odstępu czasowego wykonywania funkcji "runifc".

  Wszystkie odstępy czasowe podawane sąw ms. Podanie ujemnej wartosći spowoduje brak zmian.

  Przykład : wait(100,-1,-1,-1,-1);
   

• writefile(string, expression) – funkcja powoduje wpisanie zapis ciągu znaków (string) do pliku otwartego przy pomocy funkcji "openfile". Za pomocą wyrażenia, gdy jest prawdziwe, użytkownik precyzuje że ciąg znaków zakonćzony jest konćem linii ("\n"), który róznież zostaje wpisany do pliku.

  Przykład : writefile("koniec pliku", 0);

 

Spis treści

Spis treści

1. Wstęp
    1.1. Systemy rozproszone
    1.2. Modularny System Fotoniczny
    1.3. Pełny Wezeł Modularnego Systemu Fotonicznego
        1.3.1. Płyta UMC
        1.3.2. Płyta nakładkowa DAC
        1.3.3. Płyta nakładkowa DIC
        1.3.4. Konfiguracja sprzetowa PWMSF
2. Geneza, cel i założenia pracy
3. Koncepcja systemu pomiarowego
    3.1. Warstwa sprzetowa
        3.1.1. Konfiguracja i metoda komunikacji
        3.1.2. Sposób sterowania systemem
        3.1.3. Wykorzystanie i rozplanowanie zasobów
    3.2. Warstwa programowa
4. Realizacja modułów sprzętowych
    4.1. Zestaw modułów po stronie UMC
        4.1.1. Kontroler systemowy RS
        4.1.2. Kontroler systemowy USB
        4.1.3. Host_PCI_plug oraz bufory wej/wyj
    4.2. Zestaw modułów po stronie DAC
        4.2.1. Slave_PCI_plug oraz bufory wej/wyj
        4.2.2. Kontrolery pamięci i przetworników A/C
        4.2.3. Kontrolery pamięci i przetworników C/A
        4.2.4. Kontroler SPI
        4.2.5. Dzielnik Zegarów CLK_DIV
        4.2.6. Blok CLK_DISTR_REG
    4.3. Zestaw modułów po stronie DIC
        4.3.1. Kontroler GPIB
        4.3.2. Kontroler RS232C
        4.3.3. Kontroler I2C
        4.3.4. Diody Led
5. Realizacja aplikacja użytkownika
    5.1. Konfiguracja portów
        5.1.1. Konfiguracja zegarów oraz układów dystrybucji sygnału zegarowego
    5.2. Konfiguracja i sterowanie przetwornikami C/A
    5.3. Konfiguracja i sterowanie przetwornikami A/C
    5.4. Sterowanie interfejsem GPIB
    5.5. Sterowanie interfejsem I2C
    5.6. Sterowanie interfejsem RS232C
6. Testy
    6.1. Testy kontrolerów
    6.2. Testy generacji i akwizycji sygnałów
        6.2.1. Test generacji
        6.2.2. Test akwizycji
    6.3. Test sterowania interfejsem GPIB
        6.3.1. Wyniki procedury identy?kacji
        6.3.2. Wyniki procedury pomiaru częstotliwości
        6.3.3. Wynik procedury transmisji sygnału do TDS7404B
    6.4. Test sterowania interfejsem I2C
    6.5. Test sterowania interfejsem RS232C
7. Podsumowanie
    7.1. Zrealizowane cele
    7.2. Możliwości wykorzystania
    7.3. Możliwości dalszego rozwoju