Multi-Computing PC Card PC Card - Part 1

Prezentacja dotyczy:

• studneckiego możliwie nisko-budżetowego rozwiązania,
• karty wielofunkcyjnej PCI lub działającej samodzielnie,
• opartej o sprawdzone [starsze] układy scalone,
• oraz darmowe środowiska programistyczne do budowy software [C/C++] oraz firmware [HDL].

W ninniejszej części zostanie przedstawione rozumowanie oraz badanie rynku [na rok 2010] mające na celu wybranie najważniejszych elementów w projekcie tj: wstępnej koncepcji oraz wymagań projektowych, jak i kontrolera projektu planowanego jako jeden z układów spośród: FPGA, uP, uC albo DSP wraz z wymaganym dla niego środowiskiem programistycznym.

W prezentacji zostanie przedstawione:

• ogólna [wstępna] koncepcja rozwiązania,
• kryteria wyboru kontrolera,
• podsumowanie wraz krótkimi wnioskami przedstawionego badania rynkowego,
• krótkie przedstawienie wybranego kontrolera,
• wytyczenie działań na następny rok.

Ideą jest stworzenie:

• rozwiązania low-cost,
• mającego różne "popularne" i cyfrowe interfejsy,
• działająceo autonomicznie lub jako karta PCI,
• zawierającego połączenia łączące kontrolery w system wieloprocesorowy.

Karta w zamierzeniu ma stanowić:

• platformę edukacyjno-testową dla rozwoju technik wieloprocesorowych z użyciem FPGA,
• tani prototyp dla przetestowania nigdy dotąd nie testowanych połączeń uP-FPGA-Peryferia, polegających na przejęciu właściwej kontroli wszystkich możliwych peryferiów oraz interfejsów uP przez FPGA [o czym mowa jest dopiero w drugiej części prezentacji],
• możliwie efektywną [a ograniczoną ceną projektu] realizacją algorytmów przetważania video przy możliwie niskim zużyciu mocy.

Firmy oraz rodziny układów, które zostay uwzględnione do badań.

Układy z danych rodzinych zostały poddane tokowi eliminacji poprzez zadane kryterią jakimi są:

• wydajna architektura 32-bitowa [najlepsze byłyby DSP, które niestety najcześciej nie mają wbudowanych sprzętowych kontrolerów popularnych interfejsów],
• darmowe środowisko do budowy projektów.

Z badań wynika, iż istnieją dwie możliwe drogi progamistyczne zadanych kontrolerów:

• środowikso oparte o kompilatory GNU GCC [z ograniczeniami na nieobłsugiwane jak na 2010 architektury],
• środowisko firmy Texas Instruments, pełną licencję którego [ograniczoną do wybranych układów] otrzymuję się wraz wykupieniem programotra XDS100 wartego poniżej 100$.

Płyta powinna być łatwo testowalna i programowalna, stąd kolejnym kryterium jest wybór takiego kontrolera dla którego istnieje tani programatror/debugger/emulator.

Z badań wynika, iż istnieją takie rozwiązania - niestety jednak:

• isnieje problem z dostępnością,
• należy stworzyć je samemu, gdzie dodatkwo nie ma gwarancji, że rozwiązanie zadziała.

Ewenenmentem są wybrane układy firmy Texas Instruemnts, gdzie programator [oparty o USB] XDS100 jest tani, a nawet jego schematy wraz z listą elementów są udostępnione publicznie.

Kolejne kryterium stanowi by wybrany układ kontrolera umożliwiał połączenie dedykowane lub ułatwiające tworzenie systmu wieloporcesorowego.

Takie połączenie umożliwiją prezentowane układy/rodziny kontrolerów i są połączenia operte o interfejsy tj. Ethernet oraz dedykowane [jak Host Port Interface lub Universal Parallel Port].

Kolejnym kryterium [5,6,7] są:

• zasoby,
• bogactwo obsługiwanych peryferiów/interfejsów,
• moc obliczeniowa,

względem ceny [peryferia+wydajność do ceny].

Lista podsumowywująca wyłania kilka możliwych rozwiązań. Kolrami łososiowym, żółtym, zielonym oraz niebieskim wyróżniono rozwiązania z możliwie największą wydajnością i bogactwem interfejsów względem ceny.

Przyjęte kryteria nie wyłoniły jednoznacznego "zwycięzcy" - wymienione rozwiązania plasują się identycznie cenowo jak i wydajnościowo. Za roziwązaniem z użyciem L138 opwiada się jednak doskonale stowrzona do niego dokumentacja wraz ze wsparciem w postaniu forum. Ponadto jest to jedyny na liście uP hybrydowy integrujący w jednym układzie scalonym rdzeń ARM oraz osobny rdzeń DSP połączonych wew. szyną, gdzie DSP działa jako coprocesor.

Z przeprowadzonych badań nad "tanimi" rozwiązanimi dla konotrolera można pokusić się o następujące stwierdzenia [na rok 2010]. Rozwiązanie z użyciem L138 plasuję się w połowie stawki... tam gdzie L138 traci niższą mocą obliczeniową tam nadrabia ciekawymi rozwiąaniami jak liczne "popularne" interfejsy czy dodatkowo zintergrowanym  DSP na pokładzie układu scalonego.

Tak wygląda w postaci blokowej architektura L138.

Tak wyglądają możliwości aplikacyjne z nim związane.

Na najbliższy rok planowane są:

• głębokie zapoznanie się z L138 wraz ze środowiskiem programistycznym,
• badania/studia literaturowe zw. z interfejsami tj. USB czy PCI w celach późniejszych ich optymlanego połącznia pod względem SI na płycie PCB, obsługi oraz implementacji kontrolerów danego interfejsu w FPGA,
• badania/studia literaturowe nad połączeniami wieloporocesorowymi/klastrowymi zarówno od strony sprzętrowej jak i programistycznej.