AVR + Spartan 3 als externes RAM

[Maik (Gast)]

Hallo,
ich möchte einen AVR 128 (ext. Memory-Bus) glueless mit einen Spartan 3 
(XC3S 400) verbinden.

In dem FPGA möchte ich nartürlich dedizierte Logic untertbringen.

Kann ich die 288kBit Block RAM des FPGAs dem AVR als externen
Daten Speicher zuweisen?

Hat jemand vieleicht ein solches Design?

Danke

Maik Scholz

[Falk (Gast)]

@ Maik (Gast)

>ich möchte einen AVR 128 (ext. Memory-Bus) glueless mit einen Spartan 3
>(XC3S 400) verbinden.

So weit so gut.

>In dem FPGA möchte ich nartürlich dedizierte Logic untertbringen.

>Kann ich die 288kBit Block RAM des FPGAs dem AVR als externen
>Daten Speicher zuweisen?

Nicht ohne (knifflige) Tricks. Der AVR ist auf ASYNCHRONEN RAM 
ausgelegt, das FPGA hat intern aber nur SYNCHRONEN RAM. Kann man ggf. 
umbiegen, aber nicht ohne Tricks.

Aber am Ende ist der Anstatz IMHO wenig wert. Nimm einen stinknormalen 
SRAM und klemm ihn an den AVR. Nimm das FPGA und klemm es auch an, 
platzier deine Logik drinnen und gut. Ein paar Dutzend Register kann man 
ohne grössere Probleme asynchron im FPGA ansprechen. Den RAM würde ich 
da nicht anklemmen.

MFG
Falk

[Thomas P. (pototschnig)]

> Nicht ohne (knifflige) Tricks. Der AVR ist auf ASYNCHRONEN RAM
> ausgelegt, das FPGA hat intern aber nur SYNCHRONEN RAM. Kann man ggf.
> umbiegen, aber nicht ohne Tricks.

Wo wir wieder beim alten Problem sind - Zum Prozessortakt ist alles 
synchron und damit würde man auch den Block-RAM synchron verwenden 
können.

Weiß man nur wieder nicht, obs da einen großen zeitlichen Unterschied 
zwischen Controller-Takt und den Daten gibt.

> Aber am Ende ist der Anstatz IMHO wenig wert. Nimm einen stinknormalen
> SRAM und klemm ihn an den AVR. Nimm das FPGA und klemm es auch an,
> platzier deine Logik drinnen und gut. Ein paar Dutzend Register kann man
> ohne grössere Probleme asynchron im FPGA ansprechen. Den RAM würde ich
> da nicht anklemmen.

Das macht schon Sinn ... Wenn das FPGA im Speicherbereich eingebunden 
ist, hat das ein haufen Vorteile und man braucht keinen zusätzlichen 
Speicher.

Mfg
Thomas Pototschnig

[Falk (Gast)]

@ Thomas Pototschnig (pototschnig)

>Wo wir wieder beim alten Problem sind - Zum Prozessortakt ist alles
>synchron und damit würde man auch den Block-RAM synchron verwenden
>können.

Ja, wenn der uC eine synchrone Speicherschnittstelle hätte.
Hat der AVR aber nicht, alles old-school asynchron. Und sogar noch mit 
LATCH statt FlipFlop. Ihhhgitt ;-)

>Das macht schon Sinn ... Wenn das FPGA im Speicherbereich eingebunden
>ist, hat das ein haufen Vorteile und man braucht keinen zusätzlichen
>Speicher.

Wenn das Wörtchen wenn nicht wär, wär ich schon lange Millionär. ;-)

MFG
Falk

[Thomas P. (pototschnig)]

Falk wrote:
> @ Thomas Pototschnig (pototschnig)
>
>>Wo wir wieder beim alten Problem sind - Zum Prozessortakt ist alles
>>synchron und damit würde man auch den Block-RAM synchron verwenden
>>können.
>
> Ja, wenn der uC eine synchrone Speicherschnittstelle hätte.
> Hat der AVR aber nicht, alles old-school asynchron. Und sogar noch mit
> LATCH statt FlipFlop. Ihhhgitt ;-)

Hmm ... ich glaub ich kann dir nicht ganz folgen. Das Interface ist 
nichtmal im AVR synchron?

Ich hab vor kurzem aber auch erst ein asynchrones Interface (16Bit, 
asynchronen und gemultiplexten Bus von einer PCI-Bridge) an ein FPGA 
angebunden und das funktioniert. Ist halt im FPGA auch ein Latch drin.

Ist eins meiner Studienprojekte ... im FPGA befindet sich auch ein 4kB 
BlockRam, das ich dann über die Bridge auslesen will.

Also es funktioniert bestimmt ... :-)

>>Das macht schon Sinn ... Wenn das FPGA im Speicherbereich eingebunden
>>ist, hat das ein haufen Vorteile und man braucht keinen zusätzlichen
>>Speicher.
>
> Wenn das Wörtchen wenn nicht wär, wär ich schon lange Millionär. ;-)

