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
@ 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
> 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
@ 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
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
@ 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
Sah in etwa so aus:
1 | - Kombinatorische Logik |
2 | -- Umschaltung f�r'n Datenbus |
3 | LAD <= (others =>'Z') when RD='1' else i_dataout; -- Tristate ein/ausschalten |
4 | i_datain <= LAD; |
5 | |
6 | process (clk) |
7 | begin |
8 | if clk'event and clk='1' then |
9 | if wr='0' then |
10 | if i_address=X"0000" then |
11 | [...] |
12 | end if; |
13 | end if; |
14 | |
15 | if rd='0' then |
16 | if i_address=X"0000" then |
17 | i_dataout <= [...] |
18 | end if; |
19 | end if; |
20 | end if; |
21 | end process; |
22 | |
23 | -- Adresslatch |
24 | process (clk) |
25 | begin |
26 | if clk'event and clk='1' then |
27 | if ALE='1' then |
28 | i_address <= LAD; |
29 | end if; |
30 | end if; |
31 | 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
@ 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
Bitte 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.