mikrocontroller.net

Forum: FPGA, VHDL & Co. Vorschläge für schnelle nichtflüchtige Speicher am FPGA


Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

brauche ein paar Vorschläge für nichtflüchtige Speicheranbindung (Größe 
~32GB) an einem Virtex 5 FPGA.

Zum Projekthintergrund:
Wir haben in der Vergangenheit ein Projekt realisiert, wo wir den Virtex 
5 mit DDR2 Ram und Compact Flash realisiert hatten. Im Projekt ging es 
hauptsächlich darum, dass schnell ankommende Daten (~40-50MB/s) im Ram 
zwischengespeichert und auf Befehl zur Compact Flash rüberkopiert 
wurden. Der Ram ist ja schnell genug, der Compact Flash wurde damals mit 
Common Memory Mode angesteuert und erreichte eine Geschwindigkeit bis 
max. 20MB/s.

Nun wollen wir in einem neuen Projekt mit ähnlich schnell ankommenden 
Daten den Ram am besten weglassen, stattdessen den nichtflüchtigen 
Speicher (z.B. CF) schneller machen, um die Daten direkt dort 
abspeichern zu können.

Soweit ich sehe können ja die CF Karten bis zu 100MB/s im UDMA Mode, was 
ich noch versuchen will zu realisieren (evtl. Tipps oder Links wären 
super!!!). Doch was für Alternativen gäbe es?
SD-Karten? Wo ja auch Werbung zum Teil mit Angaben von 90MB/s gemacht 
wird. Die Recherche im Forum bestätigt dies aber nicht!

Zum einen brauchen wir einen Temperaturbereich von -40 bis +85°C, zum 
anderen werden die Speicher unter Strahlung laufen müssen, alles in 
einer Lebensdauer von mind. 5 Jahren.

SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, 
da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten 
in den nichtflüchtigen Speicher ablegen werden soll.

Danke schonmal im voraus für Vorschläge

Yafes

Autor: FlashGordon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ohne mich jetzt mit dem FPGA-Thema sonderlich gut auszukennen:

Wenn ein Datenstrom schnell und zuverlässig (!) gespeichert werden muss, 
werdet ihr mit einem Speicher mit internem Controller Schwierigkeiten 
haben. Grund: Es ist nie klar, wie lange der Controller benötigt, um die 
Daten zu schreiben, und welchen Durchsatz er zuverlässig dauerhaft 
erreicht.

Alles was also Speicherkarte, EMMC oder SSD ist, eher schwierig, bzw. 
wird ein großer Pufferspeicher und Reserven bei der 
Schreibgeschwindigkeit Pflicht.

Ich würde mich bei parallelem NAND-Flash umsehen.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme,
> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten
> in den nichtflüchtigen Speicher ablegen werden soll.

Wenn ihr mit einer SSD nicht zurecht kommen könnt wird es dünn...

SD und Co haben wie erwähnt Recht lange maximale Latenzen von mehreren 
hundert Millisekunden. Auch eine dauerhafte Rate von 50 mib/s ist höchst 
selten bis unwahrscheinlich. Selbst bei einer SSD nicht 
selbstverständlich. Gegen bzw. Für die Lebensdauer hilft Größe. Oder wie 
ist der Einwand gemeint?

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FlashGordon schrieb:
> Ohne mich jetzt mit dem FPGA-Thema sonderlich gut auszukennen:
>
> Wenn ein Datenstrom schnell und zuverlässig (!) gespeichert werden muss,
> werdet ihr mit einem Speicher mit internem Controller Schwierigkeiten
> haben. Grund: Es ist nie klar, wie lange der Controller benötigt, um die
> Daten zu schreiben, und welchen Durchsatz er zuverlässig dauerhaft
> erreicht.
>
> Alles was also Speicherkarte, EMMC oder SSD ist, eher schwierig, bzw.
> wird ein großer Pufferspeicher und Reserven bei der
> Schreibgeschwindigkeit Pflicht.
>
> Ich würde mich bei parallelem NAND-Flash umsehen.

Als Zwischenpuffer kann evtl. der DDR2 Ram dienen, was bisher ja der 
Fall war, heißt aber ich kann ihn dann halt nicht weglassen.

NAND-Flash sind aber interessant, schaue mir grad ein Datenblatt von 
einem Micron NAND-Flash an.

Karl schrieb:
> Yafes61 schrieb:
>> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme,
>> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten
>> in den nichtflüchtigen Speicher ablegen werden soll.
>
> Wenn ihr mit einer SSD nicht zurecht kommen könnt wird es dünn...
>
> SD und Co haben wie erwähnt Recht lange maximale Latenzen von mehreren
> hundert Millisekunden. Auch eine dauerhafte Rate von 50 mib/s ist höchst
> selten bis unwahrscheinlich. Selbst bei einer SSD nicht
> selbstverständlich. Gegen bzw. Für die Lebensdauer hilft Größe. Oder wie
> ist der Einwand gemeint?

