HighSpeed OptoBus (für FPGA-Lab)

[Lennart]

Da ja offensichtlich einige an verschiedenen FPGA Projekten werkeln, wollte ich mal meinen 'Senf' in den Raum werfen

Da in den meisten Fällen ja größere Datenmengen zu transportieren sind (ich denke da z.B. an den Logic Analyzer) besteht auch bedarf an einem schnellen Interface richtung PC und den (hoffentlich) mehreren Modulen.

FPGA-IFP
Als Bindeglied PC<->FPGABus dachte ich an einen ATmega mit USB-Port (FTDI). Der Speicher sollte als kleiner Puffer ausreichen und zum übertragen der Daten sollte er schnell genug sein.

FPGABus
Wie macht man das am besten? Meine erste überlegung währe ein SPI-ähnliches Interface mit 2 Kanälen. Einmal IFP(Master)->Bus und einmal BUS->IFP(Slave). Ein Port ist im ATmega vorhanden den zweiten müßte man per Software einbinden. Fragt sich nur ob Software-SPI noch schnell genug ist.

Wie gesagt sind das nur ein paar Gedanken die mir durch den Kopf gehen. Ist auch schon spät (bzw. früh) also bitte nicht gleich schlachten

gruß .. Lennart

[Lennart]

Ich hab da mal auf die schnelle was zusammen gepinselt .. so etwa würde ich mir einen SPI-OptoBus vorstellen .. die 6N137 können laut datenblatt 10Mbs .. auf der kurzen distanz sollte denk ich flachbandkabel reichen (oder?)

PS: an den SPI gehört natürlich noch bisl logic um ihn auch auf der platine für andere bausteine nutzen zu können
PPS: es gibt sicher auch verfügbare quad-optis in smd bauform dann verbrät das ganze nich so viel platz
PPPS: ups der eine opti ist natürlich verkehrt herum im schaltplan .. sry

[joedawson]

Howdy!

Erst mal ein (ganz kleines) bisschen Haarspalterei: Das was du da vorschlägst, wäre ja eine Vollduplex-Punkt-zu-Punkt-Verbindung - also kein Bus
Aber jetzt zur eigentlichen Thematik: warum denn immer dieser furchtbare ATmega? Ja, ich mag keine 8bitter und auf ATmegas pflege ich mittlerweile einen sprichwörtlichen Hass, aber ich bin einfach der Meinung dass man das mit nem kleinen ARM deutlich eleganter erschlagen kann.
Beispiel: in diesem Fall z.b. ein Luminary Micro LM3S3748 anstatt ATmega 644 + FTDI-Knubbel. Zumindest laut Farnell-Vergleich a) billiger b) deutlich mächtiger c) hätte zwei SSIs über die man den FPGA sehr performant ankoppeln könnte.

Gedanken dazu?
Greetz Joe

[Lennart]

erstmal ist es schön, das sich überhaupt wer beteiligt

Erst mal ein (ganz kleines) bisschen Haarspalterei: Das was du da vorschlägst, wäre ja eine Vollduplex-Punkt-zu-Punkt-Verbindung - also kein Bus

stimmt schon .. dann ist der OptoBus allerdings auch keiner, da er eine ähnliche punt-zu-punkt verbindung zu den benachbarten modulen darstellt

Aber jetzt zur eigentlichen Thematik: warum denn immer dieser furchtbare ATmega? Ja, ich mag keine 8bitter und auf ATmegas pflege ich mittlerweile einen sprichwörtlichen Hass, aber ich bin einfach der Meinung dass man das mit nem kleinen ARM deutlich eleganter erschlagen kann.
Beispiel: in diesem Fall z.b. ein Luminary Micro LM3S3748 anstatt ATmega 644 + FTDI-Knubbel. Zumindest laut Farnell-Vergleich a) billiger b) deutlich mächtiger c) hätte zwei SSIs über die man den FPGA sehr performant ankoppeln könnte

