Bare Metal Cortex-A8 mit FPGA

[Michael F. (mifi)]

Hallo zusammen,

hier mal ein kleines Beispiel für einen Bare Metal Cortex-A8 mit einer
FPGA Anbindung. Als Cortex-A8 wurde hier das BeagleBone Board verwendet.
Für das FPGA ein Altera DE0-nano. Die CPU ist hier ein AM335x und das
FPGA ein Cyclone IV.

Bei der CPU wurde der GPMC Bus, im FPGA ein Wishbone Bus verwendet.
Das Beispiel dient mehr als Test für die Umsetzung des GPMC / Wishbone
Masters. Wenn alles läuft können von der CPU aus die LEDs (0 bis 6)
auf dem DE0-nano gesteuert werden. Genug der Worte hier gibt es die
Sourcen:

http://www.emb4fun.de/arm/bbbmfpga/index.html

Einen extra "Schaltplan" für die Verbindung zwischen CPU und FPGA gibt
es nicht. Also mal in die Sourcen schauen...

Viele Grüße,
Michael

[Duke Scarring (Gast)]

Michael Fischer schrieb:
> Wenn alles läuft können von der CPU aus die LEDs (0 bis 6)
> auf dem DE0-nano gesteuert werden.
Das ist ja nun noch nicht die Killerapplikation ;-)

Wie breit ist das Dateninterface?
Wie schnell kann der Prozessor an seiner Schnittstelle die Daten 
bereitstellen bzw. abholen?
Was bleibt von der Datenrate effektiv noch übrig, wenn man auf dem 
Wishbonebus misst?

Duke

[Michael F. (mifi)]

Hallo Duke,

>Das ist ja nun noch nicht die Killerapplikation ;-)
Das habe ich mir gedacht das so etwas kommen wird. Aber egal, mein
Schwerpunkt lag darin einen Wishbone Master zum laufen zu bekommen.
Und erst mal eine Lösung für weitere Diskussionen.

Zurück zu den Fragen. Der GPMC Bus vom AM335x läuft mit 100MHz, und die
Read/Write Zugriffe sind auf 50ns eingestellt. Zwischen den Zugriffen
brauche ich aber noch 30ns Cycle2Cycle Delay. D.h. die max.
Geschwindigkeit beträgt hier 80ns. Die Busbreite beträgt 16-Bit.
Mit diesen 80ns würde ich in die Rechnung gehen wollen. Mit 80ns
und 16Bit Breite komme ich auf einen Wert von 25MByte/s.

Warum jetzt nur 50ns und 30ns Cycle2Cycle Delay?

Der CPU Bus läuft asynchrone zum FPGA. D.h. die Steuersignale
wie CS, WE und OE werden erst mal einsynchronisiert. Da hierdurch jetzt
die FPGA Signale verzögert sind gegenüber der CPU, werden die FPGA
Signale auch später wieder deaktiviert gegenüber der CPU. Darum benötige
ich das Cycle2Cycle Delay. Vielleicht ist das auch der falsche Ansatz,
und es gibt bessere Möglichkeiten für das Bus Interface. Immer her
damit, ich mache jetzt VHDL erst seit einem Jahr und mir fehlt die 
entsprechende Erfahrung um vielleicht den letzten Takt aus dem Design zu 
holen.

Alternativ zum ersten Ansatz könnte man  das CPU Interface auch synchron
betreiben. Hier wird der 100MHz Clock aber nur so lange erzeugt wie auch
ein Zugriff auf dem Bus vorhanden ist. Für meine interne Schaltung
benötige ich aber auch einen Clock. D.h. ich habe hier ClockDomain
Übergänge. Und wie ich das dann intern synchronisiere weiß ich nicht.
Und würde ich damit im Endeffekt wirklich an Zeit gewinnen?

Die Sourcen stehen zur Verfügung, und Timings mit dem Logic Analyzer
kann ich auch liefern, wenn Du eine Möglichkeit sieht das zu verbessern.
Steht alles unter der BSD Lizenz, darum dann auch von anderen benutzbar.

Ach, vergessen, das FPGA läuft intern mit 200MHz.

Viele Grüße,
Michael

[Duke Scarring (Gast)]

Michael Fischer schrieb:
>>Das ist ja nun noch nicht die Killerapplikation ;-)
> Das habe ich mir gedacht das so etwas kommen wird.
Deswegen war ja ein Smilie dran.

> einen Wishbone Master zum laufen zu bekommen.
Können an diesem Wishbone noch weiter Master agieren?
Wenn ja, kann das GPMC warten, falls gerade ein anderer Master den Bus 
verwendet?

