spezielles Lesetiming - so realisierbar?

[Andreas B. (loopy83)]

Hallo zusammen,

ich habe folgendes Problem und wollte erst einmal die Machbarkeit 
überprüfen.
Im Anhang ist das Lesetiming eines PowerPCs mit Chipscope dargestellt.

Zu sehen sind die Adressen (im 2er-Inkrement wegen 16bit Zugriff), 
Chipselect und Ouput-enable.
Der Transfer wird geburstet, es werden also immerhalb von einem 
Lesezyklus 16x16bit Werte gelesen, also 32 Byte. Es sollen erst 32Byte 
auf Fifo1 gelesen werden und dann 32byte aus Fifo2... also immer im 
Wechsel (PADD Bit 22 wechselt ale 16 Lesezugriffe den Wert, also habe 
ich es daran festgemacht).

Der Sampletakt von Chipscope war der Lesetakt PCLK.

Nun kann man ja sehen, dass sich die Adressen mit dem ersten Lesetakt 
ändern, dann noch ein Takt Luft ist und sich dann die Adresse schon 
wieder ändert.

Leider kann mir mein Kommilitone, welcher den PPC konfiguriert, nicht 
sagen, auf welchem Takt der PPC die Daten liest, aber ich vermute auf 
dem zweiten Takt.

Der Lesetakt ist 83MHz.

Ist es mit dem FPGA möglich, die Adressänderung auf dem ersten Takt zu 
erkennen und auf dem zweiten Takt die Daten auf den Bus zu legen?

Ich habe es mit einer Statemachine versucht, bin aber bisher an den 
ganzen Bedingungen gescheitert, so dass die Werte nicht zuverlässig 
gelesen werden können.

Ist eine Statemachine anhand der Abbildung machbar, die die Aufgabe 
löst, oder sind es zu wenig Takte für jeden einzelnen Lesezugriff?

Hier mein derzeitiger Versuch:

process (PClk)
  begin
    if rising_edge(PClk) then
      if reset = '0' then
        cam_state1 <= WARTEN;
        read_en1 <= '0';
        read_en2 <= '0';
        PDATA <= (others => 'Z');
      else
        case cam_state1 is
        
          -- WARTEN
          when WARTEN =>
            read_en1 <= '0';
            read_en2 <= '0';
            PDATA <= (others => 'Z');
            if fifos_full = '1' then
              cam_state1 <= LESEN_0;
            end if;

          -- LESEN_0
          when LESEN_0 =>
            read_en1 <= '0';
            read_en2 <= '0';
            PDATA <= (others => 'Z');
            if (PCS1 = '0' and POEn = '0' and PRnW = '1' and PADD(22) = '0') then
                read_en1 <= '1';
                PDATA <= fifo1_out;
                cam_state1 <= LESEN_2;
            elsif PCS1 = '1' then
              cam_state1 <= WARTEN;
            else
              read_en1 <= '0';
              read_en2 <= '0';
              PDATA <= (others => 'Z');
              cam_state1 <= WARTEN;
            end if;
          
          --LESEN_2
          when LESEN_2 =>
            read_en1 <= '0';
            read_en2 <= '0';
            PDATA <= (others => 'Z');
            if (PCS1 = '0' and POEn = '0' and PRnW = '1' and PADD(22) = '1') then
                read_en2 <= '1';
                PDATA <= fifo2_out;
                cam_state1 <= LESEN_0;
            elsif PCS1 = '1' then
              cam_state1 <= WARTEN;
            else
              read_en1 <= '0';
              read_en2 <= '0';
              PDATA <= (others => 'Z');
              cam_state1 <= WARTEN;
            end if;
          
          --OTHERS
          when others =>
            read_en1 <= '0';
            read_en2 <= '0';
            PDATA <= (others => 'Z');
            cam_state1 <= WARTEN;
        end case;
      end if;
    end if;
  end process;

VIELEN DANK!
Andi

[Läubi .. (laeubi)]

Andreas B. schrieb:
> Leider kann mir mein Kommilitone, welcher den PPC konfiguriert, nicht
> sagen, auf welchem Takt der PPC die Daten liest, aber ich vermute auf
> dem zweiten Takt.
Steht bestimmt im Datenblatt des PPC bzw. dessen Speichercontrollers.

> Ich habe es mit einer Statemachine versucht, bin aber bisher an den
> ganzen Bedingungen gescheitert, so dass die Werte nicht zuverlässig
> gelesen werden können.
Versuch doch erstmal dir mit dem IP Generator einen beispielcore für den 
Bus zu generieren.
Beim FSL Bus wird es z.B. so gemacht das die Zustandübergänge in einer 
Statemachine geschehen, das legen auf die "Ports" geschieht dann 
asyncron mit dem aktuellen Zustand als Bedingung, so hat man je nach 
interner Laufzeit die Daten bei der nächsten Taktflanke anliegen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Wie ist der Prozessor ans FPGA gekoppelt? Eingebaut im FPGA?

Sind die Takte für den Prozessor und das FPGA die selben (oder 
wenigstens synchron)?

>             PDATA <= (others => 'Z');
Weil es einen Tristate-Bus im FPGA nicht gibt, vermute ich, der PPC 
ist extern angeschlossen. Dann sollte die Treiberumschaltung aber nicht 
an den Takt gekoppelt sein, denn sonst bist du immer zu spät dran und 
hast jeweils einen Buskonflikt. Siehe den 
Beitrag "Re: FPGA, Datenbus & Register"

[Andreas B. (loopy83)]

Hallo,

PPC und FPGA sind gleich getaktet. Also der Takt wird vom PPC vorgegeben 
und mit diesem Takt takte ich dann die Leseprozesse im FPGA. Somit 
sollte es synchron laufen.