Das mit der Lebensdauer ist folgendermaßen grob kalkuliert:
Wir gehen von max. ca. 15 Schreibzyklen pro Zelle pro Tag aus. Je 
nachdem was für Daten ankommen kann es ja sein das zufällig eine Zelle 
am Tag 15 mal hin und her wechselt.
So hätten wir 15 Schreibzyklen pro Zelle x 365 Tage = 5475 Schreibzyklen 
x 5 Jahre = 27375 Schreibzyklen (Worst Case!)
Nur die SSDs mit SLC bieten ja 100.000 Schreibzyklen, die würden gehen.
Aber ich brauche einen Zwsichenspeicher wie DDR2 Ram.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Je nachdem was für Daten ankommen kann es ja sein das zufällig eine
> Zelle am Tag 15 mal hin und her wechselt.
Du hast die Speicherverwaltung und das Wearleveling der Karten ausser 
Betracht gelassen: auch wenn du in einer Datei ständig nur 1 und das 
selbe Byte änderst, änderst du bei gutem Waerleveling jedesmal eine 
andere Speicherzelle.

Und dann kann es sein, dass du eine Speicherkarte länger nicht mehr 
unter Strom hattest. In diese Fall wird die Karte in den ersten paar 
Minutan ziemlich langsam sein, weil sie intern erst mal alles umsotieren 
wird, damit die Speicherplätze im Flsh durchrotieren und der Inhalt 
aufgefrischt wird.

Auf jeden Fall ist ein Medium mit Flash-Speicher niemals 
deterministisch. Du kannst also nie sicher sein, dass irgendetwas nach 
einer bestimmten (kurzen) Zeit abgeschlossen ist.

: Bearbeitet durch Moderator
Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die Anregungen.

Gibt es evtl. einen Link oder ein Design im Netz zur UDMA Ansteuerung 
von CF-Karten? Habe im letzten Design hier ca. 20MB/s geschafft, im 
Common Mode wie schon gesagt. Ich würde den gerne schneller hinbekommen. 
Mein DDR Ram wird in dem Falle als Zwischenspeicher dienen.

Des weiteren schaue ich mir grad diesen NAND-Flash an:
file:///C:/Users/CKalayci/Downloads/M73A_32Gb_64Gb_128Gb_256Gb_AsyncSync 
_NAND.pdf

Dazu habe ich ein Example Design gefunden, mit ähnlichem NAND-Speicher:
https://www.microsemi.com/document-portal/doc_view...

An sich sieht das ja nicht so komplex aus, rein von der Ansteuerung her.
Wenn man den NAND-Flash direkt vom FPGA aus verwaltet, hat man 
theoretisch hier keine Latenz?!?

Wie sieht es mit dem PCB Design aus? Was ist im Routing besonders zu 
beachten? (Datenlängen, parallel Routing, Terminierung etc.)
Hat wer damit schon mal Erfahrung?

Danke

Yafes

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Das mit der Lebensdauer ist folgendermaßen grob kalkuliert
Vergiss diese Kalkulation. Ich teste seit ein paar Jahren SD-Karten mit 
Dauerschreibversuchen. Die meisten Karten sind nach erstaunlich 
schneller Zeit kaputt...
Ich verweise mal auf den 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" und den darin 
versteckten weitergehenden Link auf den 
Beitrag "Re: MIcroSD Karte durch Raspberry PI zerstört"

Falls du Flashspeicher (irgendwelche, denn die basieren abgesehen vom 
Businterface ja auf der selben Technologie!) einsetzen willst, dann 
solltest du vorher ausgiebige Untersuchungen machen...

Yafes61 schrieb:
> Wenn man den NAND-Flash direkt vom FPGA aus verwaltet, hat man
> theoretisch hier keine Latenz?!?
Du brauchst dann aber eine sehr schlauen Verwaltung, die mit defekten 
Flash-Blöcken umgehen kann. Denn solche sind bei diesen Bauteinen 
"normal". Und dann lies dir zum Thema "Firmware und Speicherverwaltung" 
wie gesagt mal die obigen Beiträge durch. Du kommst mit sehr hoher 
Wahrscheinlichkeit zum Ergebnis: das willst du nicht selber machen...

: Bearbeitet durch Moderator
Autor: blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei 10x32GB täglich schon mal über ein SAN aus SSDs nachgedacht das per 
Sata,Gb-Ethernet oder Infiniband angesperochen wird?

Vermutlich reicht dann aber der Virtex5 nicht mehr aus..

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Du brauchst dann aber eine sehr schlauen Verwaltung, die mit defekten
> Flash-Blöcken umgehen kann. Denn solche sind bei diesen Bauteinen
> "normal". Und dann lies dir zum Thema "Firmware und Speicherverwaltung"
> wie gesagt mal die obigen Beiträge durch. Du kommst mit sehr hoher
> Wahrscheinlichkeit zum Ergebnis: das willst du nicht selber machen...

