Hallo an Alle, ich versuche gerade zwei Microblazes per FSL zu verbinden und eine Kommunikation zu realisieren. Die Kommunikation funktioniert auch schon in beide Richtungen, jedoch benötigt der Microblaze 20 Takte für einen "putfslx(val, MBXE_FSL, FSL_NONBLOCKING)" - Befehl. Laut Datenblatt (Microblaze Processor Reference Guide) soll der nicht-blockierende Befehl aber in einem Takt möglich sein. Ich habe verschiedenen Einstellungen am FSL Bus vorgenommen, jedoch ohne jegliche Veränderung. Momentan arbeite ich mit folgenden Einstellungen am FSL Bus: C_EXT_RESET_HIGH = 1 C_ASYNC_CLKS = 0 C_IMPL_STYLE = 0 C_USE_CONTROL = 0 C_FSL_DEPTH = 4 Ich benutze das Xilinx EDK 11.3 und das Spartan 3A DSP 1800 Board. Hat jemand eine Idee, wie diese 20 Takte zustande kommen, bzw. hat jemand gleiche oder andere Erfahrungen gemacht? Wenn der FSL wirklich 20 Takte benötigt, dann ist daran doch nichts mehr "Fast" und es macht wirklich nur Sinn einen Coprocessor per FSL zu Verwenden, wenn dieser große Aufgaben lösen soll und wenig Parameter braucht. Zusätzlich würde mich interessieren, wie ich einen eigenen IP Core entwickel, der an mehr als einem Microblaze per FSL angeschlossen werden kann. Der "Create and Import Peripheral Wizard" unterstützt nur einen Input FSL und einen Output FSL, aber leider nicht mehrere der gleichen Sorte. Hat jemand eine Idee, wie man das hinbekommen kann? Wenn es nur die Möglichkeit gibt, sich einen IP Core mit einem Input und einem Output FSL zu generieren und man dann per Hand in den VHDL und MPD Dateien rumbasteln muss, wäre es schön zu wissen, wie man da am besten vorgeht, und was genau man anpassen muss... Gruß, ChrisB
bist du sicher das BEFEHL selber 20 zuklen braucht? xilinx treiber haben overhead eigene fsl IP sind einfach, aber muss manchmal ohne wizard per hand machen Antti
Ja der eigentliche nput Befehlt benötigt 20 Takte. Ich habe mir angeguckt, was der Compiler auf dem Funktionsaufruf putfslx() (was eigentlich nur ein Makro für eine Assambleranweisung ist) gemacht wird. Es ist wirklich der reine nput-Befehl. Wie bekomme ich es denn hin, dass ich einen IP Core im EDK habe, welcher mehrere FSL Busse zur verfügung stellt, an die ich per Drag und Drop einen oder mehrere Microblazes hängen kann? Eine andere Frage zum eigenem IP Core: Kann ich für meinen IP Core auch eine "Konfigurationsoberfläche" erstellen, wie es sie für die Xilinx IP Cores gibt, um dann Parameter meines IP Cores anzupassen? Gruß, ChrisB
siehe die MPD files an konfiguration eigener ip cores is moglich da gibt es parameter die man spater im gui einstellen kann Antti
ChrisB schrieb: > Wie bekomme ich es denn hin, dass ich einen IP Core im EDK habe, welcher > mehrere FSL Busse zur verfügung stellt, an die ich per Drag und Drop > einen oder mehrere Microblazes hängen kann? Du mußt das Konfigurationsfile (leider) per Hand anpassen für diesen Zweck. Schau mal in die Konfigfile zum MicroBlaze, oder vieleicht hilft dir auch das hier weiter: http://forums.xilinx.com/xlnx/board/message?board.id=EMBEDDED&thread.id=2086 > Ja der eigentliche nput Befehlt benötigt 20 Takte. Wie kommst du zu dieser Messung?
Also die Zeitmessung mache ich, indem ich in einer Schleife zwei mal den Timerwert (der mit dem gleichen Takt läuft wie der Microblaze) auslese und die Differenz bilde. Daraus ergibt sich dann eine Art Offset, die ich abziehe, sobald ich etwas zwischen die beiden Timer-Auslesen-Stellen schreibe. In meinem Fall ist das halt der nput-Befehl, und sonst nichts. Die Differenz bei jedem Durchlauf wird denn mit einem min und einem max Wert vergliegen und dieser ggf. überschrieben, so dass ich am Ende die minimale und maximale Anzahl an Takten habe. Damit auch der I-Cache keine Rolle mehr spielt zähle ich in der Schleife eine Variable hoch, und erst wenn die Variable 100 überschreitet lasse ich meine min-max Auswertung starten. So kann ich sicher sein, dass auch alle Befehle im I-Cache stehen. Für den min und den max Wert ergeben sich bei mir immer genau 20 Takte (Offset schon abgezogen). Bei einem nop ist es nur einer.
Wieviele Pipelinestufen hat dein Prozessor ?
Mark schrieb:
> Wieviele Pipelinestufen hat dein Prozessor ?
3 bis 5.
Das Problem kann hier wirklich eine ungünstige Pipelineausnutzung sein,
führe doch einfach mal 100 puts aus (nacheinander schreiben ohne
Schleife) und schau dir vorallem mal das ASM Listing an!
Zudem können Pipelinekonflikte die eigentliche Taktzahl erhöhen. Ich hatte das gleiche 'Problem' mal auf einer NiosII Platform.
Also im asm ist momentan wirklich nur der nput-Befehl zwischen meiner Zeitmessung. Ich hönnte nochmal versuchen mehrere nputs direkt hintereinander auszuführen und dann die mittlere Zeit berechnen, die ein Befehl benötigt. Ich vermute jedoch, dass auch dort die 20 Takte rauskommen werden. Hat denn jemand eine ähnliche Messung gemacht, mit der man mein Ergebnis Bestätigen oder Widerlegen kann? Mich würde interessieren auf welche Werte andere Leute kommen. Vielleicht geht ja auch wirklich was schief. Momentan liegt die Pipeline bei 5 Stufen durch C_AREA_OPTIMIZED = 0
Ja, das ist ein Parameter vom Microblaze. Durch Setzen des Parameters auf '1' wird der Microblaze auf engerem Raum (weniger Logik-Zellen) platziert. Dadurch ist aber gleichzeitig auch die Pipeline nur noch 3-stufig anstatt wie üblich 5-stufig.
Ich habe mich in meiner Diplomarbeit mal mit dem MB beschäftigt, kam da aber eher so auf 4 Takte pro Durchlauf. Genauer weiß ichs aus dem Kopf grad nicht mehr, aber woher kriegt der MB den seine Daten? Internes BRAM? Oder Flash/SRAM/DDR? Da kann einem nämlich das ganze ohne Cache gehörig in die Suppe spucken.
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.