Hallo zusammen,
ich habe auf einem Intel MAX10 einen NIOS2e Prozessor (32Kb RAM) mit
einem selbst geschriebenen Avalon Memory Mapped Slave (CRC in Hardware).
Ich habe nun die Performance mir angeschaut und brauche Hilfe.
Ich schreibe in der Endlosschleife
mit ldw, Modi und stw auf den Avalon MM slave. Das klappt auch soweit
nur zwischen zwei Schreibvorgängen (write signal) liegen 33 clock
Zyklen.
Ich dachte zuerst es liegt am NIOS2e aber mit einem NIOS2f und jeweils
1Kb Cache habe ich das gleiche verhalten.
Woher kommt diese Latenz?
Gibt es einen Weg diese zu minimieren?
Vielen Dank.
avalonMax1000 schrieb:> Hallo zusammen,>> ich habe auf einem Intel MAX10 einen NIOS2e Prozessor (32Kb RAM) mit> einem selbst geschriebenen Avalon Memory Mapped Slave (CRC in Hardware).> Ich habe nun die Performance mir angeschaut und brauche Hilfe.>> Gibt es einen Weg diese zu minimieren?
Mehrere, beispielsweise den Takt reduzieren, oder alles an einem Takt zu
hängen, das erspart die synchronizer. Und nicht das man Genrieren durch
uninspiriertes drauflosclicken mehr Waitsates als nötig configuriert
worden. Avalon Streaming IF sollte man auch genügend Aufmerksamkeit
widmen:
https://www.intel.com/content/www/us/en/programmable/documentation/nik1412467993397.html#nik1412467963376
Ich meine mich zu erinnern dass das auch mit der Konfiguration des NIOS
zu tun hat, wie er die Tasks abarbeitet. Das Streaming IF an sich ist
schnell und latenzarm. Was regelmäßig zum Warten führt, sind
DDR-Zugriffe aller Art. Das lässt sich nur durch intelligente
FIFO-Steuerung lösen.
Danke für den Input.
Ich stelle meine Frage nochmals spezieller:
Wenn ich einen eigenen Avalon SPI Slave mache, braucht dann NIOS2 immer
>20 Zyklen für den Registerzugriff?
Das Streaming-IF hilft ja bei einem klassischen Register ja nichts, da
bidirektional.
avalonMax1000 schrieb:> Danke für den Input.> Ich stelle meine Frage nochmals spezieller:>> Wenn ich einen eigenen Avalon SPI Slave mache, braucht dann NIOS2 immer>>20 Zyklen für den Registerzugriff?
Nein.
Ich habe mit dem Signal Tap logic mir die Avalon Signale angeschaut.
Wahrscheinlich komme ich nicht drum herum, einen Avalon Master für eine
Art DMA zu implementieren um effizienter zu werden.
avalonMax1000 schrieb:> Ich habe mit dem Signal Tap logic mir die Avalon Signale angeschaut.> Wahrscheinlich komme ich nicht drum herum, einen Avalon Master für eine> Art DMA zu implementieren um effizienter zu werden.
Nein, bei 22 Takten gibt es geeignetere Lösungsansätze als DMA-Master.
Und Streaming ist eine Form des DMA, das hast Du ja bereits als "nicht
hilfreich" abgekanzelt.
@ avalonMax1000
Folgendes Set-Up: Avalon-MM-Slave Komponente mit internem Registersatz.
Der Inhalt von Register[0] wird über ein UND-Gatter auf einen Nios2
externen Testpin geführt. Anschließend beschreibe ich das Register
abwechselnd mit 0x00000000 und 0xFFFFFFFF ...
Komme so auf eine Registerzugriffszeit von 40ns, bzw. zwei
Prozessortakte ...
@Ben
War das ein NIOS2 f oder e?
Ich habe den Code beim NIOS 2e aus dem externen SD-RAM laufen lassen,
wobei dieser CAS 3 ist; folglich drei Waitstates.
Einen Cache kann ich nicht verwenden, weil ich die Lizenz für den NIOS2
nicht habe, daher geht leider nur ohne Cache.
Der Cache würde die Performance sicherlich erhöhen.
Inzwischen habe ich eine akzeptable Lösung gefunden; ich habe hole die
Daten per Avalon in ein FIFO und in ein weiteres Fifo die empfangenen
Daten der SPI Schnittstelle. Wenn die SPI Transaktion dann fertig ist,
schreibe ich per Avalon-Master die Daten wieder in das SD-RAM.
Hiermit habe ich nur noch Waitstates und kann BURST verwenden.
Trotzdem würde ich verstehen, wieso es so viele Takte für die genannten
Assembler Befehle sind.
@avalonMax1000
Das war tatsächlich ein Nios2 (f). Ich hab es gerade noch einmal mit
einem Nios2 (e) aufgesetzt und den oben erwähnten Test in Assembler
implementiert:
Ein Registerzugriff kommt dann auf 6 Prozessortakte + zwei Takte
Verzögerung durch den Avalon-Bus selbst.
Das passt, bedenkt man, dass der Nios2 (e) keine Instruktionspipeline
besitzt und somit für einen Befehl sechs Takte benötigt (Instruction
fetch, Instruction Decode, Execute, ... ,siehe Handbuch).
@Ben
Danke für die Information. Ich hatte total verdrängt, dass der NIOS2 (e)
auch eine sechsstufige Pipeline hat. Wahrscheinlich muss ich mir doch
mal eine NIOS2 (f) Lizenz leisten.
@avalonMax1000
der Nios2 (e) besitzt 'keine' Instruktionspipeline. Deshalb braucht er
ja in Summe sechs Takte um einen Befehl abzuarbeiten ...
Setzt du den Nios2 kommerziell ein?
Zur Ehrenrettung muss man an dieser Stelle sagen, dass der Nios2 (e) vor
dem Hintergrund einer minimalen Resourcennutzung entwickelt wurde, was
summa summarum dazu führt, dass die Performance entsprechend gering
ausfällt.
Nichtsdestotrotz habe ich den (e)-Core bereits in einer Vielzahl von
Anwendungen implementiert, wo es darum ging eine
"konfigurierbare/flexible State-Machine" zu haben, die mit wenig
Resourcen auskommt. Die Ausführungsgeschwindigkeit war hier sekundär.
Trotzallem ist der Einwurf von 'Schiffe Versenken' richtig. Es gibt
kostenfreie Alternativen a la Gaislers LEON2/3. Diese Cores gehen aber
in die Richtung des Nios2 (f) Cores ...
Eine eigene Frage?
Dieser Thread ist über 6 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
