Hi. Bin jetzt irgendwie an nem Punkt angekommen, wo ich nicht mehr so recht weiterweiß, warum und wieso das so ist. Also mein Problem.... Ich hab ein externes SRAM an einen Atmel Controller (ATMega162) angebunden. Das funktioniert soweit eigentlich auch. Jetzt hab ich aber einen weiteren Baustein, einen CPLD - wollte das trotz verwendeten Baustein nicht ins CPLD/FPGA Forum posten - auf den selben Adressbus, wie den Atmel gelegt. Der CPLD ist mit 3,3V versorgt, hat aber 5V Tolerante Eingänge. Die Ausgänge, die an den Adressen des RAMs angeschlossen sind, sind vorerst mal die ganze Zeit im Tristate Zustand. Jetzt wollte ich mit dem Atmel das RAM wie zuvor beschreiben und wieder auslesen... einfach als RAM-Test. Jetzt ist es so, dass Fehler beim Schreiben bzw. Lese des RAMs auftreten (weiß leider nicht was fehlschlägt). Lasse ich den CPLD unversorgt, dann funktioniert es wieder einwandfrei. Meine Frage ist jetzt, darf ich CPLD und Atmel so einfach zusammenschalten, auch, wenn der CPLD seine Eingänge im Tristate Modus hat, weährend der Atmel auf den Bus schreibt????? Oder weiß jemand, was das für ein Fehler sein kann. mfg Andreas
Hi du hast Tri-State Pins an einigen Addressleitungen des SRAMs? Sonst nichts? Du solltest da entweder Pull-Up/Down vorsehen oder die betreffenden Pins des CPLD auf Ausgang schalten. Matthias
Hört sich schwer nach Buskollisionen an. Bist Du Dir sicher, daß der CPLD bei RAM-Zugriffen im Tristate ist? Dort würde ich ansetzen. Wie hast Du /CE vom RAM beschaltet? Der RAM muß natürlich abgeschaltet sein, wenn auf den CPLD zugegriffen wird. Schließe doch Testhalber den CPLD an den Bus an und lege ihn per Hand auf Tristate - vielleicht ist einfach nur ein Wurm bei der Selektierung. @Matthias: Wenn Du die Adressausgänge des CLPD auf Ausgang schaltest, findet das der Atmel sicherlich nicht so prall - schließlich geht er davon aus, daß er der Busmaster ist... Pull-Up/Down sind in der Regel auch nicht nötig - wegen des Atmel.
Hi. Danke schonmal für die Antworten. @thkais: Also, ich will mit Atmel und CPLD auf das RAM zugreifen. Über so eine Art Chipselect garantiere ich, dass der CPLD immer im Tristate Zustand ist, wenn der Atmel das RAM lesen/schreiben will. Aber ich werde die Ausgänge des CPLD, die im Tristate zustand sein sollen, nochmal genau unter die Lupe nehmen. mfg Andreas
Das dürfte aber nicht so ohne weiteres funktionieren. Ich bastele gerade am exakt gleichen Problem ;) Du hast AD0-AD7, A8-A15, ALE am CPLD. Der CPLD arbeitet als 8Bit Latch für AD0-AD7. Dessen 8 Ausgänge stellen die gelatchte Addresse A0-A7 dar. Der SRAM ist nun mit A0-A7 am CPLD A0-A7 Latch, A8-A15 am gemeinsammen Bus zwischen AVR und CPLD,und die Datenausgänge IO0-IO7 des SRAMs sind wieder an AD0-AD7. Das wäre die Standardbeschaltung. Man muss nämlich beachten das der AVR seine Addressleitungen nach einem Speicherzugriff nicht auf Tristate legt. Würden also der AVR und der CPLD als Busmaster auf den Addressbus zugreifen wollen dann muß immer einer der beiden Master seine Ausgänge auf Tristate/Pulldown legen. Aber ganau dies ist beim AVR nur möglich wenn nach einem Speicherzugriff das XMEM Interface deaktiviert wird, A0-A15 mus manuell auf Tristate/Pulldown gelegt werden. Das ist natürlich, für mich zumindestens, inakzeptabel da das ziemlich die Performance drückt. Ich persönlich bastle da an einer anderen Idee. Als SRAM will ich CacheSRAM Bausteine nutzen, also maximal 30ns Zugriffzeit. Der AVR liegt komplett mit XTAL, ALE, WR\, RD\ am CPLD. Der CPLD hat A0-A15, D0-D7, CS, RD\,WR\ wiederum als eigenen Daten-Addressbus. An diesem liegen die externen Geräte wie eben auch der SRAM. Der CPLD wird mit 32MHz getaktet und teilt das runter auf 16Mhz als Takt für den AVR. Nun sind mehrere Punkte gegeben: 1.) synchroner Takt zwischen AVR und CPLD 2.) CPLD Takt ist 2 mal höher als AVR Takt 3.) CPLD steuert komplett den schnellen SRAM und externe Geräte an. Der CPLD wird nun intern wie ein Dual Port SRAM arbeiten. Dazu greift er selber immer in 2 Zeitscheiben auf den externen SRAM synchronisiert zum AVR zu. In der 1. Zeitscheibe erfüllt er alle Anforderungen des AVRs. In der 2. Zeitscheibe greift er für sich selber auf den SRAM zu. Die Gesammtzugriffzeit für den AVR ist danach wieder so wie ohne CPLD. Nachteil ist der Punkt das der CPLD nun mehr IOs benötigt. Deine Frage zielt erstmal nur auf einen Buskonflikt durch den CPLD wenn der AVR zugreifen will, ab. Wenn der CPLD später selber den Bus übernehmen will, er also selber aus dem SRAM lesen will, musst du ja sicherstellen das der AVR seinen Bus auf Tristate/Pulldown legt. Das kannst du aber nur wenn du das XMEM Interface deaktivierst und die Ausgänge als Eingänge schaltest. So lange das XMEM Interface aber aktiviert ist beleiben an AD0-AD7 und A8-A15 die zuletzt benötigten Werte stehen, und kollidieren somit mit dem CPLD Zugriffen. Gruß Hagen
Ok... also das Problem des gemeinsamen Zugriffs versteh ich. Sowas hab ich mir eigentlich auch schon gedacht, dass der Atmel seine Adressleitungen nicht in den Tristate Mode versetzt (zumindest nicht selbst). Das mit dem deaktivierem im XMEM Register ist bei mir nicht problematisch, da ich 1. das ganze nicht auf Performance geht, 2. ich das RAM mit dem CPLD vollschreibe und dann mit dem Atmel auslesen will. Ich werd jetzt aber erst noch was anderes probieren. Ich werd die 15 Leitungen des CPLD einfach mal als Eingang schalten und versuchen das RAM vom Atmel aus zu beschreiben und anschließend wieder auszulesen. Hab die ganze Zeit eigentlich nicht erwähnt, was das ganze eigentlich soll... Ich hab vor einen Logic Analyser zu bauen. Und zwar zählt der CPLD nur die Adressen des RAMs hoch (Frequenz vorerst mal mit 12 MHz danach sollte er das mit ca. 50 MHz machen und die Frequenz soll auch runterteilbar sein). Also, CPLD zählt die Adressen hoch und "taktet" den WR Eingang. Über einen 74HC573 sollen die Daten immer wieder gelatcht werden. Wenn das RAM - ist übrigens ein altes 20ns RAM von nem alten PC - voll ist, wird ein high Signal auf einer Leitung ausgegeben und der Atmel kann das RAM auslesen und die Werte an den PC übertragen. Also theoretisch sollte das ganze funktionieren. Praktisch muss ich das eben noch testen. Später soll ja auch noch ein analoger Teil für ein DSO (digitales Speicher Oszi) hinzukommen. mfg Andreas
Den 8Bit Latch für die unteren Addressen kannst du auch im CPLD einbauen, somit brauchst du den 74HC573 nicht mehr. Das kostet fast nichts an Makrozellen. Über eine ähnliche Lösung wie deine hatte ich auch schon nachgedacht, nur kommt die bei meinem Projekt nicht in Frage. Der CPLD und der AVR müssen quasi zur gleichen Zeit (bezogen auf AVR takt) auf den SRAM zugreifen können. Am Anfang wollte auch ich es so machen das der AVR mit seinem Bus voll am CPLD hängt. Der CPLD wiederum hat einen vollständigen und eigenen Bus zum SRAM. So lange nun der CPLD in den SRAM schreibt wurde ein externes Signal auf H gelegt. Nachdem der CPLD den SRAM gelesen/geschrieben hatte wurde das Signal auf L gelegt und im AVR ein Interrupt ausgelösst. In diesem Moment schaltet der CPLD alle Anforderungen vom AVR Bus direkt 1 zu 1 zu seinem SRAM Bus durch. Nun, leider geht das bei mir nicht, da ich eben zur "gleichen" Zeit vom AVR und CPLD an beliebigen SRAM Addressen lesen oder schreiben muß. Ich hoffe mal das mein "Timesharing" Ansatz funktioniert. Der CPLD soll bei mir auch noch den 8Bit Addresslatch und eine Addressdekodierung für Memory Mapped Devices enthalten. Wenn es denn mal funktioniert kann man das VHDL auch leicht so umschreiben das sich zwei AVRs den gleichen SRAM teilen können. Zur zeit hänge ich am Simulator von Quartus II, die nötigen Wave Files sind ziemlich zeitaufwändig. Gruß Hagen
"(Frequenz vorerst mal mit 12 MHz danach sollte er das mit ca. 50 MHz machen und die Frequenz soll auch runterteilbar sein)." Wie willst die den Takt für den CPLD erzeugen ? Es gibt ja verschiedene Ansätzeund ich bin mir bei meinem Projekt noch nicht so ganz im klaren darüber. Ein externer TTL Oszillator wäre meine Vorstellung. Gruß Hagen
Momentan erzeuge ich den Takt mit einem einfachen Quarz an nem Inverter (direkt am CPLD hat das bei mir nicht geklappt). | |\ | | +--|/°-+ | | | | | +--|------|---+ | | +-|R |-+ | | +-|Q|--+ | | C --- --- C --- --- | | +---+--+ | --- GND - Das funktioniert aber auch nur bedingt. Ohne Oszi ist das alles etwas schwierig abzustimmen. Und für 50 MHz ist die beste Lösung wohl sowieso ein Quarzoszillator. mfg Andreas
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.