Ja, es macht aber wirklich sinn ;-)

> MFG
> Falk

[Falk (Gast)]

@ Thomas Pototschnig (pototschnig)

>Hmm ... ich glaub ich kann dir nicht ganz folgen. Das Interface ist
>nichtmal im AVR synchron?

IM AVR wird schon alles synchron sein, aber AM AVR zum exteren SRAM ist 
es klassisch asynchron mit ALE, N_RD und N_WR.

>Ich hab vor kurzem aber auch erst ein asynchrones Interface (16Bit,
>asynchronen und gemultiplexten Bus von einer PCI-Bridge) an ein FPGA
>angebunden und das funktioniert. Ist halt im FPGA auch ein Latch drin.

Sicher geht das, aber ggf. muss man tricksen. Z.B. wenn Schreibzugriffe 
Handshake Flags setzten etc.Alles machbar, aber sicher nicht mehr sauber 
synchrones Design.

>Ist eins meiner Studienprojekte ... im FPGA befindet sich auch ein 4kB
>BlockRam, das ich dann über die Bridge auslesen will.

>Also es funktioniert bestimmt ... :-)

Hab ich auch schon gemacht, mit genügend Wait States und einem schnellen 
lokalen Takt am FPGA geht das schon. Abr wirklich schön isses nicht.

MfG
Falk

[Thomas P. (pototschnig)]

Sah in etwa so aus:

- Kombinatorische Logik
-- Umschaltung f�r'n Datenbus
  LAD <= (others =>'Z') when RD='1' else i_dataout; -- Tristate ein/ausschalten
  i_datain <= LAD;
  
  process (clk)
  begin
    if clk'event and clk='1' then
      if wr='0' then
        if i_address=X"0000" then
          [...]
        end if;
      end if;

      if rd='0' then
        if i_address=X"0000" then
          i_dataout <= [...]
        end if;
      end if;
    end if;
  end process;

-- Adresslatch
  process (clk)
  begin
    if clk'event and clk='1' then
      if ALE='1' then
        i_address <= LAD;
      end if;
    end if;
  end process;

Wenn das wirklich ganz asnynchron ist, muss man die Signale halt 
einsynchronisieren. Aber das FPGA ist eh viel schneller als der AVR und 
da denke ich nicht, dass es Probleme gibt.

Und in Verbindung mit dem BlockRAM: WE vom Blockram mit dem 
einsynchronisierten WE verbinden - dann wird halt im schlimmsten Fall 
öfters, das gleiche auf die selbe Speicheradresse, geschrieben, das ist 
ja egal. Lesen ist ähnlich.

Also wo ist nochmal das Problem?


Mfg
Thomas Pototschnig

[Falk (Gast)]

@ Thomas Pototschnig (pototschnig)


>-- Adresslatch
>  process (clk)
>  begin
>    if clk'event and clk='1' then
>      if ALE='1' then
>        i_address <= LAD;
>      end if;
>    end if;
>  end process;
>[/code]

>Wenn das wirklich ganz asnynchron ist, muss man die Signale halt
>einsynchronisieren. Aber das FPGA ist eh viel schneller als der AVR und
>da denke ich nicht, dass es Probleme gibt.

OHHH doch! Ok, für ein Hobbyprojet ist es wahrscheinlich egal, wenn alle 
paar Millionen Schreibzugriffe mal einer daneben geht. Aber im 
professionellen Bereich gibt das verdammten Ärger.
Deshalb müssen ALLE asynchronen Signale einsynchronisiert werden. Und 
auch dort kann man viel falsch machen! Einen Bus darf man nicht einfach 
per Register synchroniesieren und sagen "passt schon". Wenn man nämlich 
in der Nähe von Datenwechseln abtastet kann es passieren, dass man 
einige "alte Bits" mit "neuen Bits" vermischt -> Bums!

>Und in Verbindung mit dem BlockRAM: WE vom Blockram mit dem
>einsynchronisierten WE verbinden - dann wird halt im schlimmsten Fall
>öfters, das gleiche auf die selbe Speicheradresse, geschrieben, das ist
>ja egal. Lesen ist ähnlich.

Jaja, abe der Teufel steckt im Detail! Und ich hab da schon viel Mist 
gesehen.

>Also wo ist nochmal das Problem?

Jugendlicher Leichtsinn . . . ;-)

MfG
Falk

[Uwe Bonnes (Gast)]

@Maik:

Glueless geht es nur, wenn der AVR auch mit 3.3. Volt laeuft...

Ansonsten CLKOUT vom AVR in den DCM und die Leitungen des AVR mit 
hoeherer Frequenz samplen.

[Falk (Gast)]

@ Uwe Bonnes (Gast)

>Glueless geht es nur, wenn der AVR auch mit 3.3. Volt laeuft...

Ja.