Zum Punkt defekte Flash-Blöcke. Das Datenblatt sagt mir das die Zelle 
60000 Schreib- bzw. Löschzyklen hat. Kann ich dem jetzt vertrauen und 
die Speicherverwaltung weglassen? So wie ich dich verstehe, nein.

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme,
> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten

Hä? Wenn vorher CF ging dann geht auch SSD. Da schreibt man nicht auf 
einer einzelnen Zelle rum, die haben alle Wear-Leveling.

Eine Samsung 960 Pro 1TB NVME erlaubt 1,2 PetaByte TBW, das sind über 10 
Jahre 320GB täglich.

CF oder SDXC gehen viel früher kaputt, jedenfalls bei der Schreibrate.

Ich würde allerdings den RAM Chip trotzdem im Design vorsehen: Man kann 
nie wissen wann der SSD Controller mal 'ne Pause für interne 
Verwaltungsaufgaben (Wear Leveling, s.o.) einlegt.

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Yafes61 schrieb:
>> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme,
>> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten
>
> Hä? Wenn vorher CF ging dann geht auch SSD. Da schreibt man nicht auf
> einer einzelnen Zelle rum, die haben alle Wear-Leveling.
>
> Eine Samsung 960 Pro 1TB NVME erlaubt 1,2 PetaByte TBW, das sind über 10
> Jahre 320GB täglich.
>
> CF oder SDXC gehen viel früher kaputt, jedenfalls bei der Schreibrate.
>
> Ich würde allerdings den RAM Chip trotzdem im Design vorsehen: Man kann
> nie wissen wann der SSD Controller mal 'ne Pause für interne
> Verwaltungsaufgaben (Wear Leveling, s.o.) einlegt.

Ich hab mal eine SSD gehabt am Rechner, wo ich mal eine Testsoftware 
hatte die 250GB in kürzerster Zeit gefüllt hatte. Geschätzt 150x habe 
ich das mit dieser Platte gemacht. War ne Samsung 840 Pro. Dann habe ich 
diese SSD als primäre Festplatte im Einsatz mit Windows 10. Nach einer 
gewissen Zeit fing an mein Rechner einzufrieren wenn ich bestimme 
Programme nutzte. Habe dann eine Clone auf eine andere SSD gemacht, die 
dann ganz normal funktionierte. Die kaputte SSD habe ich eingeschickt, 
bekam dann die neure 850 Pro vom Hersteller über die Garantie. Die SSD 
hat 3 Jahre gehalten. Deswegen frage ich auch skeptisch zum Thema SSD.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hat mir das mal vor 4 Jahren angeschaut, das lief darauf hinaus das 
man ein schnelles PCIe im FPGA implementiert und da drüber die SSD 
dranbammelt.
http://searchsolidstatestorage.techtarget.com/podc...

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Falls du Flashspeicher (irgendwelche, denn die basieren abgesehen vom
> Businterface ja auf der selben Technologie!) einsetzen willst, dann
> solltest du vorher ausgiebige Untersuchungen machen...

Was ich bei solchen Projekten generell mache ist, im Dauerbetrieb 
(ähnlich wie dein Beitrag) Speicher komplett zu füllen (mit 
Zufallsdaten, LFSR) und auszulesen, dabei zu vergleichen ob Write / Read 
Data übereinstimmen. Das über mehrere Tage.
Meinst du mit ausgiebige Untersuchung sowas?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Die SSD
> hat 3 Jahre gehalten. Deswegen frage ich auch skeptisch zum Thema SSD

CT hatte Stresstest mit SSDs gemacht, dabei habe die SSDs ein vielfaches 
der Mindestschreibleistung gehalten. Die Samsung waren am ende von Test 
immer noch quicklebendig.

Es könnte also auch sein, das es ein "normaler" Ausfall bei dir war.


https://www.heise.de/newsticker/meldung/SSD-Langze...

Autor: Analog OPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir haben ebenfalls SSDs am werkeln und es kommt genau zu diesem Punkt: 
Grundsätzlich hohe Datenrate, aber dann sporadisch und nicht gut 
vorhersagbar Aussetzer und Blockaden des Controllers. Die Lösung war 
eine Art Cache im externen RAM und eine Verwaltung, die die SSDs 
beschreibt und verifiziert. Am Ende sind wird mit einem Array aus 4 SSDs 
rausgekommen, sozusagen RAID manuell. Vielleicht schaffst Du es ja 
einen, RAID Controller mit dem FPGA einzubinden und anzusteuern. Keine 
Ahnung wie kompliziert das ist.

Wir lesen ein, schreiben parallel auf zwei RAMs, (falls eins mal 
kaputtgehen sollte) und ziehen dann aus beiden (mit Vergleich um 
Sicherzustellen) die Daten langsam raus und schieben sie parallel auf 2 
SDDs und ihre Spiegel. Damit hat man im Mittel die doppelte Bandbreite 
jeder SSD und minimal die einfache Bandbreite einer SSD.

Schreib-Lese-Bandbreite des Controllers ist wegen 4x Schreiben und 2x 
Rücklesen + 2x Lesen aus den RAMs und 2x Schreiben so etwa : 12x 
Nettodatenrate.

