AVR + Spartan 3 als externes RAM

@ 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 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 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 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

@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.

@ 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

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

@ 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