>Ansonsten CLKOUT vom AVR in den DCM und die Leitungen des AVR mit
>hoeherer Frequenz samplen.

Da wäre ich vorsichtig, ausserdem braucht der DCM mind. 24 MHz, der AVR 
läuft mit max. 20 MHz. :-(
Ausserdembin ich mir nicht so ganz sicher ob der AVR nciht zuviel Jitter 
generiert, die DCMs sind da bisweilen ein wenig mädchenhaft, ähhh 
sensibel. ;-)

Es sollte auch ohne DCM gehen. Oder besser einen hohen Takt nehmen, im 
FPGA durch zwei oder vier teilen und dann dem AVR zur Verfügung stellen. 
Dann isses FAST synchron. Und spart ein Pin am AVR. Und schütz gegen 
verfusen ;-)

MFG
Falk

[Joachim (Gast)]

Habe auch schon einen AVR an ein FPGA (allerdings Altera Cyclone) 
angeschlossen. Das Takten des AVR über das FPGA macht die Sache auch 
nicht wirklich einfach, weil die AVR-Signale ja auch nicht absolut 
zeitgleich mit dem CPU-Takt sind. Ich habe in meinem Falle einfach mal 
die Timingangaben im Datenblatt genommen und nachgerechnet, ob ich im 
"grünen Bereich" liege.

Das Knifflige am Bustiming ist lediglich das Signal ALE.
RD und WR sind unkritisch. Die Busdaten liegen lange genug an.
Laut AVR-Daten liegen die Adressdaten minimal 5ns nach Abfallen von ALE 
an.
Das ist verdammt kurz, um die fallende Flanke von ALE 
einzusynchronisieren.
Andererseits stehen die Adressen mindestens 52ns vor Abfallen ALE an, 
wenn der AVR mit 8MHz läuft.
Ich habe das Problem ebenfalls durch das einfache Abtasten des Pegels 
von ALE gelöst.
Bei 50MHz Takt werden dabei 2 gültige Adressen "erwischt", solange ALE 
noch High ist. Der letzte Zustand (bevor ALE als Low erkannt ist), ist 
also garantiert gültig. 100prozentig! Da der AVR die Adresse 5ns nach 
ALE garantiert, ist man auch bezüglich Laufzeiten im FPGA auf der 
sicheren Seite.

Von daher muss das o.g. funktionieren:

>-- Adresslatch
>  process (clk)
>  begin
>    if clk'event and clk='1' then
>      if ALE='1' then
>        i_address <= LAD;
>      end if;
>    end if;
>  end process;

Sieht bei mir genauso aus.
Einziger Haken:
Das funktioniert nur, wenn das FPGA ca. 3x so hoch getaktet wird, als 
der AVR.
Denn die Adressen liegen nur minimal 0.5Clock-10 vor Abfallen ALE an.
In der Praxis bedeutet dies für den AVR Takt:
8MHz: 62,5ns-10ns = 52,5ns
16MHz: 31,25ns-10ns = 21,25ns
20Mhz: 25ns-10ns = 15ns

Bei 16MHz AVR würde ein 50MHz FPGA-Takt gerade noch reichen, wenn auch 
sehr knapp.
Bei 20MHz AVR würde mit 50MHz bereits "danebengetappt", da die 
Abtastperiode 20ns beträgt, die Adresse aber nur garantierte 15ns lang 
anliegt.

Joachim

[Falk (Gast)]

@ Joachim (Gast)

>nicht wirklich einfach, weil die AVR-Signale ja auch nicht absolut
>zeitgleich mit dem CPU-Takt sind. Ich habe in meinem Falle einfach mal

Meine Rede.

>Das Knifflige am Bustiming ist lediglich das Signal ALE.
>RD und WR sind unkritisch. Die Busdaten liegen lange genug an.
>Laut AVR-Daten liegen die Adressdaten minimal 5ns nach Abfallen von ALE
>an.
>Das ist verdammt kurz, um die fallende Flanke von ALE
>einzusynchronisieren.

Würde ich nicht machen. Hier würde ich ALE als echten Takt, oder 
meinetwegen als Latch enable nutzen und ein Register/Latch im FPGA 
direkt implementieren. Ohne Einsynchronisieren auf einen schnellen Takt. 
Gleichzeitig kann dadurch auch ein Flag gesetzt werden, welches vom FPGA 
synchronisiert wird und zur weiteren Steuerung verwendet werden kann. 
Gelöscht wird das Flag dann über den asynchronen Reset.

>Bei 16MHz AVR würde ein 50MHz FPGA-Takt gerade noch reichen, wenn auch
>sehr knapp.
>Bei 20MHz AVR würde mit 50MHz bereits "danebengetappt", da die
>Abtastperiode 20ns beträgt, die Adresse aber nur garantierte 15ns lang
>anliegt.

Eben, deshalb lieber wirklich asnchrones Latch un den Rest über 
Abtastung. Spart viel Stress.

MFG
Falk