Hallo Community, nachdem ich ab und zu hier lese, mein erster Beitrag / Frage um Hilfe, bin naemlich mitlerweile mit meinen Latein am Ende. Ich habe eine 4MB Retro-Speichererweiterung mit async. DRAMS umgesetzt. Diese funktinioert auch mit entsprechenden 74F TTL-Grab hervorragend. Siehe Schaltung mit 74F74 und 74F00. Eingesetzt werden GM74C17400 (oder HYB5117400, TMS417400 ... 4Mbitx4 DRAMs). Was macht die Schaltung: bei DRAMS >1Mbit, funktiniert der CAS before RAS refresh nur korrekt wenn WE write-enable auf high ist, ansonsten geht es in den test-mode (bei WE = low). Wie gesagt mit dem TTLs 74F00 und 74F74 funktiniert es prima. Siehe dazu BIld mit Logicanalzer Salea. Nun moechte ich die Logik + weitere TTL Logic in einen XC9536XL umsetzen. Siehe Schematic Bild, verwende dafuer ein FDC Flip-flop statt des 74F74. In der Simulation mit ISE sieht ebenfalls prima aus. Siehe Bild. Aber nachdem ich den XC9536XL (XL wegen der 5V Logic der DRAMS und des Interface) programmiere, scheitert es. Wenn ich den FWE direkt auf WE lege, klappt das Schreiben und Lesen es bedingt oft, d.h. bis zufaellig der FWE vorher mal low war, dann gehen die DRAM wieder in den TestMode und das Schreiben versagt. Habe bereits die -5ns und -10ns Variaten des XC9536XL probiert, kein Unterschied, Timing ist laut Datenblatt ok, WE-Wechsel hat ca. 10ns bevor RAS auf Low geht. Siehe Bild. Leider habe ich nur ein zwei-Kanal Oszi, deswegen sehe ich CAS, RAS, FWE und WE nicht aufeinmal, was das Fehlersuchen praktisch unmoeglich macht. Mit den ganz einfachen Salea Logicanalyzer komm ich mit nur 100MHz Bandbreite max. auch nicht viel weiter, sehe zwar alle vier Channels, und sehe ebenfalls, dass die 74F TTL Logic genau das tut was sie soll, aber die CPLD Logik Probleme macht. Der ibuf BUffer vor WE war ein Test in meiner Verzweiflung, ob es an der Beschaltung der Ausgangs-Pins liegt. Macht aber mit oder ohne ibuf keinen Unterschied. Bin CPLD-Neuling.... Ich vermute ich uebersehe irgendetwas grundlegendes... Vielen Dank schon mal im vorraus fuer eure Hilfe, stelle gerne noch mehr Input zur Vefuegung falls noetig....!!! Alex. P.S.: Die im CPLD Schematic "herumliegenden" Inverter ignorieren, ebenfalls die CRAS un CCAS die noch oben in weitere Logic gehen (Multiplexer fuer DRAM Bank-Select) - der uebrigens im CPLD geht :) :(
Angehängte Dateien:
-
mk_HW_CASRASW.png
15 KB -
mk_schematic.png
30 KB -
MK_logic_sim.png
26 KB -
mk_pins.png
78 KB
@ AppleII Enthusiast (apple2enthusiast) >Aber nachdem ich den XC9536XL (XL wegen der 5V Logic der DRAMS und des >Interface) programmiere, Die XL haben aber 3,3V IO-Spannung, wenn gleich sie 5V tolerant sind. > scheitert es. Wenn ich den FWE direkt auf WE >lege, klappt das Schreiben und Lesen es bedingt oft, d.h. bis zufaellig >der FWE vorher mal low war, dann gehen die DRAM wieder in den TestMode >und das Schreiben versagt. Tja, so ein CPLD ist DEUTLICH schneller als TTL-ICs, vor allem die FlipFlops sind höllisch schnell. Wenn da unsaubere Takte oder asychrone Resets im Spiel sind hast du verloren. Darum sind die guten, alten Tricks von damals bei diesen ICs tabu! Man baut die Designs nahezu rein sychron aus. Siehe Glitch >Leider habe ich nur ein zwei-Kanal Oszi, deswegen sehe ich CAS, RAS, FWE >und WE nicht aufeinmal, was das Fehlersuchen praktisch unmoeglich macht. >Mit den ganz einfachen Salea Logicanalyzer komm ich mit nur 100MHz >Bandbreite max. auch nicht viel weiter, sehe zwar alle vier Channels, >und sehe ebenfalls, dass die 74F TTL Logic genau das tut was sie soll, >aber die CPLD Logik Probleme macht. Doch, das reicht. Denn damit sieht man, wenn dein FlipFlop einmal zuviel schaltet und damit die Logik im Eimer ist. Ohh, jetzt seh ich es! Dein Trick mit U2d und U2A wird so nicht funktionieren! Dafür ist der IC zu schnell bzw. die Funktion wird von der Fitter-Software anders umgesetzt. Da ist dann KEIN Gatter mehr zur Laufzeitverzögerung drin (U2a)! Also - Die Eingangssignale für Takte und asynchrone Resets müssen absolut glitchfrei sein - das Design muss praktisch synchron sein, Laufzeittricks funktionieren kaum noch (ausser man weiß WIRKLICH, was man tut und weiß, wie die Software das in Logikfunktionen umsetzt)
Angehängte Dateien:
-
cas_before_ras_refresh.png
34 KB -
testmode.pdf.png
39 KB
Vielen, vielen Dank fuer die Antworten.... Jettzt muss ich erstmal die Grundlagen zum Glitch bzw. dem CPLD Verhalten verstehen... D.h. fliessig lesen. Die XL Version is wegen der 5V-toleranz genau richtig, habe namlich noch einen LS245 in den CPLD und einen MUX in den CPLD verbannt. Die DRAMS scheinen mit den 3.3V gut zurecht zukommen. Anbei die beiden Timings um die es mir geht, wie gesagt das Problem ist den WE definitiv in den HIGH state zu bekommen, wenn der CAS before RAS refresh kommt, ansonsten schlaegt der Test mode zu... Wie ich das jetzt in ein glitch-freies, Sync. CPLD Verhalten umsetzte... Nunja.. da steh ich noch auf dem Schlauch...
AppleII E. schrieb: > Wie ich das jetzt in ein glitch-freies, Sync. CPLD Verhalten umsetzte... > Nunja.. da steh ich noch auf dem Schlauch... Hast du einen Takt den man nutzen kann?
Hm, ich habe folgendes: CCAS (aber asynchron) liegt im Moment auf GCK1. Zusaetzlich habe ich noch den PHI2 Clock des 65XXX Prozessors auf den Pin GCK2 gelegt Cycle Type Low High Period ___________________________________________________________________ Normal 2.8-MHz cycle 140ns 210ns 350ns in mir nicht sicher ob das weiterhilft. Ich weiss, dass bei einem rising PHI2 die oberen 8bit der 24bit des Adressbus anliegen, ist also bei Lese- und Schreibzugriffen auf den Speicher "in sync". Wie das bei den CAS before RAS only Refresh aussieht muss ich mal am Oszi anschauen. Glaubt ihr der PHI2 würde mir weiterhelfen? Danke.
> Leider habe ich nur ein zwei-Kanal Oszi, deswegen sehe ich CAS, RAS, FWE > und WE nicht aufeinmal, was das Fehlersuchen praktisch unmoeglich macht. Das ging schon im letzten Jahrtausend mit einem Einkanaler. Stichwort: "Externer Trigger".
Angehängte Dateien:
Habe jetzt mal den PHI2 Takt mit aufgezeichtet... Die Aufzeichung stammt von der funktionierenden TTL Logik. Die Page ueber Glitches habe ich denke ich verstanden, nur bin ich mir nicht sicher wie ich meine TTL Logik jetzt entspechend glitch-free / synchron meinen CPLD beibringen soll. Irgendwie denke ich kann ich den PHI2 ins Spiel bringen... Im Moment bin ich als CPLD Neuling wohl zu doof fuer diese relativ einfache Aufgabe... sorry... Kann mir jemand auf die Spruenge helfen ? Danke. Alex.
AppleII E. schrieb: > Im Moment bin ich als CPLD Neuling wohl zu doof fuer diese relativ > einfache Aufgabe... sorry... Kann mir jemand auf die Spruenge helfen ? Du kannst im CPLD nicht solche Konstellationen wie NAND-Gatter zur Signalverzögerung nehmen. Aber Du kannst die Signale über Flipflops zu einem externen Takt synchronisieren und verzögern. Welche Signale kommen rein und welche müssen rauskommen?
Das mit der nicht-moeglichen Verzoegerung habe ich verstanden. Eingangssignale sind CCAS (column address strobe), CRAS (row address strobe) und FWE (Write enable Input) Ausgangssignale sind nur der modifizierte WE. Das Problem im Moment ist, dass WE ein beliebigen Zustand (letzter Schreib- oder Lese-zugriff) vor dem "CAS before RAS Refresh" hat, ABER fuer einen korrekten CAS before RAS refresh das WE signal unbedingt HIGH sein muss. Wenn es naemlich LOW ist geht das DRAM in den Testmode, und dass soll nicht sein. Deshalb habe ich mit der TTL Logik FWE zu WE so modifiziert, dass wenn ein CAS before RAS refresh kommt, WE auf HIGH geht. Im Gegensatz zu einem normalen Schreibzugriff, bei dem zuerst RAS und dann CAS kommt, und FWE -> WE korrekterweise LOW sein muss. Siehe die beiden Auzuege aus den DRAM Datenblatt in ein paar Antworten weiter oben. Eigentlich relativ einfach, aber CPLD-tauglich krieg ich es nicht hin :( :(
Im ersten Bild sieht WE aus, wie WE = ~(FWE | CCAS) FWE und CCAS per NOR verknüpft. Damit ist WE high wenn beide low sind.
Angehängte Dateien:
-
mk_simple_CASRAS.png
3,6 KB
Hier das ein normaler Schreibzyklus (siehe Anhang), WE low nach dem fallenden RAS und noch vor dem fallenden CAS. Ich hatte dann ein vereinfachte Variante (siehe Anhang) angedacht, die keine Verzoegerungen mehr benoetigt. Das Problem ist aber dass der WE jetzt erst zu spaet auf LOW geht, naemlich immer nur beim fallenden CAS. Das ist zwar fuer einen korrekten CAS-before-RAS-refresh perfekt, aber leider nicht fuer einen normalen Schreibzugriff.
Angehängte Dateien:
-
mk_write_cycle.png
45 KB
Sorry hatte das Bild fuer den Write Zugriff vergessen...
Dann musst du noch eine Logik reinbauen wie zwischen RAS before CAS und CAS before RAS unterscheidet. Kleine State Machine oder so
Angehängte Dateien:
-
mk_write_cycle.png
45 KB
Torben K. schrieb: > Im ersten Bild sieht WE aus, wie WE = ~(FWE | CCAS) > > FWE und CCAS per NOR verknüpft. Damit ist WE high wenn beide low sind. Das ist richtig, damit funktioniert der CAS-before-RAS refresh, aber fuer einen normalen Schreibzyklus klappt es nicht, da kommt RAS vor CAS und WE muss nach RAS und noch vor CAS auf LOW sein. :( In dem Fall mit NOR waere WE erst beim CCAS auf LOW und das waere dann zu spaet, siehe das Write Cycle Timing in der Antwort.
Torben K. schrieb: > Dann musst du noch eine Logik reinbauen wie zwischen RAS before CAS und > CAS before RAS unterscheidet. Kleine State Machine oder so Klingt verlockend, aber wie code ich sowas in VHDL... Ich denke ueber eine Schematic in ISE bekomme ich das nicht hin. Waere es ueber einen Process meoglich z.b. ueber verschachtelte IFs ? Ich muss dazu sagen ich habe erst ein paar Zeilen VHDL selbst gecodet, meist Tutorials modifiziert etc. Dachte mir meine simple TTL Logik sollte kein Problem sein, bin aber nun ein besseren belehrt worden, denn "Kulturschock" von der "heilen" TTL in die CPLD Logik muss ich erst mal verkraften... bzw. will ich meistern...
Einen Mealy- oder Moore-Automat kannst du auch als Schematic malen. In Verilog würde es in etwa so aussehen (kann kein VHDL und in Verilog noch jung):
1 | reg [1:0] state; |
2 | |
3 | always @(negedge CCAS or negedge CRAS) |
4 | begin |
5 | if (CCAS & CRAS) state <= 2'b00; // Ausgangszustand |
6 | if (CCAS & !CRAS & state == 2'b00) state <= 2'b01; // RAS before CAS |
7 | if (!CCAS & CRAS & state == 2'b00) state <= 2'b10; // CAS before RAS |
8 | if (!CCAS & !CRAS & state != 2'b00) state <= 2'b11;// Beide low |
9 | ... |
10 | end |
Das kann man auch malen, eine Eingangslogik vor den zwei FF, die Eingangssignale & FF-Ausgangssignale entsprechend der Logiktabelle verknüpft und die Eingangssignale des FF entsprechend setzt. Im Prinzip wie ein Quadratur Decoder der linksrum und rechtsrum erkennt
:
Bearbeitet durch User
Ok, ich denke ich habe die Funktionsweise der Statemachine in aus dem Code entnommen, auch wenn ich den Verilog Syntax nicht kenne. Werde heute versuchen das in VHDL zu coden (mal schauen wie weit ich komme). D.h. wenn ich es richtig verstehe hat das "reg" (ist ein FF oder?), den Zustand der Statemachine, d.h. Ich kann den Zustand entsprechend mit dem FWE ver-NOR'en und es müsste passen. Wäre es das selbe wenn ich statt des "reg" zwei FF nehmen von denen das eine HIGH ist wenn CAS-before-RAS, und dass andere wenn RAS-before-CAS, erkannt wurde ? Frage zum Code bzw. dem CPLD Verhalten, da erwähnt wurde, dass zeitlich Abläufe ein Prolem sein können und das CPLD sehr schnell ist, der Code bedeutet ja wenn eine negative Flanke für CAS oder RAS erkannt wurde wird dann das "reg" entsprechend gesetzt indem CAS und RAS mit UND verknuepft werden, wie klappt das? Das würde ja bedeuten, dass nach der Flankenerkennung "zeitlich etwas verzoegert" das korrekte LOW und HIGH bei RAS und CAS schon vorliegt, ansonsten (wenn das CPLD sehr schnell ist) wäre in CAS oder RAS keine LOW oder HIGH sondern in dem Moment noch der Flankenübergangszustand ? Wäre echt nett wenn ihr mit das erkärt ich glaube an der Stelle habe ich als "konkreter-TTL-Logiker" noch meine Denkprobleme... ;) Vielen herzlichen Dank nochmal für den bisherigen Support!!!! Alex.
AppleII E. schrieb: > D.h. wenn ich es richtig verstehe hat das "reg" (ist ein FF oder?), den > Zustand der Statemachine, d.h. Ich kann den Zustand entsprechend mit dem > FWE ver-NOR'en und es müsste passen. Wäre es das selbe wenn ich statt > des "reg" zwei FF nehmen von denen das eine HIGH ist wenn > CAS-before-RAS, und dass andere wenn RAS-before-CAS, erkannt wurde ? Du, das ist das selbe. Die Synthesetools machen aus reg immer FFs. Schau dir mal ein Schaltbild zu nem Mealy-Automaten an, dann weißt du was ich meine :) Sobald eine Flanke auftritt wird das FF gesetzt (mit paar ns Verzögerung, CPLD eben)
1 | always @(negedge CCAS or negedge CRAS) |
das geht nicht, denn dafür braucht es ein FF mit 2 Clock Eingängen. Und da du auf beide Signale reagieren willst, egal was der Zustand des anderen Signals ist, gibt es auch keine Chance das zu implementieren.
Würde es mit zwei getrennten FF funktionieren. Keine Chance zum Implementieren hoffe ich ist nicht auf den kompletten Sachverhalt bezogen, sonst hätte es nie funktionierende Async DRAM COntroller gegeben :) :)
Lattice User schrieb: > das geht nicht, denn dafür braucht es ein FF mit 2 Clock Eingängen. > Und da du auf beide Signale reagieren willst, egal was der Zustand des > anderen Signals ist, gibt es auch keine Chance das zu implementieren. Dann eben ein FF pro Signal welches das andere sperrt. Das muß rein asynchron machbar sein, CPLD sind wie früher die PAL/GAL für asynchrones Design geeignet. Es sei denn, ich habe einen Takt von außen.
AppleII E. schrieb: > Würde es mit zwei getrennten FF funktionieren. Keine Chance zum > Implementieren hoffe ich ist nicht auf den kompletten Sachverhalt > bezogen, Ist es nicht, nur auf die spezifische Methode. Wir sehen hier nur einen Ausschnitt aus deinem Async DRAM Controller, man sollte aber das ganze Konzept an den CPLD anpassen. Wie werden z.B. CCAS, CRAS erzeugt? Ich würde ürigens einen synchronen Controller bauen, mit 32 oder 50 MHz hat man 16 bzw 25 Zyklen pro Phase der AppleII Clock. In der 1. Phase macht man den Refresh, in der 2. den eigentlichen Zugriff. Der AppleII interne DRAM macht es auch so.
An und für sich hat in dem Fall der Apple IIGS einen DRAM controller, der auch prima für bis zu 1Mbit DRAMs CAS, RAS und FWE erzeugt. Nur war er damals nur für die 1Mit DRAMs ausgelegt. Die kannten keinen Testmode während eines CAS before RAS refresh war das WE signal deshalb völlig irrelevant. Ab den 4Mbit DRAMs kam der Test mode dazu der quasi wie der CAS before RAS angesteuert wird, und dann aktiv wird wenn WE LOW ist. Und genau den Testmode gilt es zu vermeiden in dem bein CAS before RAS refresh WE definitv HIGH ist. Genau diese Problemstellung ist es. Mit der 74F00 und 74F74 TTL Schaltung oben hat es prima funktioniert. Ich habe keinen zusätzlichen Taktmöglichkeiten (ausser dem PHI2). Es muss also auch asynchron funktionieren. Wär ja ein schlechter Scherz wenn man mit CPLD keine simple Aufgabe die zwei uralte 74F TTLs lösen hinekommen könnte. Ähm, ich hab es nur nicht geschafft, siehe Glitch Problematik oben. Ich habe schon gehofft, dass die dual FF Lösung ein Ausweg wäre.
Angehängte Dateien:
-
c4r.png
4,6 KB
Spannend. Sowas? Ein Flipflop, das mit der fallenden /CCAS-Flanke den Zustand von /CRAS übernimmt. Ist /CRAS zu dem Zeitpunkt H ist Q = H (CAS before RAS), ist /CRAS schon L ist Q = L (RAS before CAS). Nur mal auf die Schnelle gedacht. Im Prinzip wie deine Anfangsschaltung, nur ohne die Verzögerungglieder. Wann darf denn WE wieder low werden?
:
Bearbeitet durch User
AppleII E. schrieb: > An und für sich hat in dem Fall der Apple IIGS einen DRAM controller, Den IIGS kenne ich nicht. > > Ich habe keinen zusätzlichen Taktmöglichkeiten (ausser dem PHI2). Ein Oscillator kostet nicht die Welt. > wenn man mit CPLD keine simple Aufgabe die zwei uralte 74F TTLs lösen > hinekommen könnte. Ähm, ich hab es nur nicht geschafft, siehe Glitch > Problematik oben. Der CPLD ist für komplexe Aufgaben gedacht, solche Trickschaltungen wie mit deinen 74F lassen sich nicht so einfach nachbilden. Ausserdem ist das ganze ja auch Zeitkritisch, sonst täte es auch 74LS. Das heisst jetzt aber nicht, die Flinte ins Korn zu werden. Der Gegner ist hier die Optimierung durch die Toolchain. Schaltplan Eingabe (bzw VHDL oder Verilog) lassen einem nicht viel Möglichkeiten Details zu beinflussen. Eventuell gibt es Constraints um das Zusammenfassen von Logik zu verhindern. Im schlimmsten Fall ein Signal auf einen Ausgang und dann wieder zurück auf einen Eingang. Wenn man auch RAS und CAS über das CPLD führt, lässt sich das Timing etwas entspannen und man braucht weniger Tricks.
WE muss wieder low werden wenn FWE low ist, UND ein RAS before CAS vorliegt. Das ist dann auch schon so ziemlich alles.
Lattice User schrieb: > AppleII E. schrieb: >> An und für sich hat in dem Fall der Apple IIGS einen DRAM controller, > > Den IIGS kenne ich nicht. Ist eine lustige Machine und das Ende der Apple II line. Damals gab es auch noch vernueftige Manuals incl. aller Schaltplaene und Timings :) Apple IIGS Hardware reference nannte sich das. Hm, gute alte Zeit ;) >> >> Ich habe keinen zusätzlichen Taktmöglichkeiten (ausser dem PHI2). > > Ein Oscillator kostet nicht die Welt. Das ist schon richtig. Hab nur voreilig schon PCBs machen lassen, weil ich dachte meine Logic krieg ich schon noch hin, der Rest im CPLD ist ein LS245, ein MUX fuer die Bank Adress. Das funzt auch alles prima. >> wenn man mit CPLD keine simple Aufgabe die zwei uralte 74F TTLs lösen >> hinekommen könnte. Ähm, ich hab es nur nicht geschafft, siehe Glitch >> Problematik oben. > > Der CPLD ist für komplexe Aufgaben gedacht, solche Trickschaltungen wie > mit deinen 74F lassen sich nicht so einfach nachbilden. Ausserdem ist > das ganze ja auch Zeitkritisch, sonst täte es auch 74LS. Voellig richtig, WE muss innerhalb von max. 20ns vor dem RAS low als high vorliegen. LS war da zu langsam. > Das heisst jetzt aber nicht, die Flinte ins Korn zu werden. Der Gegner > ist hier die Optimierung durch die Toolchain. Schaltplan Eingabe (bzw > VHDL oder Verilog) lassen einem nicht viel Möglichkeiten Details zu > beinflussen. > Eventuell gibt es Constraints um das Zusammenfassen von Logik zu > verhindern. Im schlimmsten Fall ein Signal auf einen Ausgang und dann > wieder zurück auf einen Eingang. > > Wenn man auch RAS und CAS über das CPLD führt, lässt sich das Timing > etwas entspannen und man braucht weniger Tricks. Ok.
Torben K. schrieb: > Spannend. Sowas? > > Ein Flipflop, das mit der fallenden /CCAS-Flanke den Zustand von /CRAS > übernimmt. Ist /CRAS zu dem Zeitpunkt H ist Q = H (CAS before RAS), ist > /CRAS schon L ist Q = L (RAS before CAS). > > Nur mal auf die Schnelle gedacht. > > Im Prinzip wie deine Anfangsschaltung, nur ohne die Verzögerungglieder. > Wann darf denn WE wieder low werden? Hab meinen letzten Versuch von letzter Nach ca. 2:00 ausgegraben ist identisch mit deiner Schaltung :) :) :) Nur fehlte mir dann noch die RAS before CAS Umsetztung bei der WE low sein muss.... Ich rieche es foermlich... die Loesung ist nah !!!
Dann reicht doch ein FF wie oben gemalt? CAS before RAS -> FF high RAS before CAS -> FF low Ausgang mit /WE verodern also in Verilog in etwa so (quick'n'dirty, synthetisierbar):
1 | module top( |
2 | input CCAS, |
3 | input CRAS, |
4 | input FWE, |
5 | output WE, |
6 | output CAS, |
7 | output RAS); |
8 | |
9 | reg CASbeforeRAS; |
10 | |
11 | assign WE = FWE | CASbeforeRAS; |
12 | assign CAS = CCAS; |
13 | assign RAS = CRAS; |
14 | |
15 | always @(negedge CCAS) |
16 | if (CRAS == 1) // CRAS ist noch high zum Zeitpunkt der Flanke |
17 | CASbeforeRAS <= 1; |
18 | else // CRAS ist schon low zum Zeitpunkt der Flanke |
19 | CASbeforeRAS <= 0; |
20 | |
21 | endmodule |
Damit ist WE zusammen mit der CAS-Flanke entweder H (CAS before RAS) oder FWE (RAS before CAS)
:
Bearbeitet durch User
Angehängte Dateien:
-
mk3_simu.png
60 KB -
mk_write_cycle_simu.png
46 KB -
mk_schaltung.png
4,3 KB
Wie gesagt, der CAS-before-RAS funktioniert so, - ABER - beim RAS-before-CAS Schreiben, muss WE schon VOR der fallenden Flanke von CAS low sein, sonst kalppt es nicht, moeglich ware deshalb ein LOW beim RAS in diesem Fall. Hab die Simulation und den RAS-before-CAS WRITE cycle noch als Bilder angehaengt.
Ich sehe in deinem Diagramm keinen zwingenden Zusammenhang zu deiner Aussage, dass WE schon vor CAS low sein muß. Mein DRAM sagt mir:
1 | A write cycle is initiated by the falling edge of CAS and |
2 | WE, whichever occurs last. The input data must be valid |
3 | at or before the falling edge of CAS or WE, whichever |
4 | occurs last. |
Ansonsten bau dir halt nach demselben Schema noch ein RAS before CAS FF welches dir in diesem Fall zusammen mit FWE ein WE = L erzeugt. So schwer sollte dir das jetzt nicht mehr fallen.
:
Bearbeitet durch User
Torben K. schrieb: > Ich sehe in deinem Diagramm keinen zwingenden Zusammenhang zu > deiner > Aussage, dass WE schon vor CAS low sein muß. > > Mein DRAM sagt mir:A write cycle is initiated by the falling edge of CAS > and > WE, whichever occurs last. The input data must be valid > at or before the falling edge of CAS or WE, whichever > occurs last. Im Prinzip hast du Recht, es gibt auch Write Cycle die OE controlled funktionieren, in dem fall ABER ist es immer ein EARLY WRITE Cycle. Der ist wie folgt definiert:
1 | write enable (/W) |
2 | The read or write mode is selected through /W. A logic high on /W selects the read mode, and a logic low selects |
3 | the write mode. The data inputs are disabled when the read mode is selected. When /W goes low prior to CAS |
4 | (early write), data out remains in the high-impedance state for the entire cycle, permitting a write operation with |
5 | OE grounded. |
D.h. das WE schon vor dem CAS low sein muss. > Ansonsten bau dir halt nach demselben Schema noch ein RAS before CAS FF > welches dir in diesem Fall zusammen mit FWE ein WE = L erzeugt. So > schwer sollte dir das jetzt nicht mehr fallen. Da hast du absolut Recht, das hatte ich als naechstes vor ! Hoffe das ich das noch zusammenkriege :)
Erzeuge mal ein Reset für das FF aus RAS und CAS. d.h. wenn RAS low ist und CAS high, das FF resetten.
Angehängte Dateien:
-
mk4.png
4,9 KB
Hallo Leute! Erfolgsmeldung... Ich glaube das war's... Lasse gerade noch im Dauertest den Memorytest die DRAMs quaelen, aber es sieht echt gut aus. Die endgueltige Schaltung im Bild, wenn ichs mir im nachhinein betrachte recht aehnlich zu meinem TTL, nur jetzt mit sauberer Logik-auswertung und ohne CAS Verzoegerungstrick der Laufzeiten... Vielen Dank, fuer die angeregte Diskussion, ich habe echt viel ueber die Besonderheiten bei CPLDs gelernt, was geht und was nicht mehr geht. Fliesst bestimmt in meine neuen Basteleien ein. BTW mit dem XC9536XL -10ns klappt es nicht, der ist einen Tick zu langsam. Mit dem XC9536 -5ns funzt es. Falls ich XC9536XL -10 braucht, ich habe jetzt etliche ueber :) Nochmal Danke, und schoenen Sonntag! Alex.
@AppleII Enthusiast (apple2enthusiast) >Die endgueltige Schaltung im Bild, wenn ichs mir im nachhinein betrachte >recht aehnlich zu meinem TTL, nur jetzt mit sauberer Logik-auswertung >und ohne CAS Verzoegerungstrick der Laufzeiten... Ja, das ist deutlich besser, aber auch hier muss man sicher stellen, daß CRAS und CCAS glitchfrei sind und daß es nicht zu race conditions kommt. Ein sauberes, synchrones Design hat keine Signale, die an Takt und Reset von FlipFlops gehen. Die Taktinvertierung ist OK.
AppleII E. schrieb: > BTW mit dem XC9536XL -10ns klappt es nicht, der ist einen Tick zu > langsam. Mit dem XC9536 -5ns funzt es. Und wenn du den Reset aus CAS = RAS = H generierst? Dann wird das FF schon vor dem nächsten "Anything before anything else" zurückgesetzt, nicht erst nach RAS-before-CAS
Torben K. schrieb: > AppleII E. schrieb: >> BTW mit dem XC9536XL -10ns klappt es nicht, der ist einen Tick zu >> langsam. Mit dem XC9536 -5ns funzt es. > > Und wenn du den Reset aus CAS = RAS = H generierst? Dann wird das FF > schon vor dem nächsten "Anything before anything else" zurückgesetzt, > nicht erst nach RAS-before-CAS Da hast du Recht, das werd ich noch ausprobieren.
Falk B. schrieb: > @AppleII Enthusiast (apple2enthusiast) > >>Die endgueltige Schaltung im Bild, wenn ichs mir im nachhinein betrachte >>recht aehnlich zu meinem TTL, nur jetzt mit sauberer Logik-auswertung >>und ohne CAS Verzoegerungstrick der Laufzeiten... > > Ja, das ist deutlich besser, aber auch hier muss man sicher stellen, daß > CRAS und CCAS glitchfrei sind und daß es nicht zu race conditions kommt. > Ein sauberes, synchrones Design hat keine Signale, die an Takt und Reset > von FlipFlops gehen. Die Taktinvertierung ist OK. CRAS und CCAS kommen vom DRAM controller auf dem Mainboard, der stammt aus einer Zeit vor CPLD und FPGA und ist als echter ASIC ausgelegt. Ich denke wenn ich mit CRAS und CCAS keine "back-feeds" mache sollte es so stabil funktionieren. Was meinst du? Alex.
Torben K. schrieb: > AppleII E. schrieb: >> BTW mit dem XC9536XL -10ns klappt es nicht, der ist einen Tick zu >> langsam. Mit dem XC9536 -5ns funzt es. > > Und wenn du den Reset aus CAS = RAS = H generierst? Dann wird das FF > schon vor dem nächsten "Anything before anything else" zurückgesetzt, > nicht erst nach RAS-before-CAS Funktioniert nicht, da im Falle von CAS vor RAS, das Reset bei der High nach Low Flanke von CAS eventuell noch anliegt, also nicht zuverlässig erkannt wird.
@AppleII Enthusiast (apple2enthusiast) >CRAS und CCAS kommen vom DRAM controller auf dem Mainboard, der stammt >aus einer Zeit vor CPLD und FPGA und ist als echter ASIC ausgelegt. Wenn wir mal annehmen, das die Leute das ordentlich gemacht haben, dann sollte das passen. > Ich >denke wenn ich mit CRAS und CCAS keine "back-feeds" mache sollte es so >stabil funktionieren. Was meinst du? Das allein reicht nicht. Das CLR des FlipFlops ist nur dann glitchfrei, wenn sich CRAS und CCAS nie gleichzeitig ändern, d.h. eines der beiden Signale muss konstant sein, wenn sich das andere ändert, siehe Artikel Glitch. Ein weiteres Problem ist ein potentieller Glitch am Ausgang des FlipFlops. Wenn CRAS = 0 und CCAS = 1 ist, dann ist CLR vom FlipFlop aktiv. Wenn nun CCAS auf 0 wechselt, wird sowohl der Takt für das FlipFlop erzeugt, aber auch das CLR inaktiv. Wahrscheinlich wird die aktive Taktflanke ignoriert und das CLR erst ein paar ns später inaktiv. OK, hier könnte es sicher sein. Allgemein ist sowas aber immer schlecht, weil es kein sauberes, synchrones Design ist. Als Workaround für Retrobasteleien ist es OK.
Falk B. schrieb: > > Das allein reicht nicht. Das CLR des FlipFlops ist nur dann glitchfrei, > wenn sich CRAS und CCAS nie gleichzeitig ändern, d.h. eines der beiden > Signale muss konstant sein, wenn sich das andere ändert, siehe Artikel > Glitch. Ist hier irrelevant, die aktiven Flanken (H>L) von CAS und RAS fallen nie zusammen (das mögen auch die DRAMs nicht), und am Ende des Zugriffs ist es egal was mit dem FF passiert. > > Ein weiteres Problem ist ein potentieller Glitch am Ausgang des > FlipFlops. Wenn CRAS = 0 und CCAS = 1 ist, dann ist CLR vom FlipFlop > aktiv. Wenn nun CCAS auf 0 wechselt, wird sowohl der Takt für das > FlipFlop erzeugt, aber auch das CLR inaktiv. Wahrscheinlich wird die > aktive Taktflanke ignoriert und das CLR erst ein paar ns später inaktiv. > OK, hier könnte es sicher sein. Auch hier kann nichts passieren, da zum Ende des Resets RAS auf Low ist, und es damit egal ist ob die Flanke auf CAS erkannt wird oder nicht. Das FF ist 0 und soll auch 0 bleiben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.