Hallo, folgende Beiträge habe ich schon gelesen: Beitrag "Berechnung der max. Differenz der Leitungslänge" Beitrag "SDRAM Layout, STM32F7" Beitrag "Richtiges SDRAM Layout" Im Anhang ist ein SAME70 Evalboard mit 166MHz SDRAM zu sehen. Ich bin kein Profi und mache jetzt zum ersten mal ein ähnliches Design. Als ich mir die Layouts von verschiedenen Evalboards angeschaut habe (166MHz SDRAM) habe ich auch schön fleißig versucht Meander zu legen wie auf den Evalboards, bis ich gemerkt habe dass ich ein Platzproblem habe. Dann habe ich mal mein Kopf benutzt und bin zu dem selben Ergebnis gekommen wie Falk B. in den o.g. Posts. Die Frage die ich mir dann gestellt habe ist: Wieso geht man denn diesen "aufwendigen" Weg, Meander zu Routen, wenn es noch nicht kritisch ist? Meine Frage bezieht sich speziell auf die Designer der Evalboards mit "langsamen" SDRAM. Grüße Mark B.
Angehängte Dateien:
-
20200701_210908.jpg
390 KB
Mark B. schrieb: > Die Frage die ich mir dann gestellt habe ist: Wieso geht man denn diesen > "aufwendigen" Weg, Meander zu Routen, wenn es noch nicht kritisch ist? Weil es hipp ist, cool aussieht, das CAD-Tool es kann und man auch wenn es Probleme gibt immer sagen kann, man hat sich an die heiligen Vorgaben gehalten.
Mark B. schrieb: > Die Frage die ich mir dann gestellt habe ist: Wieso geht man denn diesen > "aufwendigen" Weg, Meander zu Routen, wenn es noch nicht kritisch ist? > Meine Frage bezieht sich speziell auf die Designer der Evalboards mit > "langsamen" SDRAM. So geht man eben auf Nummer sicher und kann später das Layout ausschließen.
Das war eben tatsächlich auch meine Schlussfolgerung. Wenn es fähige Designer sind, dann kann es ja eigentlich auch nur dieser Grund sein, sich unangreifbar machen. Besten Dank. VG, Mark B.
Mark B. schrieb: > sich unangreifbar machen. Ich glaube er meinte mit René F. schrieb: > kann später das Layout > ausschließen. etwas anderes. Und zwar wenn du eine Schaltung entwirfst, dann gibt es sehr viele Fehlerquellen. Wenn du alles auf Kante nähst dass es gerade so funktionieren müsste, was machst du dann wenn es nicht funktioniert? Dann hast du ganz viele mögliche Fehlerquellen die du alle einzeln überprüfen müsstest was dann aber kaum geht weil die ja zusammenspielen. Wenn du aber z. B. beim Layout lieber auf Nummer sicher gehst und dann die Schaltung funktioniert, dann hast du schon einen Punkt den du als Fehlerquelle ausschließen kannst. Das macht das Debugging einfacher. Ich habe das auch nicht einsehen wollen. Vor allem weiß man als Laie nicht wo die Grenze ist und kann das nicht einschätzen. Bin ich jetzt an der Kante und es funktioniert nur noch mir viel Glück oder habe ich das schon overdesignt? Das ist auch nicht einfach weil man mit mehr Optimierung eigentlich immer zusätzliche Sicherheit bekommen kann, wo soll man die Optimiererei also beenden und zufrieden sein? Und da kommt Erfahrung ins Spiel. Allerdings kostet das Zeit und Geld. Das kannst du aber vielleicht teilweise sparen wenn du dir anguckst was Andere gebaut haben und was auch funktioniert. Z. B. hier: https://sigrok.org/wiki/Sysclk_LWLA1034 Da ist SRAM drauf und wird wohl mit 133 MHz betrieben. Und ja, der SRAM IC ist zwischen FPGA und USB Buchse, also genau dort wo man den USB IC vermuten würde. Aber den USB IC hat man auf dem Bild https://sigrok.org/wimg/2/2b/Sysclk_lwla1034_pcb_top2.jpg über das FPGA gesetzt und zieht das USB2 einmal quer über die Platine auf der Rückseite https://sigrok.org/wimg/9/90/Sysclk_lwla1034_pcb_bottom2.jpg . Funktioniert das fehlerfei? Mit den so unterschiedlich langen Leitungen am SRAM? Klar! Ich habe das Teil hier und war erstmal erschüttert als ich es geöffnet hatte. Aber wenn man überlegt, das sind vielleicht 5 cm Längenunterschied maximal. 30 cm entsprechen 1 ns. Also reden wir von < 200 ps Laufzeitunterschied. Und das bei einer Periodendauer von 7,5 ns. Das ist also in der Tat völlig egal. Schön ist das natürlich nicht und wenn man Zeit hat dann kann man das besser machen. Hier ist 133 MHz DRAM ohne Längenausgleich: https://sigrok.org/wiki/ASIX_OMEGA
Gustl B. schrieb: > Und das bei einer Periodendauer von 7,5 ns. > Das ist also in der Tat völlig egal. Schön ist das natürlich nicht Dieses "Schönheitsempfinden" geht eher in Richtung Pedanterie und Overegineering! "So einfache wie möglich, so genau wie nötig!" Das ist einer der Grundsätze der Ingenieurskunst! > wenn man Zeit hat dann kann man das besser machen. Warum? Um dein Ego zu füttern?
Mark B. schrieb: > Die Frage die ich mir dann gestellt habe ist: Wieso geht man denn diesen > "aufwendigen" Weg, Meander zu Routen, wenn es noch nicht kritisch ist? Auf welche Analysen stützt sich deine Aussage das es nicht kritisch wäre? Genau, auf garkeine oder eine sehr oberflächliche (im wahrsten Sinne des Wortes). Der Skew wird nur zu einem Teil durch die Tracklänge bestimmt, ebenfalls und einen nicht zu geringen Einfluß hat die Homogenität der HF-Eigenschaften (Dielektrizität) des Prepregs und Interne des ansteuernden Schaltkreis. Man kann nicht immer davon ausgehen das der Speicher von einem modernen FPGA getrieben wird, bei dem man das timing in subnano-bereich feinjustieren kann. Noch komplexer wird es bei gesockelten Speicher, etwas was beim SDRAM-Einsatz im PC in den Anfangszeiten üblich war. Und im Unterschied zu beispielsweise CRC abgesicherten Kommunikationskanälen, will man bei SDRAM als Programmspeicher keine Bitfälscher, weil die ggf. das System böse crashen lassen. Du willst doch nicht das dir der Augenlaser statt einer Sehschärfenkorrektur den String "Exception fault" auf die Hornhaut nagelt ;-) Und dann kommt die Frage nach den möglichen Kosten und Zeitaufwand für einen PCB-Respin. Also wenn die Annahme über ist nicht kritisch zu leichtsinnig war und der Speicher läuft nicht sabil, dann muss ein neues PCB gemacht werden, auf das man 4 Wochen warten darf ... Da ein ausführliches Beispiel für die Berechnung/Analyse des skew-budgets: https://www.nxp.com/docs/en/application-note/AN1722.pdf Auf die dort gezeigte Weise schätzt man das Risiko mit Kopf ab, und nicht nach Pi*Daumen/Fensterkreuz.
Falk B. schrieb: > "So einfache wie möglich, so genau wie nötig!" Vollkommen richtig. Das bedeutet aber nicht, dass man es so baut, dass es gerade so funktioniert, sondern so, dass es zuverlässig funktioniert. Dieser kleine Unterschied ist für einen Laien wie mich aber sehr schwierig weil die Grenzen unbekannt sind.
:
Bearbeitet durch User
C. A. Rotwang schrieb: > Noch komplexer wird es bei gesockelten Speicher, etwas was beim > SDRAM-Einsatz im PC in den Anfangszeiten üblich war. Was ist denn gesockelter SDRAM. Gibt oder gab es diesen überhaupt? Also in der Bauform DIP/DIL? Evtl. PLCC oder ähnlich? Ausser Du meinst SDRAM auf einer Modulplatine die wiederum in einen Modulsockel kommt, das war aber nicht in den Anfangszeiten. Gruß
:
Bearbeitet durch User
Michael K. schrieb: > Was ist denn gesockelter SDRAM. Gibt oder gab es diesen überhaupt? Also > in der Bauform DIP/DIL? Evtl. PLCC oder ähnlich? Ein DIMM, wie er millardenfach benutzt wird. https://www.elektronik-kompendium.de/sites/com/1409031.htm
Falk B. schrieb: > Ein DIMM, wie er millardenfach benutzt wird. Wie ich es schon schrieb: Michael K. schrieb: > Ausser Du meinst SDRAM auf einer Modulplatine die wiederum in einen > Modulsockel kommt, das war aber nicht in den Anfangszeiten. Und ob millardenfach in Zusammhang mit SDRam Modulen zutreffend ist, nun ja.... Und PC Anfangszeit müsste man auch mal definieren. Gruß
Mark B. schrieb: > Die Frage die ich mir dann gestellt habe ist: Wieso geht man denn diesen > "aufwendigen" Weg, Meander zu Routen, wenn es noch nicht kritisch ist? > Meine Frage bezieht sich speziell auf die Designer der Evalboards mit > "langsamen" SDRAM. Ist denn dieser Weg überhaupt so aufwendig? Weg 1: Längenausgleich mittels Meander. Vorteil: Man verbessert insgesamt das Verhalten und die Zuverlässigkeit der Baugruppe. Oder anders: Man erhöht die Toleranz gg. Abweichungen aller Art. Nachteil: Der Einstiegslevel liegt halt höher und das richtige Werkzeug ist auch teurer. Weg 2: Längenausgleich einfach ignorieren. Vorteil: Weniger Einlernzeit, billigere SW, evtl. günstigere LP. Nachteil: Weniger Toleranz gg. andere Fehler, evtl. Fehlfunktion und Unsicherheit ob man es nicht doch zu locker gesehen hat. Aus meiner Sicht ist Weg 1 letztendlich leichter. Die Anfangsinvestition ist natürlich höher, aber auf Dauer bekommt man dies gutverzinst zurück. Gruß
Michael K. schrieb: > Man erhöht die Toleranz gg. Abweichungen > aller Art. Es ist auch eine schlechte Idee, das Gesamtbudget an erlaubten Toleranzen schon an einem einzigen Punkt aus reiner Faulheit aufzubrauchen. Michael K. schrieb: > Längenausgleich einfach ignorieren. Das ist die Methode Falk. Alles was mehr als 50 Hz benötigt ist nicht nur Voodoo, sondern es braucht auch kein Mensch. Die Designer von Motherboards oder Handyplatinen haben alle keine Ahnung, jedenfalls nicht so viel wie Falk. Georg
Michael K. schrieb: > Und PC Anfangszeit müsste man auch mal definieren. Nein, da muss man nachlesen -> 20. August 1981 https://de.wikipedia.org/wiki/IBM_Personal_Computer Da ein Blick aufs motherboard: https://en.wikipedia.org/wiki/IBM_Personal_Computer#/media/File:IBM_PC_Motherboard_(1981).jpg wobei dessen RAM wahrscheinlich noch DRAM statt SDRAM ist. SDRAM wurde ca. 1992 eingeführt, da hatte man PC, XT und AT hinter sich und war schon im 32 bit Zeitalter angekommen.
Kurator schrieb: > wobei dessen RAM wahrscheinlich noch DRAM statt SDRAM ist. SDRAM wurde > ca. 1992 eingeführt, da hatte man PC, XT und AT hinter sich und war > schon im 32 bit Zeitalter angekommen. Nicht wahrscheilich sondern mit Sicherheit DRAM. SDRam kam auf mit dem Pentium 1. 486er mit SDRam sind mir nicht bekannt. Gruß
georg schrieb: >> Längenausgleich einfach ignorieren. > > Das ist die Methode Falk. Alles was mehr als 50 Hz benötigt ist nicht > nur Voodoo, sondern es braucht auch kein Mensch. Die Designer von > Motherboards oder Handyplatinen haben alle keine Ahnung, jedenfalls > nicht so viel wie Falk. Das mit dem sinnerfassenden Lesen musst du noch mal üben. "Du schaffst das!" (tm) Ich habe mich mit keiner Silbe GEGEN einen Längenausgleich ausgesprochen, wohl aber immer wieder ein relistisches Augenmaß dabei eingefordert. Denn der Längenausgleich ist ein ähnlicher Fetisch wie eine Massefläche, wo jeder Hobbybastler mit drei LEDs meint, ohne diese keine brauchbare Platine hinzukriegen. Ebenso ist Längenausgleich kein Wundermittel und Selbstläufer, man kann da auch einiges vermurksen, vor allem wenn man krampfhaft auf sub-Millimeter die Längen ausgleichen will. Alles schon erlebt.
Falk B. schrieb: > Das mit dem sinnerfassenden Lesen musst du noch mal üben Du kannst ja nicht mal die Überschrift erfassen, da ist von SDRAM die Rede und nicht von 3 LEDs. Die Dinosaurier haben sicher auch auf den Meteoriten geschaut und gesagt "das kann nicht sein, das hats früher nie gegeben - das ignorieren wir einfach". Natürlich kann man Elektronik im Stil der 60er Jahre konstruieren, allerdings wahrscheinlich keine SDRAM-Platine. Suum cuique. Georg
Angehängte Dateien:
Hallo, wie ich sehe habe ich wohl eine kleine Diskussion entfacht. Es sind aber leider Antworten dabei, die gefühlt überhaupt nichts mit meiner Frage zu tun haben: 1981, 1992, Pentium 1... Michael K. schrieb: > Nachteil: Der Einstiegslevel liegt halt höher und das richtige Werkzeug > ist auch teurer. Naja, ich nutze Kicad und die Meanderfunktion macht einen guten Eindruck und lässt sich auch einfach bedienen. Das klingt jetzt etwas widersprüchlich, wo ich doch das Wort "aufwendig" benutzt habe. Ich scheue den Aufwand auch nicht. Ich hinterfrage nur und möchte dazu lernen. Da ich bei meinen Prototypen gerne auch mal meinen Kopf benutze und nicht einfach irgendwelche Evalboarddesigns übernehmen möchte, wollte ich mir das nochmal genauer anschauen. (Ja richtig, auch wenn das für Einige klar ist). Was die ganze Timingausrechnerei angeht habe ich noch nicht die nötige Praxiserfahrung. Das wollte ich jetzt mal ändern und habe angefangen mir für die Zukunft eine kleine Exceltabelle zu erstellen, u.a. mit Hilfe diesen Beitrags (ich weiß es gibt echt gute Leute unter euch, die das mal eben im Kopf ausrechnen und diesen Excelkram nicht brauchen): https://www.mikrocontroller.net/articles/SDRAM-Timing Da kommt mir etwas komisch vor, siehe Bild im Anhang. Kann das mal bitte jemand prüfen? Warum spielt denn bei dem Schreibzugriff die Ausgabezeit des SDRAM eine Rolle? Jedenfalls - Beim genauen Lesen der Datenblätter stößt man dann plötzlich auf Data-input-setup-Zeiten von 8ns. Da frage ich mich wie kann das sein. Ein ach so toller 600MHz Mikrocontroller (RT1064) und ein 166MHz SDRAM (IS42S16160J-6BLI). Man könnte aber auch 0.6ns haben wenn man den uC mit einem Strobe-Signal speisen würde. Und ausgerechnet dieser Pin des uCs wird auf dem Evalboard nicht benutzt.
Mark B. schrieb: > Naja, ich nutze Kicad und die Meanderfunktion macht einen guten Eindruck > und lässt sich auch einfach bedienen. Das ist doch schon mal was. Und 166MHz SDRam Clk ist auch kein Hexenwerk. Setze CPU und Ram einigermassen dicht beieinander, drehe sie sinvoll zueinander und beachte die Routeprioritäten des Herstellers. Ich setze mal als minimum 4 Lagen an, 6 Lagen sind eine Erleichterung. Ein angepasster Lagenaufbau ist auch nützlich. Stichwort Impedanz. Ein Längenausgleich auf +/- 8mm in Relation zur Clk Leitung (=Referenz) würde ich als ausreichend ansehen. Auf geht's Frage noch: Ist der E70 der konkrete Chip oder nur ein Beispiel?
Michael K. schrieb: > Ist denn dieser Weg überhaupt so aufwendig? > > Weg 1: Längenausgleich mittels Meander. ... > Weg 2: Längenausgleich einfach ignorieren. ... Weg 3: erstmal die beteiligten Leitungen, deren erforderlichen Zeitrahmen und deren Länge näher anschauen und ggf. den SDRAM etwas umplazieren und dann besser routen. Zumeist hilft das bei dem Zeugs, was man am µC benutzt, bereits sehr, um die Längendifferenzen so klein zu halten, daß sie entweder keine oder nur ne marginale Rolle spielen. W.S.
W.S. schrieb: > Zumeist hilft das bei dem Zeugs, was > man am µC benutzt, bereits sehr, um die Längendifferenzen so klein zu > halten, daß sie entweder keine oder nur ne marginale Rolle spielen. Auch eine Möglichkeit, aber unterhalb welcher Differenz beginnt denn Marginal?
:
Bearbeitet durch User
Mark B. schrieb: > Da kommt mir etwas komisch vor, siehe Bild im Anhang. Kann das mal bitte > jemand prüfen? Prüf doch selber, oben gibt es einen Link zu Details der Speicherinterface-Berechnung. Und als nächstes schaust Du mal mit dem scope wie die Signale tatsächlich aussehen. Dann kommst du sicher schnell drauf das die Flankenzeiten auch in Rechnung einfliessen. Und wenn du schon die Flanken und damit den Umschaltpunkt zwischen '1' und '0' im Eye hast, überlegst du mal was passiert wenn der Datenbus heftig schaltet (Zufallsfolge PRBS23 ist so ein Klassiker beim RAM ausmessen) und der Ausgangspegel am Ausgang einbricht. von den vermeidlichen 6 ns Timingreserve bleibt da nicht viel übrig. Alsosolltest Du dir was einfallen lassen, wie du den Pegel stützt. Ach ja, Terminierung will auch beachtet werden, bringt zwar nicht unbedingt viel, aber wenn man sonst schon alles auf Kante näht, könnten gerade dort die entscheidenden 500 ps verloren gehen. Aber auch dazu finden sich Erklärungen im erwähnten Link.
Michael K. schrieb: > Auch eine Möglichkeit, aber unterhalb welcher Differenz beginnt denn > Marginal? Wenn es in den min..max Angaben des IC-Herstellers liegt. W.S.
Michael K. schrieb: > Sind das nicht eher IL 140mm bzw AL 165mm /ns?! https://de.wikibooks.org/wiki/Digitale_Schaltungstechnik/_Signallaufzeit/_Leitungen Also so 20 cm/ns.
Gustl B. schrieb: > Michael K. schrieb: >> Sind das nicht eher IL 140mm bzw AL 165mm /ns?! > > https://de.wikibooks.org/wiki/Digitale_Schaltungstechnik/_Signallaufzeit/_Leitungen > > Also so 20 cm/ns. Da wird aber die Rechnung ohne parasitäre Kapazitäten gemacht. Diese Formel kann man benutzen wenn man ein frei in Luft hängendes Stück Draht als Verzögerungselement benutzt, bei tracks auf dem PCB dagegen gilt es den 'Kondensator' aus Signal-track, GND-plane und PCB-Dieelektrikum mit umzuladen, was sich im Oszilloskopbild als verschliefene Flanke darstellt und so am Zeit-Budget frisst. Und darauf kommt es bei digitalen Signalen an. Bei analogen Signalen auf Leitungen dagen schaut man sich lediglich den Verkürzungsfaktor (velocity rate) an.
Angehängte Dateien:
-
pcb03.JPG
82 KB
Gustl B. schrieb: > Also so 20 cm/ns. Die Formeln samt Ergebnis im Anhang. Gruß
Hallo, der E70 war nur ein Beispiel weil ich den zuerst nehmen wollte. Jetzt wird es ein Rt1064. Es wird auch mindestens eine 6 lagige PCB und der SDRAM liegt schon sehr nahe am uC weil die Abmessungen der Platine sehr klein sind und noch Kamera und LCD Signale geroutet werden müssen. Aber das ist nicht der Punkt. Kann mir jemand sagen wie ich herausfinden kann wer den Artikel geschrieben hat? https://www.mikrocontroller.net/articles/SDRAM-Timing Oben steht nur "Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)". Wo finde ich die Versionsgeschichte? Da muss doch irgendjemand von euch direkt sehen ob es sich da um einen Tippfehler handelt oder doch richtig ist.
Michael K. schrieb: > Gustl B. schrieb: >> Also so 20 cm/ns. > Die Formeln samt Ergebnis im Anhang. Der angenommene Er gilt für LP in FR4. Mit speziellen Materialien wie z.B. Rogers gehen auch noch andere Werte, dies dürfte für diesen Thread hier aber keine Rolle spielen. Ausserdem kann der Er für die AL noch mit dem Material und der Dicke des Lötstoplackes variieren. Als gute Faustformel taugen die Werte aber schon. Gruß
:
Bearbeitet durch User
Mark B. schrieb: > Kann mir jemand sagen wie ich herausfinden kann wer den Artikel > geschrieben hat? Das war ich, vor langer Zeit. Und naja, so dolle ist er nicht geraten, da fehlen aussagekräftige Bilder 8-0 >Oben steht nur "Aus der Mikrocontroller.net Artikelsammlung, mit >Beiträgen verschiedener Autoren (siehe Versionsgeschichte)". Wo finde >ich die Versionsgeschichte? https://www.mikrocontroller.net/wikisoftware/index.php?title=SDRAM-Timing&action=history Und ja, das ist ein Tippfehler, SDRAM und uC wurden verwechselt. Gut aufgepaßt und mitgedacht!
Mark B. schrieb: > der E70 war nur ein Beispiel weil ich den zuerst nehmen wollte. Jetzt > wird es ein Rt1064. Habe mir gerade das Kurzdatenblatt zum RT1064 angeschaut. Zitat: 'The SEMC is a multi-standard memory controller optimized for both high-performance and low pin-count. It can support multiple external memories in the same application with shared address and data pins. The interface supported includes SDRAM, NOR Flash, SRAM, and NAND Flash, as well as 8080 display interface.' Das heisst dann wohl der SDRam Speicher teilt sich die Leitungen mit den anderen Speichertypen. Das macht die Sache nicht einfacher. Grundsätzlich gilt vor allem das SDRam auf einem abfallenden Ast sitzt. Die großen Hersteller haben sich da schon länger zurückgezogen. Das bedeutet Mittel bis Langfristig Lieferprobleme und steigende Preise. Selbst DDR(1) ist eigentlich schon überholt. Gruß
Michael K. schrieb: > Das macht die Sache nicht einfacher. > Grundsätzlich gilt vor allem das SDRam auf einem abfallenden Ast sitzt. > Die großen Hersteller haben sich da schon länger zurückgezogen. Das > bedeutet Mittel bis Langfristig Lieferprobleme und steigende Preise. > Selbst DDR(1) ist eigentlich schon überholt. Mag sein, aber es gibt sogar noch SRAM. Nicht an jeden kleinen bis mittelgroßen Mikrocontroller oder Mikroprozessor kann und will man GDDR5 RAM anschließen ;-) Selbst der NE555 ist nach über 50 (?) Jahren noch im Geschäft. SDRAM wird es auch noch mindestens 10 Jahre, eher mehr. Daß die Mengen und Marktanteile kleiner werden ist da nebensächlich.
Falk B. schrieb: > Mag sein, aber es gibt sogar noch SRAM. Da kann ich keinen Zusammenhang erkennen. Falk B. schrieb: > Selbst der NE555 ist nach über 50 (?) Jahren noch im Geschäft. Das mag stimmen, geht aber am Thema vorbei. Falk B. schrieb: > Nicht an jeden kleinen bis > mittelgroßen Mikrocontroller oder Mikroprozessor kann und will man GDDR5 > RAM anschließen ;-) Ob man es kann oder will entscheidet letztendlich der Markt. Wenn es einfach keine Chips mehr gibt geht der Ofen halt aus. Und bei SDRam habe ich jahrelang die Abkündigungen bekommen, jetzt gibt es nicht mal mehr diese. Es bleiben halt die üblichen Nischenhersteller, wie z.B. die Eingangsfoto erkennbare Fa. ISSI. Aber auch die müssen irgendwann upgraden, dann bleiben halt noch die Broker, viel Spass bei Qualität und Preis. Man muss einfach grundsätzlich verstehen das der Markt für DRams im wahrsten Sinne dynamich ist und nicht vergleichbar mit anderen Bauteilen. Daher ist es keine gute Idee jetzt noch auf 15 bis 20 Jahre alte Technologie zu setzen. Aktuell lichten sich bereits 2 Generationen weiter, also DDR2, die Reihen erheblich. Die aktuelle, in der Industrie angewandte Technik lautet DDR3(L). Hier ergibt sich auch das beste PLV. Ein Verweis auf GDDR5 halte ich für daneben. Und ja, es ist durchaus möglich CPU's mit SDRam Interface mit DDR2 zu verheiraten. Auch hier gilt wieder: Die Anfangsinvestition ist natürlich höher, aber auf Dauer bekommt man dies gutverzinst zurück. Gruß
:
Bearbeitet durch User
Es gibt auch memory controller die Verzögerungen (pro Bytegruppe oder sogar pro Bit) per Software einstellen können. Das entspannt das Routing auf der Leiterkarte deutlich da man damit nochmal feinjustieren kann.
Michael K. schrieb: > Falk B. schrieb: >> Mag sein, aber es gibt sogar noch SRAM. > > Da kann ich keinen Zusammenhang erkennen. SRAM ist noch älter als SDRAM und trotzdem noch verfügbar! >> Nicht an jeden kleinen bis >> mittelgroßen Mikrocontroller oder Mikroprozessor kann und will man GDDR5 >> RAM anschließen ;-) > > Ob man es kann oder will entscheidet letztendlich der Markt. Nö, die Technologie und der Preis. >Wenn es > einfach keine Chips mehr gibt geht der Ofen halt aus. > Und bei SDRam habe ich jahrelang die Abkündigungen bekommen, jetzt gibt > es nicht mal mehr diese. Es bleiben halt die üblichen Nischenhersteller, > wie z.B. die Eingangsfoto erkennbare Fa. ISSI. > Aber auch die müssen irgendwann upgraden, dann bleiben halt noch die > Broker, viel Spass bei Qualität und Preis. Stimmt. Aber dann ist das halt so. Das sind aber "nur" Probleme bei langlebigen Produkten wie INdustrieelektronik, Bahntechnik, etc. Der Konsumerkram läuft in DEUTLICH kürzeren Lebenszyklen und nutzt meist aktuelle, wenn nicht gar brandneue ICs. > Man muss einfach grundsätzlich verstehen das der Markt für DRams im > wahrsten Sinne dynamich ist und nicht vergleichbar mit anderen > Bauteilen. Sicher. > Daher ist es keine gute Idee jetzt noch auf 15 bis 20 Jahre alte > Technologie zu setzen. Im Prinzip ja, aber manchmal gibt es nur wenig Alternativen. Und eine bekannte, bewährte Lösung in Form eines "alten" Mikrocontrollers etc. hat da, zumindest aus Sicher der Entwicklung, deutlich Vorteile. Aus sicht der Langzeitverfügbarkeit sieht's halt anders aus 8-0 > Aktuell lichten sich bereits 2 Generationen weiter, also DDR2, die > Reihen erheblich. > Die aktuelle, in der Industrie angewandte Technik lautet DDR3(L). Hier > ergibt sich auch das beste PLV. > Ein Verweis auf GDDR5 halte ich für daneben. Es war ein übertriebenes Beispiel. Und dennoch, es gibt genügend Anwendungen unterhalb der DDR3 Speicherklasse. > Und ja, es ist durchaus möglich CPU's mit SDRam Interface mit DDR2 zu > verheiraten. Na dann mal viel Spaß! > Auch hier gilt wieder: Die Anfangsinvestition ist natürlich höher, aber > auf Dauer bekommt man dies gutverzinst zurück. Das kann man so allgemein gar nicht sagen! So eine Brücke von SDRAM auf DDR2 baut man nicht einfach mal so! Das lohnt sich bestenfalls bei hohen und HÖCHSTEN Stückzahlen! Bauteilverfügbarkeit ist wichtig, aber sie ist nicht das Einzige Kriterium zur Auswahl von Bauteilen.
Angehängte Dateien:
-
SDRAM_Flanken.png
160 KB
Hallo, seht euch mal bitte das angehängte Bild an. Werden die Daten am µC wirklich bei der fallenden Flanke ausgegeben und bei der darauf folgenden steigenden Flanke am SDRAM Daten eingelesen oder ist das im Datenblatt des µCs falsch?
Falk B. schrieb: > Das kann man so allgemein gar nicht sagen! So eine Brücke von SDRAM auf > DDR2 baut man nicht einfach mal so! Ich habe die Hardware in Form von CPU E70 mit DDR2 innerhalb von 3 Tagen entworfen. Das ist natürlich nicht die gesamte Entwicklungszeit, sondern nur der Teil zur Ram Anbindung im Schaltplan. Mehr Probleme machte die übliche Linux Boot SW, die wollte partout das Ram nicht kennen. Da musste der Programmierer dann händisch ran, hat irgenwas um eine Woche gebraucht. Man muss halt akzeptieren das man die Hälfte der Speicherkapazität verliert, das ist aber OK, billiger ist es immer noch. Das Sparvolumen beträgt für mich einige tausend Eur im Jahr, mit steigender Tendenz. ++++++++++++++++++++++++++++++ Wie so viele Threads hier im Form schwächelt auch dieser an fehlenden Infos bzw. einer Zielvorgabe des TO, wie z.B: Hobby/Gewerblich? Stückzahl? Wie lange soll geliefert werden? Erfahrung bzw. Wissen des TO? So lange man dies alles nicht hat ist es schon ein wenig stochern im Nebel. Gruß
Michael K. schrieb: > Wie so viele Threads hier im Form schwächelt auch dieser an fehlenden > Infos bzw. einer Zielvorgabe des TO, wie z.B: > Hobby/Gewerblich? > Stückzahl? > Wie lange soll geliefert werden? > Erfahrung bzw. Wissen des TO? > So lange man dies alles nicht hat ist es schon ein wenig stochern im > Nebel. Meiner Meinung nach schwächeln die meisten Threads an kurzen knackigen hilfreichen Antworten. Wieso musst Du das denn wissen? Das hat überhaupt nichts mit meiner ursprünglichen Frage zu tun. Ob ein SDRAM bald nicht mehr verfügbar ist oder seit wann es diese Technologie gibt und was Deiner Meinung nach besser ist, hilft mir und anderen Lesern nicht. Das ist schön und gut zu wissen. Wie man sich die Leiterbahnimpedanzen ausrechnet oder Ausbreitungsgeschwindigkeiten ausrechnet ist auch sehr wichtig aber das hat auch nichts mit meiner Frage zu tun. Es gibt dutzende Threads die das ausführlich behandelt haben und sicherlich auch dutzende Antworten darunter, die ebenfalls nichts mit dem Thema zu haben. Entweder irre ich mich oder Falk B. und Michael K. nutzen meinen Thread nur, um zu zeigen wer mehr Ahnung hat. Es ist ja nicht so als hättet Ihr offenbar keine Zeit zu antworten, denn die Antworten kommen im 30min-Takt. Durch Eure nichtsbeitragenden Antworten gehen meine Fragen unter und derjenige der eine Antwort liefern könnte, hat keine Lust sich hier durchzuscrollen. Meine Frage mit dem Tippfehler wurde auch nur beantwortet weil ich nachgehakt habe, wer dass denn verfasst hat. Zumindest habe ich das Gefühl, vielleicht irre ich mich da. Ich wette ihr könntet ganz schnell sagen, ob die Taktflanke falsch eingezeichnet ist und was Sache ist, aber ich glaub Ihr wollt nicht wirklich helfen. Falls dem so ist, dann schreibt doch bitte keine Füllantworten. Genau diese Detailfragen sind nicht mal eben aus einem Datenblatt herauslesbar oder in Büchern detailiert beschrieben. Für uns Neulinge ist es manchmal schwer da durchzublicken, vorallem wenn jeder Hersteller seine Diagramme anders darstellt oder wenn hier und da mal Wörte vertauscht werden. In älteren Büchern oder Datenblättern wurde teilweise noch viel mehr ins Detail gegangen. Leider ist das wohl heutzutage nicht mehr so wichtig, denn das weiß ja wohl jeder. Wie die Impedanzen oder Ausbreitungsgeschwindigkeiten ausgerechnet werden findet man in etlichen Büchern. Die Gleichung kann ich hier auch ganz schnell posten und dass die Geschwindigkeit bei einer Stripline langsamer ist als Microstrip ist ja wohl auch klar, weil das e_reff kleiner ist bei einer Microstripleitung. Aber auf die Details kommt es manchmal an, die nicht in jedem Buch stehen, und das habt Ihr euch über die Jahre durch Erfahrung etc. angeeignet. Also nochmal zu meiner Frage. Kann mir jemand sagen ob die Flanke in dem Datenblatt falsch eingezeichnet ist und ob das Sinn macht? Bitte keine Antworten hier in meinem Thread, die nichts mit dieser Frage zu tun haben.
Mark B. schrieb: > seht euch mal bitte das angehängte Bild an. Werden die Daten am µC > wirklich bei der fallenden Flanke ausgegeben und bei der darauf > folgenden steigenden Flanke am SDRAM Daten eingelesen oder ist das im > Datenblatt des µCs falsch? Vermutlich ja, denn es ist SEHR ungewöhnlich, am uC die Daten mit der fallenden Taktflanke auszugeben. Diese Spielchen mit Ausgabe auf der einen und Abtastung auf der anderen macht man nur bei SPI, da hat es bei moderaten Bitraten ein paar Vorteile (man kann sich mit einfacher Taktverteilung und diversen Nachlässigkeiten durchmogeln). Bei schon recht flotten 166MHz SDRAM hat es satte Nachteile, nämlich die Verdopplung der Mindestperiodendauer! AFAIK ist bei allen SDRAM und abgeleiteten Technologien alles auf die steigende Taktflanke bezogen, so wie bei normaler, synchroner Logik. Darum gibt es auch für sowas oft eine PLL oder DLL, um einen phasenrichtigen Takt vom uC an den SDRAM zu kriegen. War zumindest bei den FPGAs immer der Fall. Damit kann man vor allem die Verzögerungen der Ausgangstreiber für den Takt kompensieren, zusätzlich natürlich auch die Laufzeit auf der Leitung, aber die ist meist deutlich kleiner.
:
Bearbeitet durch User
Vielen Dank für Deine Antwort! Kurze Erläuterungen weshalb ich da etwas skeptisch war (fehlendes Wissen spielt auch eine Rolle). Das Timing-Diagram des SDRAMs habe ich wohl fälschlicherweise so interpretiert, als würden die Daten (Befehle) vom uC zwischen T0 und T1 ausgegeben werden. Und die fallende Taktflanke im uC Datenblatt hat die Verwirrung noch komplett gemacht. In anderen uC Datenblättern ist sie wohl richtig eingezeichnet - mit steigenden Taktflanken. Das heißt, das Diagram muss so gelesen werden, dass der erste READ Befehl (siehe T0) schon bereits bei T0 minus 1 Zyklus am uC Ausgang angelegt wurde. Und dass der READ Befehl an der Stelle T0 für den nächsten Zyklus gilt.(?)
Mark B. schrieb: > Das heißt, das Diagram muss so gelesen werden, dass der erste READ > Befehl (siehe T0) schon bereits bei T0 minus 1 Zyklus am uC Ausgang > angelegt wurde. Und dass der READ Befehl an der Stelle T0 für den > nächsten Zyklus gilt.(?) Kann man das so pauschal festlegen oder ist es nicht abhängig davon, was als CAS Latency (CL) (Bits 6:4) Configuration register eingestellt wurde?
C. A. Rotwang schrieb: > Kann man das so pauschal festlegen oder ist > es nicht abhängig davon, was als CAS Latency > (CL) (Bits 6:4) Configuration register > eingestellt wurde? Ich mit meinem Halbwissen habe das so verstanden. Die CAS Latenz beschreibt die Anzahl der nötigen Taktzyklen die der SDRAM braucht, um die angeforderten Datenbytes an seinen Datenpins stabil anzulegen nachdem der erste READ Befehl und natürlich die Signale an den Adresspins eingelesen wurden. Bei der Analyse der Timings, sprich Laufzeitunterschiede (was mich ja momentan interessiert) zwischen Taktsignal und Befehlsignale + Adresssignale, spielt die CAS Latenz keine Rolle. Bei einem Schreibzugriff auf den SDRAM sendet der uC, in meinem Fall, das Taktsignal zu dem SDRAM. Der uC legt dann die gewünschte Adresse und den WRITE Befehl an seine Ausgangspins. Diese liegen aber erst eine gewisse Zeit nach der steigenden Taktflanke an den Ausgängen des uCs stabil an. In dem letzten Bild von mir ist das TDVO, in dem SDRAM-Timing Artikel ist das TC2O. Theoretisch sollte man hier den max. Wert nehmen. Da der aber nicht gemessen bzw. angegeben wurde, nimmt man in erster Näherung den 1ns Wert und verdoppelt (?) ihn um "auf Nummer sicher zu gehen". Oder vielleicht auch verdreifachen. Da fehlen mir die Erfahrungwerte. Messen wäre vielleicht noch die sicherste Methode aber die Pins sind bei mir nicht zugänglich. Für meine Analyse reicht das auch erst einmal. Na jedenfalls, hat man dann noch eine gewisse Laufzeit auf den Verbindungsleitungen und eine geforderte Mindeststabilisierungszeit (Setup time) an den SDRAM Eingangspins (für alles Signale). Und diese Signale müssen dann VOR der nächsten steigenden Taktflanke am SDRAM anliegen und eine gewisse Zeit danach gehalten werden. Bei der Timing Analyse ist es also wichtig sich alle Signale zwischen uC und SDRAM bzgl Laufzeit und Setup- und Holdzeiten, relativ zur Taktflanke gesehen, anzuschauen. Und die CAS Latenz ist die innere SDRAM Verarbeitungszeit. Ich hoffe ich hab das jetzt nicht völlig falsch beschrieben.
Mark B. schrieb: > Bei der Analyse der Timings, sprich Laufzeitunterschiede (was mich ja > momentan interessiert) zwischen Taktsignal und Befehlsignale + > Adresssignale, spielt die CAS Latenz keine Rolle. Richtig. > ist das TC2O. Theoretisch sollte man hier den max. Wert nehmen. Ja. > Da der > aber nicht gemessen bzw. angegeben wurde, nimmt man in erster Näherung > den 1ns Wert und verdoppelt (?) ihn um "auf Nummer sicher zu gehen". Schwer zu sagen. > Oder vielleicht auch verdreifachen. Das ist zuviel. Der doppelte Wert ist hier schon recht konervativ. Juristen würden dir aber auch sagen, daß ohne eine explizite max. Angabe alles erlaubt ist, bis in den Milliekundenbereich ;-) > Bei der Timing Analyse ist es also wichtig sich alle Signale zwischen uC > und SDRAM bzgl Laufzeit und Setup- und Holdzeiten, relativ zur > Taktflanke gesehen, anzuschauen. Und die CAS Latenz ist die innere SDRAM > Verarbeitungszeit. Ja.
Thread beobachten
Seitenaufteilung abschalten
.jpg){kind=link}
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.