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.
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.
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ß
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
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
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?
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.
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.
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ß
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ß
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.
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.
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.
20200701_210908.jpg
(390 KB)
.jpg){kind=link}