Der PPC und der FPGA sind zwei physisch getrennte ICs. An dem Bus hängt 
nur noch ein NOR-Flash, auf den sehr selten zugegriffen wird. In meinen 
bisherigen Versuchen, gab es keine Konflikte.

Wie kann ich denn die Tristate-Treiberumschaltung ungetaktet 
realisieren?
Dieser Ansatz ist mir gänzlich neu und ich habe eine derartige 
Vorgehensweise auch noch in keinem Beispiel gefunden.

Die Geschichte mit dem IP Core muss ich mir mal durchdenken. Bisher habe 
ich hier nur eine DCM und einen Fifo verwendet. Dass man hier auch die 
Buskommunikation steuern kann, ist mir neu. Ich werde mal versuchen ein 
entsprechendes Beispiel zu finden.

Ich fasse zusammen:
Das Hauptproblem besteht darin, dass der PPC mit einer Taktflanke die 
Daten von Bus liest, ich aber mit der gleichen Taktflanke die Daten erst 
auf den Bus lege. Also muss ich die Sache irgendwie asynchon regeln, 
richtig?

Vielen Dank!
Andi

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Das Hauptproblem besteht darin, dass der PPC mit einer Taktflanke die
> Daten von Bus liest, ich aber mit der gleichen Taktflanke die Daten erst
> auf den Bus lege.
Ein alte Geschichte. Wenn du das nicht über einen Dummy-Read am Anfang 
eines Lese-Bursts abhandeln kannst, dann mußt du das Timing so 
gestalten, dass du die Adresse an deinen Fifo direkt anlegst.
> Also muss ich die Sache irgendwie asynchon regeln, richtig?
Du hast z.B. kein Problem, wenn dein Fifo von sich aus gleich nach dem 
Lesen schon die nächsten Daten ausgibt.


> Wie kann ich denn die Tristate-Treiberumschaltung ungetaktet
> realisieren?
Beitrag "Re: spezielles Lesetiming - so realisierbar?"
Das hast du gelesen?

Dieser Tristate-Treiber hier legt abhängig vom oe und ce die Daten 
direkt auf den Bus:

d <= dat when oe = '0' and ce = '0' else (others => 'Z');

> Dieser Ansatz ist mir gänzlich neu und ich habe eine derartige
> Vorgehensweise auch noch in keinem Beispiel gefunden.
Uralte Technik. Das wird seit jeher mit jedem asynchronen Datenbus so 
gemacht.

[Andreas B. (loopy83)]

Hallo,

jetzt verstehe ich die Tristategeschichte. Damit lege ich immer die 
Daten auf den Bus, wenn CE und OE = '0' sind... mit einem getakteten 
Prozess schreibe ich dann nur noch meine Ausgangsdaten in den Vector 
dat.

Ich habe zwei 16bit Fifos, die ich auslese. Abhängig von drei weiteren 
Eingängen entscheide ich, welche 8bit ich aus jedem Fifo auf den Bus 
lege, dass ich wieder auf meine 16bit Busbreite komme, aber keine Daten 
verliere bzw. ich immer entscheiden kann, welche der 16bit ich mir 
ansehen möchte.
Diese Entscheidung, geregelt über eine case Anweisung, muss ich ja 
takten. Aber wenn ich das recht überschaue kann ich ja dann in der case 
Anweisung den dat-Vector beschreiben... ja, das sollte gehen.

Ein Dummy Read am Anfang des Bursts ist leider nicht möglich, weil 
dieser über einen DMA-Tranfer geregelt wird. Da kann nach Aussage meines 
Kommilitonen der erste Read nicht verworfen werden, ohne dass das 
Adress-increment nicht auch mit aufgehoben wird.

Ich habe mir den Fifo als IP-Core implementiert. Ich habe da jetzt keine 
Möglichkeit gefunden, wie ich die Adressen direkt und die Bit-Selektion 
mit einbinden kann. Auch hat der Fifo-Speicher einen Lesetakt und es 
wird nur gelesen, wenn read_en aktiviert ist. Mir wäre neu, wenn die 
neuen Daten direkt am Ausgang anliegen würden, obwohl das read_en nicht 
gesetzt ist.

Vielen Dank!
Andi

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Ich habe mir den Fifo als IP-Core implementiert.
Schreib ihn selber und verwende Distributed RAM als Speicher:
http://www.lothar-miller.de/s9y/archives/21-FIFO.html

>Mir wäre neu, wenn die neuen Daten direkt am Ausgang anliegen würden,
Stichwort "fall thru"

[Andreas B. (loopy83)]

Vielen Dank Lothar!
Ich werde mir die FiFo Sache nochmal genauer anschauen, aber den IP Core 
habe ich eigentlich als First-word-fall-throu konfiguriert.
Einen Fifo selber zu programmieren war mir bisher immer etwas zu 
komplex... zumal ich mit diesen memory-Sachen noch nie etwas zu tun 
hatte. Aber dein Code sieht ja an sich sehr übersichtlich aus... ich 
werde ihn mir mal genauer anschauen!

Fürs erste werde ich mir erst einmal damit behelfen, dass die Adressen 
bei meinem Bustiming nicht nur 2, sondern 3 Takte aktiv bleiben. So habe 
ich mir genau den weiteren Takt erschummelt, damit die Daten dann auch 
da sind, wenn sie gelesen werden. Damit sollte dann doch meine 
State-machine wieder funktionieren, oder?

Da muss ich aber glaube ich noch etwas Arbeit investieren, denn 
scheinbar läuft da noch etwas nicht ganz rund...

Vielen Dank!
Andi