Hallo liebes Forum, ich moechte gerne ein Projekt mit einem mega128 starten. Einige Berechnungen wuerde ich aber gerne in einen co-processor auslagern. Das ganze soll dann auf einem FPGA laufen. Mich interessieren die Interfacemoeglichkeiten. Zum einen gibt es die ports und das SPI. Liesse sich mit auch der RAM des AVR mit einem co-prozessor teilen?
Bastler schrieb: > Liesse sich mit auch der RAM des AVR mit einem co-prozessor teilen? Welches RAM? Das im AVR eingebaute? Da kommst du nicht ran... Mein Standpunkt: Bevor du einen billigen 8-Bit-uC mit einem externen FPGA "aufbohrst" kauf besser einen ARM. Der hat Leistung satt und kostet nicht mehr als der AVR alleine...
Lothar Miller schrieb: > Welches RAM? Das im AVR eingebaute? Da kommst du nicht ran... Warum nicht? FPGA fragt Adresse an und der AVR liefert den Wert. Ist natürlich nicht besonders schnell, aber grundsätzlich geht es schon. Fraglich bleibt trotzdem ob sich das lohnt. Ein Softcore mit ähnlicher Leistung ist warscheinlich mit unter 1000 Lut/FF möglich.
hjk schrieb: > Warum nicht? > FPGA fragt Adresse an und der AVR liefert den Wert. Das ist nicht das, was ich als "Zugriff aufs RAM" bezeichnen würde. > Ist natürlich nicht besonders schnell, aber grundsätzlich geht es schon. Ich habe gemeint, per DMA und oder Cycle-Stealing mit halbwegs vertretbarer Geschwindigkeit von aussen direkt ans RAM zu kommen... Man könnte natürlich das RAM des FPGAs als "externes asynchrones RAM" an den AD-Bus (Ports A, C und G) des AVR anschliessen, dann hätte der direkten Zugriff auf das FPGA. > Ein Softcore mit ähnlicher Leistung ist warscheinlich mit unter 1000 > Lut/FF möglich. Und trotzdem garantiert teurer als ein ARM.
Ich wuerde mit so einem Quatsch gar nicht anfangen, und den Vorschlag von lkmiller nehmen. Ein ARM Prozessor und eventl. ein FPGA am Memory Interface des Prozessors. hosentraeger
Lothar Miller schrieb: > Und trotzdem garantiert teurer als ein ARM. Das bezweifle ich nicht. Eher ist es doch so das es, gerade bei Hobbyprojekten wo es nicht auf cent/stück ankommt, genug Platz im FPGA für den Softcore gibt, ein Board mit µC UND FPGA zu realisieren aber deutlich mehr Aufwand Bedarf. Außer der µC reicht sowieso alleine, dann wird man sich die FPGA Entwicklung wohl eh nicht antun wollen.
hjk schrieb: > Eher ist es doch so das es, gerade bei Hobbyprojekten wo es nicht auf > cent/stück ankommt, genug Platz im FPGA für den Softcore gibt, ein Board > mit µC UND FPGA zu realisieren aber deutlich mehr Aufwand Bedarf. Ganz genau. Es gab mal das FPSLIC, das war µC UND FPGA, dazu gab es sogar eine eigene IDE. Die FPGAs sind mittlerweile jedoch so gross das man ohne weiteres einen µC als softcore nehmen kann. (Ich vermute das ist der Grund warum das FPSLIC nicht weiter etnwicklt wurde.) Ich habe mal mit dem 8051 experimentiert. Der 8051 kennt externen und internen RAM, wobei sich der externe wunderbar mit einem co-processor teilen laesst. Idelaerweise uebertraegt man eine ganze reihe an bytes zwischen externem RAM und co-prozessor und macht dazu einen einzelnen handshake ueber die ports. So braucht man nicht fuer jedes uebtertragene byte einen eigenen handshake. Beim mega128 bin ich nicht so sicher wie gut sowas geht oder ob etwas anderes mehr sinn macht.
Bastler schrieb: > Beim mega128 bin ich nicht so sicher wie gut sowas geht oder ob etwas > anderes mehr sinn macht. Du kannst das FPGA wie einen externen RAM-Baustein an den ATmega128 anschließen, die Daten dort speichern, und über einen Interrupt signalisieren, wenn die Berechung fertig ist...
Ich hab sowas gemacht, und zwar deswegen, weil der AVR mit einer SD dann bequem das FPGA booten kann. Im FPGA läuft dann ein Microblaze, der dann wiederum den AVR als eine Art IO-Expander für die SD und AD-Wandler nutzt. Als Interface werden die Pins für das Slave-parallel-IF des FPGAs und der gemuxte 8Bit AD-Bus des AVRs genommen (+ALE/RD/WR). Im (gebooteten) FPGA hängt dann daran ein Dual-Port-RAM, dass vom Microblaze über verschiedene IO-Adressen angesprochen werden kann. Eine bildet das uart-lite-Verhalten nach, d.h. der AVR macht RS232-IO. Hat den Vorteil, dass AVR und FPGA-Ausgaben über dieselbe Schnittstelle laufen. Dann gibts noch ein Sektor-read/write-IF (ähnlich IDE), worüber das MB-Linux dann sein SD-IO abwickelt. Die AD-Werte stehen auch drin, eine Doorbell-Interrupt in beide Richtungen gibts auch. Der Bootvorgang sieht so aus, dass der AVR via FAT-FS auf der SD-Karte das "neueste" FPGA-Image findet (man kann per RS232 manuell auch was anderes wählen) und damit das FPGA konfiguriert. Das dann startende MB-Bios fordert vom AVR den im selben Ordner liegenden Linux-Kernel+Initrd an, der AVR hangelt sich dabei (wie beim Bitstream) noch selbst durch die FAT. Wenn das Linux gestartet ist, wird für die SD-Karte nur noch das Sektor-IF benutzt, der Linuxtreiber dazu ist recht trivial, er muss ja nur die Sektornummer weiterreichen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.