Die Frage wäre, ob es möglich ist, das in einen FPGA zu bekommen. 4x 
SATA sollte eigentlich gehen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Das über mehrere Tage.
> Meinst du mit ausgiebige Untersuchung sowas?
Wochen. Monate... ;-)

Yafes61 schrieb:
> Was ich bei solchen Projekten generell mache ist, im Dauerbetrieb
> (ähnlich wie dein Beitrag) Speicher komplett zu füllen und auszulesen,
> dabei zu vergleichen ob Write / Read Data übereinstimmen.
Beim Flash kann es auch vorkommen, dass Daten die du nicht anrührst 
durch das mehrmalige Löschen eines benachbarten Blocks in 
Mitleidenschaft gezogen werden.
Du solltest also den Speicher mit Daten befüllen, dann laufend einen 
Block löschen und beschreiben und dabei kontrollieren, ob die nicht 
manipulierten Daten konstant bleiben.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Du solltest also den Speicher mit Daten befüllen, dann laufend einen
> Block löschen und beschreiben und dabei kontrollieren, ob die nicht
> manipulierten Daten konstant bleiben.

Speicher sind inzwischen so optimiert das sie ohne Cache nicht 
zuverlässig funktionieren, siehe Rawhammer 
https://www.heise.de/security/meldung/Rowhammer-RA...

Die Caches und wear leveling sind inzwischen essential geworden, älterer 
Speicher mit breiteren Strukturen mag noch unkaputtbar sein, moderner 
Speicher mit hoher Informationsdichte ist es nicht. Der ist aber so 
ausgelegt, das bei normalerer Anwendung (0815 Windows-User) über die 
spezifizierte Lebensdauer nichts passiert.

Autor: Mac Gyver (macgyver0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest Dich mal bei industriellen SSDs mit SLC Flash umsehen.
Nicht billig, aber für -40..+85°C verfügbar und (pro Zelle) langlebiger 
als MLC Flash.
Aber auch hier gilt: Je größer desto besser, da besser verteilt 
geschrieben werden kann.


Alle heutigen Consumer SSDs verwenden MLC oder gar TLC Flash, da hat man 
pro Zelle nur noch ein paar tausend Schreibzyklen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitwurschtler schrieb:
> Speicher sind inzwischen so optimiert das sie ohne Cache nicht
> zuverlässig funktionieren
Die Optimierung beginnt schon ganz unten auf dem Speicherchip, der sogar 
so "optimiert" wurde, dass die erste Fehlerbereinigung auf dem Flash 
selber stattfinden muss...

: Bearbeitet durch Moderator
Autor: Analog OPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mac G. schrieb:
> Alle heutigen Consumer SSDs verwenden MLC oder gar TLC Flash, da hat man
> pro Zelle nur noch ein paar tausend Schreibzyklen.

D.h. die Langzeitdauer wird allein durch das Verteilen erreicht? Stellt 
sich die Frage, wie das mit den Testergebnissen der 
Computerzeitschriften zusammenpasst, die angeblich Dauertests auf SSDs 
machen und sie kaum kaputt bekommen.

Ich meine: Wenn wir ständig Daten draufschreiben, ist der Trick mit dem 
Verteilen schnell am Limit. Und bei uns geht auch in der Tat 
allenthalben eine kaputt. Daher die RAID-Lösung.

Eine andere Frage: Wenn man so hohe Raten hat, dass andauern geschrieben 
wird, warum dann nicht einfach ein RAM-Array mit Energie-Puffer?

Wir hatten in einer Firma mal so eine Informix-Datenbank am werkeln. 
Weil die Platten alle zu langsam waren (SSDs gab es noch nicht) hat man 
einfach einen Rechner als Server hingestellt, der 16GB RAM hatte und 
immer lief. Der hat garnichts auf Platten gespeichert und Anfragen nur 
aus dem RAM bedient.

Mit den heutigen Methoden müsste sich doch einfach eine große RAM-Disk 
auf einem Industriecomputer anfertigen lassen, die die Bandbreite 
schafft. Mein Rechner hier wäre z.B. auf 8x16GB RAM aufrüstbar, wenn Ich 
es bräuchte.

Keine Ahnung, wie schnell da eine RAM-Disk unter Windows ist, aber 
100MB/sec scheint mir machbar.:-)

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Analog OPA schrieb:
> Ich meine: Wenn wir ständig Daten draufschreiben, ist der Trick mit dem
> Verteilen schnell am Limit.

nein, weil die Platten ja immer größer werden.

Bei einer 512GB platte sind 1000 mal überschreiben auch schon 512TB. Das 
Interface (SATA) ist einfach zu langsam um die Platte schnell kaputt zu 
machen.

Autor: Analog OPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine eingebute Platte wird aber nicht mehr grösser :-)

Ich gebe Dir natürlich Recht: Grösse macht Langlebigkeit. Aber SATA kann 
immerhin bis zu 16GBit und beim Rücklesen und Vergleichen auf Fehler 
sowie mehrfachem Schreiben, kriegt man das schon mit einer Nettorate von 
4GBit hin und das wäre 500MB/s.

