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.

AttachmentWielkość
Multi-Computing Multi-Computing - Part 1.pdf3.72 MB