sicherlich sind die ARMs deutlich leistungsfähiger, aber was nutzt mir nen zig gigaherz programmloader fürs FPGA? denn zu mehr ist er ja eigendlich nicht gedacht (oder versteh ich da was falsch?) .. was mich an den meisten ARMs noch ein wenig abschreckt ist die gehäuse größe (wobei ich mich bisher nur mit den sam7/sam9 von atmel beschäfftigt habe) .. warum ich atmel bevorzuge? weil die super erhältlich sind. ich hab nicht wirklich lust in einer apotheke wie farnell/digikey einzukaufen

als kompromiß dürfte nen sam7 (AT91SAM7S32..AT91SAM7S512 64pin LQFP/QFN) doch sicher reichen .. der is relatiev flott, hat auch einiges an schnittstellen und ist zudem auch gut zu bekommen

wobei es mir eher um die kommunikation der einzelnen (FPGA-)Einschübe untereinander als den µC auf einem Einschub geht .. der ATmega644 war nur nen beispiel da er auf der original schaltung verbaut ist und er code kompatiebel zu den bisherigen modulen ist .. ein neuer µC bedeutet man müßte viele codeabschnitte komplett neu schreiben

soviel erstmal dazu .. ich hoffe ja das sich noch einige mehr beteiligen, evtl. bekommen wir das ja noch hin womit (nahezu) alle bedürfnisse befriedigt werden

[joedawson]

erstmal ist es schön, das sich überhaupt wer beteiligt

Erst mal ein (ganz kleines) bisschen Haarspalterei: Das was du da vorschlägst, wäre ja eine Vollduplex-Punkt-zu-Punkt-Verbindung - also kein Bus

stimmt schon .. dann ist der OptoBus allerdings auch keiner, da er eine ähnliche punt-zu-punkt verbindung zu den benachbarten modulen darstellt

Hast du auch recht gegenseitiges Haareanspalten ist doch was feines!

erstmal ist es schön, das sich überhaupt wer beteiligt
als kompromiß dürfte nen sam7 (AT91SAM7S32..AT91SAM7S512 64pin LQFP/QFN) doch sicher reichen .. der is relatiev flott, hat auch einiges an schnittstellen und ist zudem auch gut zu bekommen

wobei es mir eher um die kommunikation der einzelnen (FPGA-)Einschübe untereinander als den µC auf einem Einschub geht .. der ATmega644 war nur nen beispiel da er auf der original schaltung verbaut ist und er code kompatiebel zu den bisherigen modulen ist .. ein neuer µC bedeutet man müßte viele codeabschnitte komplett neu schreiben(nahezu) alle bedürfnisse befriedigt werden

Ich hab auch nix gegen Atmel, vor mir lag nur gerade ein Luminary-Kit. Der Grundgedanke war einfach: warum zwei ICs, wenns mit einem auch und sogar besser geht. Mit nem einigermassen leistungsstarken Prozessor liessen sich ja auch noch ein paar Kleinigkeiten bewerkstelligen:
- aufheben der noch bestehenden Einschränkungen beim FAT auf der SD-Karte
- vielleicht bereitstellen eines Lese/Schreibweges eben auf diese ohne zusätzliche Hardware
- und wenn er anständig getaktet ist kann man natürlich auch die Kommunikationsraten nach oben treiben

Greetz Joe

[VGOE]

Aus meiner Sicht ist eine Ethernetschnittstelle wesentlich interessanter. Die Schnittstelle zum FPGA ist m.E. schnell genug. Für die FPGA - FPGA Kommunikation würde ich sowieso in Abhängigkeit der Ressourcen eine Projekt spezifische Schnittstelle aufbauen. Ziel ist hier möglichst wenig FPGA Ressourcen zu verbraten. Die SD-Karte ist mir 32 Einträgen auch ausreichend, besser ist hier eine SD_Karten Simulation, bzw. ich nutze sowieso lieber die JTAG Schnittstelle.
Auf längere Sicht halte ich ein paar Erweiterungsprojekte für sinnvoll, im Gegensatz zu einem Hardware-Zoo der Basisversionen.
CU
Volker