Wenn man nun verteilt:

1000x512GB*8/16Gbps = 72h spätestens defekt, praktisch eher früher
mit etwas Sicherheit von 99% gerechnet 0,7h bei voller Rate, 7h mit 1/10 
Rate. Und unser Freund braucht 100MB/s also mehr, als ein 1/10.

So wie Ich es sehe, hat er schon nach 7h Vollast eine Chance von > 10% 
auf Plattendefekt!

Bei den 10x32GB wären es 16000 Tage und 160 Tage für die 1%-Schwelle.

Wir rechnen mit einer Lebensdauer nach Ausfall für 10ppm -> 1,6 Tage 
MTBF

Das wäre nicht tragbar!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Analog OPA schrieb:
> D.h. die Langzeitdauer wird allein durch das Verteilen erreicht?
Ja. Wie gesagt: Wearleverling.

> Stellt sich die Frage, wie das mit den Testergebnissen der
> Computerzeitschriften zusammenpasst, die angeblich Dauertests auf SSDs
> machen und sie kaum kaputt bekommen.
Genau so, dass der Test ohne oder mit schlechtem Wearleveling schon 
nach kürzester Zeit beendet wäre.
Wearleveling nimmt nämlich auch beliebige Daten in die Hand: wenn du 
dein Flash zu 99% mit statischen Daten voll hast und nur auf 1% 
herumschreibst, dann werden die 99% zwischendurch umsortiert, dass auch 
andere Speicherblöche mal "drankommen"...

Yafes61 schrieb:
> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme,
> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten
> in den nichtflüchtigen Speicher ablegen werden soll.
Wenn CF funktionieren würden, dann funktionieren auch SSD, denn das 
Flash in der CF ist das selbe wie in der SSD. Allein die Firmware ist je 
nach Businterface evtl. ein wenig unterschiedlich.

