Hallo, was wären Vorschläge wie man eine schnelle Verbindung zwischen einem ARM9 Chip und einem FPGA herstellen kann? Nur prinzipiell, denn weder der FPGA noch der ARM Chip stehen endgültig fest (vermutlich Virtex-6 und ein AT91SAM9G20). Das schnellste was ich an dem ARM9 entdeckt hab ist eine SPI die per DMA angesteuert werden kann (max Taktfreq. muß ich noch aus dem Datenblättern extrahieren, so 3-5MByte/s sollten drin sein). Sollte das nicht reichen, gibts andere Ideen? Möglichst was straight-forward, keine Hacks. Das wird mein erstes Board mit schneller Digitallogik. Bei einem Board in unserer 4ma gibts eine CPU an der ein DDR-Ram hängt, parallel dazu ein 32Bit Bustreiber der die Leitungen an den FPGA führt. Ich hab nur den Schaltplan gesehen, aber da hat doch nicht jemand den FPGA memory-mapped an das SD-RAM Interface gehängt??!? (Designer nicht mehr erreichbar) Funktionieren tut's offensichtlich aber selber traue ich mich nicht so einen Stunt auf die Platine zu bringen... Was gibts sonst für Möglichkeiten? Gibts ARM9 CPUs die ein schnelles (auch paralleles) Interface mit 10MByte/s oder schneller zu einem FPGA anbieten? Oder muß ich mich irgendwie an den SDRAM oder Flash-Speicherbus hängen? Es gibt CPUs mit schnellen SPIs, ich will nur mal im voraus fragen falls sich heraus stellt dass das nicht reicht. Andere Frage: Oft sieht man ARM9 Boards die (viel) NAND und (ein wenig) XOR Flash haben. Keine Eval-Borad sondern kleine CPU-Module für die Serie. Zu was ist das gut? Zum booten? Geht das nicht oder nur umständlich aus dem NAND-Flash? Beispiel dafür ist: http://microcontrollershop.com/product_info.php?products_id=3774 Viele Grüße,
Hi, Zuerst ist natürlich immer die Frage interessant: Welche Bandbreite brauchst du überhaupt? Dein favourisierter ARM9 besitzt ein externes Speicherinterface: "External Bus Interface: 1" (hab ich von der atmel homepage) Das ist ein paralleler Speicherbus. Wenn du den komplett am FPGA anschließt und du im FPGA einen Speicher beschreibst, dann kannst du auf einfachste Weise auf Register im FPGA schreiben und davon auch lesen. Hier sollten je nach Taktrate, Latency, etc. eine sehr hohe Bandbreite möglich sein. Der Zugriff in C/C++ sieht dann exemplarisch so aus:
1 | int *int_reg; |
2 | |
3 | int_reg = address; // das ist die zu schreibende Adresse |
4 | *int_reg = write_value; // das ist ein Schreibzugriff |
5 | read_value = *int_reg; // das ist ein Lesezugriff |
Ich empfehle dir im Datenblatt alles über das Externe Bus Interface zu lesen, damit du eine Vorstellung davon bekommst. Vg BF
Die Frage ist auch, ob du viele Daten am Stück übertragen willst, oder eher immer kurze (einzelne Worte) von verschiedenen Speicherstellen. Für ersteres wäre ein Straming-Interface sinnvoll, die TI OMAP haben beispielsweise eine Streaming-Port dran. Sehr einfaches FIFO-Interface, schnell und full-duplex. Für zweiteres ist ein paralleles Interface am Speicherbus sinnvoll, du kannst den FPGA dann als Speicher einblenden und wie oben schon beschrieben zugreifen. Lange Datensätze auf einmal gehen dann meist aber eingeschränkt, und direkter Transfer in den RAM geht dann auc nur über die CPU, weil ja beide am gleichen Bus hängen. Was hast du gegen den memory mapped FPGA? Das ist normale Design-Praxis, millionenfach bewährt. Es gibt sogar (DDR)SDRAM Interfaces wo der FPGA einen SDRAM Slave darstellt.
> Was hast du gegen den memory mapped FPGA? Das ist normale Design-Praxis, > millionenfach bewährt. Es gibt sogar (DDR)SDRAM Interfaces wo der FPGA > einen SDRAM Slave darstellt. Mir ist (war) die Vorstellung unheimlich an ein 133MHz-SDRAM-Interface noch was anderes dran zu friemeln und nicht eine Punkt-zu-Punkt Verbindung zum Speicherbautein zu machen. Aber so wie ich das Datenblatt lese teilen sich bei dem ARM9 Chip sämtliche Speicherchips (SDRAM, Flash, SRAM) zumindest die Datenleitungen, so dass das eh keine Punkt-zu-Punkt Verbindung wird. Wie macht man dann die Verteilung und die Terminierung? Serielle Terminierung beim Sender geht ja nur in dem Fall gut dass der einzige Empfänger am Ende der Leitung sitzt, wegen der zurücklaufenden Welle. Macht man dann einen Bus an dem der Reihe nach alle Speicherbausteine (und der FPGA) sitzen? Wie terminiert man dann am Ende? Shunt-Terminierung mit einem R-C? Ein Bus mit allen Bausteinen sicher von der Raumaufteilung schwierig. Kann man kurze T-Stücke machen? (133MHz wären 7ns Periodendauer. Die Lauflänge von 0,7ns auf der Platine sind ca. 11cm bei angenommen c/2) Ich wette da gibts auch Designbeschreibungen als pdfs... ich glaub ich muß noch viel lesen...
Noch eine Frage zu Layout für schnelle Digitallogik: Man sieht auf solchen Boards immer Serpentinen in Datenleitungen, zum Längenausgleich. Ich frage mich wie kritisch das ist. Oben hab ich noch ausgerechnet dass 10cm immerhin die Laufänge von nur 1/10 Periode bei 133MHz sind, da sollte doch +/- 1 cm ggü. der Taktleitung an Längenunterschied gar nicht so kritisch sein?!? http://danstrother.com/2011/01/16/spartan-6-bga-test-board/ (Da sieht man das zischen dem FPGA in der Mitte und dem SDRAM links) Der Aufbau der Serpentinen wundert mich auch. Dadurch dass sie so Eng sind dass der Abstand der benachbarten Leitungen nicht größer ist als die Leiterbreite selber muß das doch koppeln wie verrückt. Komme aus der HF-Ecke und hab so eine Serpentine (noch) nicht selber simuliert, aber das sieht mir eher wie ein Hochdrequenz-Filter aus als wie ein Bauteil das einen glatten Frequenzgang hat. Vielen Dank für eure Tipps, BTW.
Bei 133MHz ist das noch relativ unkritisch. Aber die aktuellen FPGAs haben DDR2 oder DDR3 RAM Interfaces, da wird allein beim Spartan 6 schon mit 400MHz DDR gefahren. Ein Bit hat dann noch eine Länge von 1,25ns, realistisch unter 1ns da du ja endliche Anstiegstzeiten hast. Da müssen die Längen schon angeglichen sein. Sowas nimmt dir aber eigentlich ein gescheites Design-Tool( zumindest teilweise) ab. Schau doch wegen der Terminierung mal in Demoboard Designs. Stubs sind immer schlecht und tunlichst zu vermeiden.
Serpentinen und Terminierung auf die harte Tour via Dioden findest du bei PCI. Da gibts sicherlich genug zu lesen. Die Serpentine ist in erster Linie eine Verzögerungsleitung. In zweiter Linie auf höherer Frequenz ein Tiefpaß.
asd schrieb: > Andere Frage: Oft sieht man ARM9 Boards die (viel) NAND und (ein wenig) > XOR Flash haben. Keine Eval-Borad sondern kleine CPU-Module für die > Serie. Zu was ist das gut? Zum booten? Geht das nicht oder nur > umständlich aus dem NAND-Flash? Das hast du korrekt erkannt. Booten von NAND ist komplexer als von NOR. Wenn ein Prozessor von NAND booten kann ist immer ein kleines Programm im ROM des Prozessors aktiv welches ein paar wenige k (2k/4k) des NAND in ein internes SRAM kopiert und dann dort hin hüpft. Diese 4k müssen dann Software enthalten die das RAM initialisiert, weitere Daten aus dem NAND kopiert und so das System Stück für Stück startet. Beim Booten von NOR steht da ab Adresse 0 Software die sofort ausgeführt werden kann. NOR ist etwas konservativer da weniger Software mitspielt die man nicht selbst im Griff hat (ROM im Prozessor). Das ist aber alles auch noch 100% SoC abhängig. Ein Atmel mag das wieder völlig anders machen als ein Freescale oder ein TI. Die heutigen SoCs können auch oftmals von weiteren Medien wie etwas I2C/SPI EEPROMs, SD-Karten oder über USB/UART booten. Alles eine Frage des ROMs im Prozessor und der Beschaltung der Configpins. Matthias
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.