> Mit 80ns
> und 16Bit Breite komme ich auf einen Wert von 25MByte/s.
Ok. Unterstützt das GPMC Burstzugriffe?
>
> Warum jetzt nur 50ns und 30ns Cycle2Cycle Delay?
>
> Der CPU Bus läuft asynchrone zum FPGA. D.h. die Steuersignale
> wie CS, WE und OE werden erst mal einsynchronisiert. Da hierdurch jetzt
> die FPGA Signale verzögert sind gegenüber der CPU, werden die FPGA
> Signale auch später wieder deaktiviert gegenüber der CPU. Darum benötige
> ich das Cycle2Cycle Delay. Vielleicht ist das auch der falsche Ansatz,
> und es gibt bessere Möglichkeiten für das Bus Interface. Immer her
> damit,
Schau Dir mal den Anhang an, Seite 25/26. Vielleicht kannst Du noch 
einen Takt rausholen.


> Alternativ zum ersten Ansatz könnte man  das CPU Interface auch synchron
> betreiben. Hier wird der 100MHz Clock aber nur so lange erzeugt wie auch
> ein Zugriff auf dem Bus vorhanden ist. Für meine interne Schaltung
> benötige ich aber auch einen Clock. D.h. ich habe hier ClockDomain
> Übergänge. Und wie ich das dann intern synchronisiere weiß ich nicht.
> Und würde ich damit im Endeffekt wirklich an Zeit gewinnen?
Wenn der Takt nicht permanent anliegt nützt er nix.
Man könnte evtl. das Boarddesign umstellen, um Controller und FPGA mit 
dem gleichen Takt zu versorgen, aber damit schränkt man sich m.E. 
unnötig ein (auf beiden Seiten).

Duke

[ARMdran (Gast)]

Vielen Dank für das Beispiel, sowas hatte ich vor längerer Zeit mal 
gesucht.

[Michael F. (mifi)]

Hallo Duke,

>Deswegen war ja ein Smilie dran.
:o)

>Können an diesem Wishbone noch weiter Master agieren?
>Wenn ja, kann das GPMC warten, falls gerade ein anderer Master den Bus
>verwendet?
Theoretisch ja, aber das wb_interconnect ist im Moment nur für einen
Master ausgelegt. Der GPMC kann warten, d.h. es werden Waits 
unterstützt. Aber, dann muß das Timing von 50ns auf 60ns erhöht werden.
Das Problem ist hier das das Wait Signal 3 Takte vor dem Ende des
Buszyklus anliegen muß. Darum dann der zusätzliche Clock. Mann müßte
dann wohl eine Crossbar und keine einfache Interconnect erstellen.

>Ok. Unterstützt das GPMC Burstzugriffe?
Der GPMC ja, mein Master im Moment noch nicht.

>Schau Dir mal den Anhang an, Seite 25/26. Vielleicht kannst Du noch
>einen Takt rausholen.
Danke für die weiteren Infos. Ich habe die beiden Seiten gerade mal
angeschaut. Das sollte aber kein Problem sein bei mir. Mein Source
sieht hier wie folgt aus:

   process (clk_i, rst_i)
   begin
      if (rst_i = '1') then
         cs_s1 <= '0';
         cs_s2 <= '0';
         
         oe_s1 <= '0';
         oe_s2 <= '0';
         
         we_s1 <= '0';
         we_s2 <= '0';
      elsif rising_edge(clk_i) then
         cs_s1 <= not GPMC_CS_n;
         cs_s2 <= cs_s1;
         
         oe_s1 <= not GPMC_OE_n;
         oe_s2 <= oe_s1;
         
         we_s1 <= not GPMC_WE_n;
         we_s2 <= we_s1;
      end if; 
   end process;
   
   cs <= cs_s2; 
   oe <= oe_s2;
   we <= we_s2;

Somit habe ich schon mal stabile Signale. Ahhh, ich verstehe Dich jetzt.

Eine Flankenerkennung damit ich das spätere Cycle2Cycle Delay nicht mehr
benötige?! Ich würde hier zwar beim FPGA ein zusätzliches FF benötigen,
kann dann aber auf das Cycle2Cycle Delay verzichten. OK, werde ich die
Tage mal genauer testen...

Viele Grüße,
Michael

[Michael F. (mifi)]

Hallo ARMdran,

>Vielen Dank für das Beispiel, sowas hatte ich vor längerer Zeit mal
>gesucht.

Ich bin beim Suchen auf folgende Lösung gestoßen:
http://valentfx.com/logi-bone/

Habe aber beim genaueren hinschauen festgestellt das die Signale
hier nicht einsynchronisiert werden. Das war dann ein Zeichen für
mich das nicht weiter zu verfolgen und selber was zu machen.

Gruß,
Michael