: Bearbeitet durch Moderator
Autor: Mac Gyver (macgyver0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Analog OPA schrieb:
> Aber SATA kann
> immerhin bis zu 16GBit

6 Gbit/s - und die SSDs können langsamer werden wenn man die komplett 
vollschreibt.
Und es sind eher 3000 - 5000 Zyklen pro Zelle.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flash sehe ich hier als sehr problematisch an. Da bräuchte es sehr viel 
Redundanz und entsprechende Caches...

Eine Alternative könnte MRAM sein. Leider ist diese Technologie erst in 
überschaubaren Speichergrößen verfügbar.

Everspin will Ende des Jahres mit einem PCIe Modul mit 16GByte auf den 
Markt kommen:

https://www.everspin.com/nvnitro-technology

Mit 1Mrd. Schreibzylken und (beim PCIe Modul mit WORST-CASE Latenz von 
11µs) und bis zu 6GByte/s auch ordentlich schnell:

https://www.everspin.com/file/1223/download

Preis ist ein anderes Thema...

Vielleicht könnte so ein Modul ja dein Cache darstellen. Als 
Massenspeicher dann eben "Standard" Festplatten oder SSDs

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses SSD-Angstgemacht bringt dich hier nicht weiter. Bei deiner 
Datenmenge musst du bei jeder Speichertechnologie nach mindestens 3 
Punkten schauen:
* DWPD (Disc-Writes-Per-Day) -> damit bleibt auch die SSD während ihrer 
Lebensdauer am Leben
* NRER (Non-Recoverable-Error-Rate) -> Chance das dir der Speicher 
falsche Daten als gute Daten anbietet (z.B. 10^-15 bit)
* Speicherzeit unpowered -> manche SSDs bieten lt. Datenblatt nur 3 
Monate Liegezeit an. Andere NAND-Flashs 30 Jahre.

schreib dir deine Anforderungen auf und sieh dich um.

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die Anregungen.

Um Kurz zusammenzufassen:

- Um einen Zwischenpuffer wie RAM komme ich nicht drum rum
- SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe 
benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling 
hätte ich eine hohe Lebensdauer
- NAND Flash wäre eine weitere Alternative
- CF ist auch möglich, muss aber einen UDMA Mode benutzen um höhere 
Datenraten zu erreichen. Habe den Common Mode implementiert, wie 
aufwändig wäre es den UDMA zu implementieren? Erfahrungen wären 
hilfreich
- Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest 
über mehrere Wochen unterliegen, um Lebenszeit zu testen (!)

Yafes

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> - Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest
> über mehrere Wochen unterliegen, um Lebenszeit zu testen (!)
Ich teste bis der Speicher kaputt ist.
Denn wenn ich nur 4 Wochen teste, dann weiß ich nicht, ob das Ende am 
nächsten Tag käme oder ob da noch 8 Wochen Luft sind...

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> - SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe
> benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling
> hätte ich eine hohe Lebensdauer

SLC ist eigentlich zu teuer, selbst die die PRO Versionen setzen auf 
MLC. Sie nutzen als Cache teilweise mit MLC als SLC.

> - CF ist auch möglich, muss aber einen UDMA Mode benutzen um höhere
> Datenraten zu erreichen. Habe den Common Mode implementiert, wie
> aufwändig wäre es den UDMA zu implementieren? Erfahrungen wären
> hilfreich
hier müsste man schauen ob es Wearleveling gibt. Generell würde ich CF 
weniger zutrauen als SSD.

> - Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest
> über mehrere Wochen unterliegen, um Lebenszeit zu testen (!)

Das bringt wenig, wenn selbst einfache SSDs schon mehr also 6 Monate 
durchhalten. Dann doch lieber auf die zugesicherten Werte aus dem 
Datenblatt schauen.


mit PCIe kann man direkt PCIe anbinden.

http://www.samsung.com/semiconductor/minisite/ssd/...

Dort steht "400 Terabytes Written", das sind bei deinen 50Mbyte/s 
immerhin 6Jahre - reicht das nicht?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Man muss ein bischen unterscheiden, ob man mit dem Totalausfall der 
Platte rechnet, weil sie gar nicht nicht mehr beschreibar ist oder dem 
Zeitpunkt, ab dem die Performance sinkt, weil immer mehr fürs Suchen 
noch beschreibbarer Bereiche drauf geht.beschreibbarer Fläche draufgeht. 
Dazu ist wichtig, die Anwendung zu betrachten, wie oft und wie lange 
etwas genutzt wird, welche maximale Bandbreite man braucht und wie stark 
dafür die Performance runtergehen darf.

Ich hatte das für einen SATA-Speicher für Audio-Echtzeitdaten mal 
abgeschätzt und bin zu folgenden Werten gelangt:

MTBF ist hier die geschätzte Zeit bis zum Fehler 50% - auf Basis des 
Durchsatzes und der Herstellerangaben, also nur ein sehr grober 
Richtwert.

POGO ist die period of good operation, also die Zeit, in der das System 
bis an die voreingestellte Fehlergrenze kommt - in der Annahme dass dann 
die Performance noch entsprechend ist - was sie auch ist, wenn sie die 
Fehler wie angegeben entwickeln.

Bei so einem Daten-Aquisesystem wie beim TE darf die Bandbreite z.B. 
nicht wirklich runtergehen, also muss man ein niedrige Fehlergrenze 
ansetzen
Bei einem reinen Datenspeicher, darf die wiederum hoch sein, weil man 
die Platte gut ausnutzen möchte. Ausserdem ist diese infolge des 
Datenwachstums meist schon lange voll, bevor sie getauscht werden muss.

Beim Server gibt es hingegen wieder nur wenig Datenwachstum, der spielt 
nur hin und her - schreibt also ständig und überschreibt.

Auch gibt es einen Unterschied beim Heim- und Arbeitsplatz-PC mit 
speicherintensiven Berechnungen

Meine Schlussfolgerung:

Für Server und Datenzwischenspeicher sollte man schon zu performantem 
Speicher greifen, der einige Schreibzyklen verträgt. Der Rest kommt mit 
low cost aus. Ein generelles Datensicherheitsproblem und Backup-Anspruch 
besteht ohnehin bei allen.

 Ein Serverspezi hat mir mal erklärt, dass sie das Thema Backup und 
Performance / Sicherheit kombinieren, indem sie die Platten deutlich VOR 
dem Ablaufdatum austauschen und in den Schrank legen und ab und zu mal 
bestromen und lesen. D.h. die Platte wird beim minimalen 
"Langsamerwerden" schon ausgetauscht und nur noch als Backup verwendet. 
Der zieht einfach jede Woche die SSDs aus dem Schacht und steckt 2 neue 
rein.

Ob das so sinnvoll ist, kann Ich nicht einschätzen.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> - SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe
> benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling
> hätte ich eine hohe Lebensdauer

ja, PCIe als PHY, jedoch bräuchtest du noch ein NVMe-Treiber. Das wäre 
dann eine CPU mit Linux noch dazu :) oder ein NVMe-Host (z.B. IP 
https://www.xilinx.com/products/intellectual-prope...). 
Witzigerweise will der IP noch einen nicht zu kleinen DRAM dazu.

Man kann auch auf SATA-IPs gehen, aber auch hier ist das alles andere 
als ein einfaches Design.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Witzigerweise will der IP noch einen nicht zu kleinen DRAM dazu.

Wahrscheinlich für einen Cache?

Für Datengewinnungssysteme mit vielen Schreib- und Löschzyklen sind SSDs 
halt nicht unbedingt der Hit.

Nur im Bereich Audio wird das inzwischen intensiv gemacht, allerdings 
will man die Rohdaten auch behalten, solange die Produktion läuft.

Also nimmt man 32 Kanäle parallel auf und schreibt etwa 2x parallel 24 
MB/s weg. Dann sind zwei 64er SSDs voll. Das Ganze wenn man klug ist 
nochmal auf ein Backup-System gleicher Größe. Statt wie früher zu 
überspielen, werden die rausgezogen und daheim in den Rechner gesteckt 
und nondestruktiv bearbeitet, oder bei der ersten destruktiven 
Bearbeitung auf die interne Platte gerendert.
Überspielt werden die Daten auf der SSD erst, wenn die Produktion durch 
ist und die CDs produziert sind, also nach Wochen. So kommt man mit ein 
paar Sätzen SSDs jahrelang ohne Probleme aus.

Vielleicht ist eine konventionelle Platte doch eine bessere Lösung?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Für Datengewinnungssysteme mit vielen Schreib- und Löschzyklen sind SSDs
> halt nicht unbedingt der Hit.

doch genau dafür sind sie der Hit weil sie verdammt schnell sind.

Sie werden aus dem Grund auch in NAS als Cache eingesetzt.

> Vielleicht ist eine konventionelle Platte doch eine bessere Lösung?
wenn es nicht gerader im viele Terabyte geht, machen sie keinen sinn 
mehr.

Wenn so eine SSD 7 Jahre bei durchgehend 50Myte/s hält - was will man 
denn noch?

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flash-Disks werden in grossen (Petabyte+-) Speichersystemen als 
Frontend-Cache eingesetzt.

Aus eigener Erfahrung kann ich sagen, dass sie deutlich weniger oft 
kaputtgehen (obwohl sie naturgemäss sehr viel öfter beschrieben und 
gelesen werden) als die dahinterliegenden drehenden Platten. Etwa eine 
im Jahr während im Schnitt jeden Monat zwei "klassische" Platten 
draufgehen.

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir sind grad in der Projektplanung, daher versuche ich viele 
Informationen zu sammeln, um später die richtige Wahl zu treffen.

Vielleicht kurz nochmal zum Projekt:
Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen 
ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig. 
Heißt z.B. SSDs mit SLC, auch wenn sie teurer wären, werden natürlich 
bevorzugt gegenüber MLC Technologie. Strahlung ist ein weiteres Thema, 
womit alles noch zusätzlich belastet wird und der ständige 
Temperaturwechsel. Vakuum sollte nicht das Problem sein.

Für die...

SSD Lösung:
- Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD 
hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer 
aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die 
Hälfte des Speichers verwendet wird, richtig?
- Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe 
Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)
- Wie verbinde ich vier PCIe Lanes vom FPGA zur SSDs, quasi nicht 
direkt, sondern über eine NVMe-Host IP?! Der noch zusätzlich ein 
Speicher benötigt?

