mikrocontroller.net

Forum: FPGA, VHDL & Co. USB Analyzer


Autor: Karsten Richter (Firma: Student) (norte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

habe vor als Diplomarbeit einen USB Analyzer/Sniffer in einem FPGA zu 
realisieren.
Da ich mit VHDL leider noch blutig bin, ist meine Frage an euch 
Fachleuten: Ist es ein realistisches Ziel in sechs Monaten eine solche 
Aufgabenstellung zu stämmen.....??

Ziel ist hauptsächlich die Implementierung. Evtl. erst mal auf einem 
Entwicklungsboard.

Danke für eure Hilfe
Norte

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karsten Richter schrieb:
> habe vor als Diplomarbeit einen USB Analyzer/Sniffer in einem FPGA zu
> realisieren.
Welchen USB? 1.0, 1.1, 2.0, 3.0...?
Kennst du dich mit USB (auf unterster Ebene) schon gut aus?
Wie sollen die abgehörten Daten weiterverarbeitet werden?

Karsten Richter schrieb:
> Ist es ein realistisches Ziel in sechs Monaten eine solche
> Aufgabenstellung zu stämmen.....??
Wenn du dich ins Zeug kniest, die Einarbeit vorneweg schon mal machst, 
gute Messgeräte hast (und die auch bedienen kannst), dich auf die 
"handhabbaren" USB-Protokolle (USB 1.x) beschränkst und bei der Arbeit 
nicht lockerlässt ... dann ja.

Mit USB 2.0 wird das Ganze allein mit einem FPGA ohne externe Bausteine 
dann schon sehr sportlich...

Autor: Karsten Richter (Firma: Student) (norte)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Lothar,

sollte schon 2.0 sein. Ich kenne mich auf unterster Ebene nur mäßig aus.
Sollte natürlich nicht ohne externe Bausteine stattfinden. Hab' mir das 
etwa so wie in dem Bild im Anhang vorgestellt.

> Wenn du dich ins Zeug kniest, die Einarbeit vorneweg schon mal machst,
> gute Messgeräte hast (und die auch bedienen kannst), dich auf die
> "handhabbaren" USB-Protokolle (USB 1.x) beschränkst und bei der Arbeit
> nicht lockerlässt ... dann ja.

Das ist ne Ansage.... Eine willige Sportskanone bin ich wenigstens schon 
mal. Bin aber unsicher ob das realistisch ist.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karsten Richter schrieb:
> Hab' mir das etwa so wie in dem Bild im Anhang vorgestellt.
Glaube ich nicht, dass du das incl. Doku in der Zeit schaffst...

Du hast das Design bis auf den m.E. kritischsten Punkt schön 
ausgearbeitet... Der USB-Transceiver: welchen stellst du dir da vor?
Immerhin sollte der ja passiv am Bus sein und nicht mit ins Protokoll 
reinfunken. Denn die kleinen blauen Pfeile sind ja nicht in der 
Wirklichkeit da. Der USB ist bidirektional...

Stefan B. schrieb:
> Gibt es schon
Ein DejaVue...  :-/

Ich korrigiere mich:
>> Du hast das Design bis auf den m.E. kritischsten Punkt schön
>> abgekupfert...

Zitat:
The various partners are: 
- EIF  (Freiburg)  and  EIVd    (Yverdon)  for  the man-machine interface development.
- HEVs  (Sion)  for  the  study and  the writing of USB driver and the dynamic linked library (DLL).
- EIG (Geneva) for the design in VHDL of the FPGA and processor firmware.
Drei beteiligte Institute? Ich habe den Aufwand wohl zu niedrig 
eingeschätzt...

Autor: Karsten Richter (Firma: Student) (norte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig Stefan, das Bild gibt es schon. Es geht lediglich um die FPGA 
Implementierung.

Ich dachte eigentlich an einen Cypress TX2 oder ähnliches. Der 
Transceiver sollte sich schon auf dem Entwicklungsboard befinden. 
Applikation auf dem Analyse PC und Hardware entwurf sollte nicht zur 
Aufgabe gehören. Lediglich die Implementierung.

> Immerhin sollte der ja passiv am Bus sein und nicht mit ins Protokoll
> reinfunken.

Hatte schwer auf hochohmiges mithören gesetzt.

> Der USB ist bidirektional...

Die Richtung kann man doch bestimmt aus dem Protokoll auslesen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karsten Richter schrieb:
>> Immerhin sollte der ja passiv am Bus sein und nicht mit ins Protokoll
>> reinfunken.
> Hatte schwer auf hochohmiges mithören gesetzt.
Das ist aber nicht das primäre Ziel von USB-Transceiver-Herstellern...

>> Der USB ist bidirektional...
> Die Richtung kann man doch bestimmt aus dem Protokoll auslesen.
Das dürfte dann ein kleineres Problem darstellen.
Aber vorher mußt du erst noch diesen "Passiv-Transceiver" finden...

Autor: Karsten Richter (Firma: Student) (norte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich seh schon, ich seh schon.
Das Blut spritzt bei mir....

Aber danke für den support und frohes arbeiten... !!


Gruß

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

nur mal ein einwurf, wobei vieleicht liege ich gerade auch völlig falsch 
und übersehe etwas wesentliches.

Solange man bei USB 2.0 Full Speed (=12Mb/s) bleibt sollte das reine 
Mithören doch nicht so das Problem sein...

ICh meine, wenn man bedenkt das ein "einfachst LA" wie der USBeeAX (pro) 
problemlos USB 2,0 mithören und die kommunikation darstellen kann, dann 
sollte das auch mit einem FPGA möglich sein... Zumindest von den 
elektrischen Specs.
Der UsbeeAX Pro hat bis auf den hier nicht relevanten Analogteil 
praktisch dieselbe Hardware wie der Salea lowCost LA, den man wiederrum 
für deutlich unter 20 Euro nachbauen kann. Der basiert rein auf einem 
Bustreiber (74erLogikreihe!) hinter dem ein Cypress µC mit 8051er Kern 
sitzt. Der USB Teil dieser CPU hat mit dem eigendlichen USB Mithören ja 
technisch nichts zu tun und wird rein zum Datentransport auf einen (auch 
anderen) PC verwendet. Die ganze Protokolldekodierung wird dabei 
natürlich im PC gemacht. dafür ist der µC zu schwach. Aber die 
Elektrische kontaktierung ist ja im prinzip zu deiner notwendigen 
identisch (wurde z.B. in diesem Thread behandelt: 
Beitrag "Logikanalzyer mit CY7C68013A", weit unten!)

Daher: elektrisch sehe ich jetzt keine großen Schwierigkeiten. Ich würde 
das jetzt evtl so angehen das ich erst einmal den reinen Datenstrom so 
aufbereite das ich den verwende kann und dann als zweiten funktionsblock 
diesen analysiere (denke das soll ja im FPGA und nicht im PC geschehen. 
Die Analyse könnte doch auch in einem mit Softcore? implementierter CPU 
laufen auf der dann ein Prog läuft oder - aber da bin ich überfragt, 
VHDL&FPGA ist leider bei mir (noch) nur in kleinsten Ansätzen ein Thema, 
es ging mir jtzt im Beitrag nur um die elektrischen Eigenschaften.)

Und für den Transfer der Daten nehme man dann einen üblichen USB 
Transceiver der Bestimmungsgemäß genutzt wird...

Ich würde die Schwierigkeiten jetzt selber auch eher erst einmal im 
einstieg in die VHDL Programmierung eines FPGA sehen als in der 
Umsetzung der Signalanalyse.

Aber wie gesagt, vieleicht übersehe ich da was?

Gruß
Carsten

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Solange man bei USB 2.0 Full Speed (=12Mb/s) bleibt
Full Speed gabs schon beim USB 1.0...
Wenn zu mir einer USB 2.0 sagt, dann bedeutet das 480MBit/s.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Lothar Miller schrieb:
> Carsten Sch. schrieb:
>> Solange man bei USB 2.0 Full Speed (=12Mb/s) bleibt
> Full Speed gabs schon beim USB 1.0...
> Wenn zu mir einer USB 2.0 sagt, dann bedeutet das 480MBit/s.

Dann verallgemeinerst du das aber stark...

Fakt ist natürlich das die Möglichkeit der Betriebsart HS die 
Bekannteste Eigenschaft des USB 2.0 standart ist, die bei 1.0 nicht 
vorhanden ist.
Aber es ist bei weitem nicht das einzigste was anders ist. Ein Gerät 
kann auch 100% USB 2.0 entsprechen, aber über 1.1 hinausgehen, ohne den 
High Speed Modus überhaupt nutzen zu müssen.
Beispiele für die unterscheidung sind unter einigem anderen die 
Microframes die mit USB 2.0 neu eingeführt wurden, oder als absolut 
triviales Beispiel die LEDs in Hubs (in der Funktion als Port 
Indikatoren) deren funktion nun verbindlich festgelegt wurde. Aber 
immerhin ist dadurch ein veränderter Aufbau des jeweiligen Descriptors 
notwendig geworden...

Will man natürlich High Speed auch richtig analysieren wird es einiges 
komplizierter. Allerding eher auf der Signalverarbeitenden Seite. Die 
reine Detektion der Bussignale ist zwar kritischer - aber immer noch 
bequem machbar. ISt halt etwas HF gerechter Schaltungsaufbau gefragt.

Allerdings etwas wo dann auch die notwendigkeit eines guten FPGAs zu 
tragen kommt. Sonst würde ja ein lahmer 8051 ausreichen wie das Salea / 
USBee beispiel zeigt...

Gruß
Carsten

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.