NAND-Flash:
- Die direkte Lösung, ohne Speicherverwaltung, heißt kaputte Zelle sind 
halt kaputt => würde quasi gehen, da Kameradaten, ob nun ein oder 
mehrere Bits kaputt sind wären egal
- Hierfür wird keine IP nötig, kann quasi aus dem Datenblatt heraus 
eigene FSM entwickeln ?! oder täusche ich mich

CF:
- hier besteht eine Lösung bis 20MB/s im mittel, Common Memory Mode
- Frage wäre was mit dem PIO oder UMDA Mode an Geschwindigkeitsvorteil 
bringt (die besagten ~100MB/s aus den Datenblättern?!)


Yafes

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Es wird ein Projekt fürs Orbit sein,

Ich gehe davon aus, dass so gut wie alle handelsüblichen "schnelleren" 
Speichermedien in irgendeiner Weise RAM mit an Bord haben, der dann 
sicher nicht ausreichend latch-up geschützt ist?

Da hast Du dann u.U. nicht nur Bitfehler, sondern Totalausfall.

: Bearbeitet durch User
Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Yafes61 schrieb:
>> Es wird ein Projekt fürs Orbit sein,
>
> Ich gehe davon aus, dass so gut wie alle handelsüblichen "schnelleren"
> Speichermedien in irgendeiner Weise RAM mit an Bord haben, der dann
> sicher nicht ausreichend latch-up geschützt ist?
>
> Da hast Du dann u.U. nicht nur Bitfehler, sondern Totalausfall.

Der Arbeitsspeicher ist theoretisch nicht geschützt. Kommt aber in eine 
Bleikammer rein, um ihn so gut wie möglich zu schützen. Einen 
Totalausfall hatten wir im letzten Projekt nicht, der schon lange im 
Orbit ist. Das FPGA hingegen wird auf Bitkipper überwacht und im Falle 
dessen neu konfiguriert. Alles zusammen wird natürlich vorher in einem 
Strahlungstest getestet, d.h. die Dosis über mehrere Jahre wird auf die 
gesamte Einheit belastet.

Die Einheit ist auch nicht ständig an, quasi nur wenn die Basisstation 
Kontakt hat (~20min) oder wenn was aufgenommen werden soll (~20min). Und 
das ca. 15 mal am Tag im Extremfall.

Yafes

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> SSD Lösung:
> - Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD
> hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer
> aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die
> Hälfte des Speichers verwendet wird, richtig?
ja, außerdem gibt es bei neuere SSDs keine 32GB mehr. Ein einzelner 
Flashbaustein hat ja schon mehr Speicher.

> - Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe
> Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)
Ich würde davon ausgehen, das es auch mit x1 Funktioniert.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> - Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe
> Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)


Nein, PCIe ist an den Leitungen skalierbar du brauchst nur einen 
PCIe-Core aber soviel schnelle IO (MGT - MultiGigabitTransceiver) wie du 
Lanes anschliessen willst. Die hat aber nicht jeder FPGA, ein Spartan6-T 
nur soviel wie für einfach x1 gebraucht.


Der Virtex-5 sollte x4 unterstützen:
https://www.xilinx.com/products/intellectual-prope...


Allerdings gibt es bei PCIe noch Unterschiede bezüglich der Generation 
(Gen1, Gen1.1, Gen2, Gen3)
https://www.xilinx.com/products/technology/pci-express.html

am besten erst mal in die PCIe Grundlagen reinschnuppern, das ist nicht 
ganz so trivial:

https://en.wikipedia.org/wiki/PCI_Express

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Yafes61 (Gast)

>Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen
>ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig.

Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht 
abfließen können? 320GB funkt man nicht einfach mal so zur Erde.

>- Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD
>hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer
>aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die
>Hälfte des Speichers verwendet wird, richtig?

Ja.

>- Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe
>Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)

Wo liegt das Problem?

>- Die direkte Lösung, ohne Speicherverwaltung, heißt kaputte Zelle sind
>halt kaputt => würde quasi gehen, da Kameradaten, ob nun ein oder
>mehrere Bits kaputt sind wären egal

Wirklich? Dann sieht euer "Teleskop" plötzlich komische Objekte. Ob das 
so sinnvoll ist. Hier würde ich MINDESTENS eine CRC draufpacken, wenn 
man die Fehler wieder korrigieren will eine ECC.

>- Hierfür wird keine IP nötig, kann quasi aus dem Datenblatt heraus
>eigene FSM entwickeln ?!

Kann man, ist aber ein wenig hemdsärmelig. Und das soll dann in den 
Orbit? Spionagesatellit für Arme?

>- Frage wäre was mit dem PIO oder UMDA Mode an Geschwindigkeitsvorteil
>bringt (die besagten ~100MB/s aus den Datenblättern?!)

Naja, das ist nur die Bandbreite der Schnittstelle. Der Flash MUSS das 
nicht zwangsläufig schaffen, schon gar nicht dauerhaft.

Autor: Yafes61 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>>Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen
>>ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig.
>
> Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht
> abfließen können? 320GB funkt man nicht einfach mal so zur Erde.

Deswegen ja auch 10x :-) Quasi 10 Überflüge

Falk B. schrieb:
>>- Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe
>>Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)
>
> Wo liegt das Problem?

Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes 
hat, meiner hat angeblich nur 3.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
>> Wo liegt das Problem?
>
> Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes
> hat, meiner hat angeblich nur 3.

Geht's um den im "Bleianzug" ?!
https://www.xilinx.com/support/documentation/data_...

Da haste zwar nur 3 Blöcke aber jeder sollte 1,4 oder 8 lanes können 
(see p.12)

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes
> hat, meiner hat angeblich nur 3.

wie schon oben geschrieben, reicht auf 1 Lane aus.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Yafes61 (Gast)

>> Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht
>> abfließen können? 320GB funkt man nicht einfach mal so zur Erde.

>Deswegen ja auch 10x :-) Quasi 10 Überflüge

Ja und dann? 1000 Überflüge um die Daten loszuwerden?

Autor: Blechbieger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yafes61 schrieb:
> Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe
> Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!)

Ich bezweifle dass so ein Consumer-grade Stecker die Vibrationen beim 
Start übersteht. Ich habe den Eindruck dass du sehr blauäugig an das 
Thema ran gehst, selbst wenn es nur um einen Cubesat gehen sollte.

Verzichte auf Stecker und löte eMMC-Flash drauf, eventuell mehrere 
parallel für Bandbreite.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blechbieger schrieb:
> Ich bezweifle dass so ein Consumer-grade Stecker die Vibrationen beim
> Start übersteht.

Im Datenblatt gibt es zumindest kein Limit

Vibration: No electrical discontinuity greater than 1u sec shall occur.
Mechanical Shock: No electrical discontinuity greater than 1u sec shall 
occur.

Wenn man Start nicht aktiv, sollte es also keine Probleme geben, so mal 
die SSD ja verschraubt ist.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> doch genau dafür sind sie der Hit weil sie verdammt schnell sind.

Im Sinne der Langlebigkeit, meinte Ich. Gegenüber Platten mit ihrem 
Cache haben sie eben den Vorteil der großen Speicherfläche. Wenn man 
aber einen FPGA in der Schaltung hat, dann wäre ein echtes S-RAM der 
gegebene Puffer, um die dynamische Rate zu packen. Der Rest mit genug 
Parallelität auf Platte. Es gibt ja diese Micro-Drives. Die habe Ich 
auch schon mal als Wechselsystem eingesetzt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.