Für die Grundlagen fehlt noch das Thema "Ram". Es gibt ja die sehr schönen Beispiele von Lothar, die den Unterschied zwischen "distributed"- und Block-Ram zeigen, sowie die Implementierung eines FIFOs: http://www.lothar-miller.de/s9y/archives/21-FIFO.html Nun stellt sich aber die Frage, wie realisiert man am besten ein Dual-Port-Ram?
chris schrieb: > Nun stellt sich aber die Frage, wie realisiert man am besten ein > Dual-Port-Ram? mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer Toolchains. https://embeddedmicro.com/tutorials/mojo/using-core-generator
chris schrieb: > Nun stellt sich aber die Frage, wie realisiert man am besten ein > Dual-Port-Ram? Im Synthesizer Users Guide steht drin, wie man eine Hochsprachenbeschreibung gestalten muss, dass der Synthesizer ein RAM draus macht. https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_4/xst_v6s6.pdf https://www.xilinx.com/support/documentation/user_guides/ug383.pdf http://ece-research.unm.edu/jimp/vhdl_fpgas/slides/2008/BRAM.pdf Ich instantiiere die Dinger üblicherweise nicht als generische VHDL-Beschreibung und nehme auch nicht den Core Generator, sondern mache es manuell mit den entsprechenden Templates...
Angehängte Dateien:
-
true_dpram_sclk_vhd.gif
3,3 KB
Von Altera gibt es auch so einen Block. Im Bild sieht man das Diagramm von Altera. Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft. Für eine Version in VHDL scheinen mir ein paar Synchronisationssignale zu fehlen. Ich stelle mir gerade die Frage, welche Signal man wirklich bräuchte:
1 | sysclk
|
2 | |
3 | adr0
|
4 | dataIn0
|
5 | dataOut0
|
6 | wr0
|
7 | rd0
|
8 | ready0
|
9 | |
10 | adr1
|
11 | dataIn1
|
12 | dataOut1
|
13 | wr1
|
14 | rd1
|
15 | ready1
|
Was meint Ihr?
chris schrieb: > Ich stelle mir gerade die Frage, welche Signal man wirklich > bräuchte: ... > Was meint Ihr? Kommt auf die Aufgabe an... > Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft. Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen Hersteller bleibst und das Design ein paar Jahre später "upgraden" musst.
Lothar M. schrieb: >> Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft. > Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen > Hersteller bleibst und das Design ein paar Jahre später "upgraden" > musst. Deshalb empfehle ich ja auch den CoreGen. Der funktioniert auch für DPRAM Strukturen für die es kein sauberers VHDL-template gibbet (bspw. unterschiedliche aspect ratios der beiden Ports) und unsinnige Werte für Parameter sind nicht eingebbar. In VHDL kann man allen möglichen Mist angegeben der nicht synthetisierbar ist, oder obwohl korrekt synthetisierbarer code trotzdem nicht vom Synthesizer erkannt wird. Siehe die dutzenden Beschwerden über den fragilen Mechanismus der RAM-inference in diversen Foren: https://github.com/clash-lang/clash-compiler/issues/127
chris schrieb: > Für die Grundlagen fehlt noch das Thema "Ram". Du machst jetzt aber nicht für alles, was in einen FPGa reinginge, ein Grundlagenthema auf oder? Sowas gibt es auf den FPGA-Seiten zuhauf! Die Hersteller haben auch allesamt genaueste mehrseitige Anleitungen, wie so etwas eingesetzt werden kann, wie es formuliert werden soll und muss, damit es funktioniert und welche Variationen es gibt. Das ist Lesestoff für Stunden und Material zum Ausprobieren für etlichen Wochen, wenn Du das alles behandeln und ausprobieren willst. https://www.fpgarelated.com/forums Zielführender fände Ich solche Themen wie: "Wie bekomme Ich einen FPGA mit einem Microcontroller verbunden" "Wann schalte Ich einen FPGA vor einen Microcontroller" "Wann benutze Ich überhaupt einen FPGA bei den immer weiter wachsenden Funktionen der Microsontroller" Das täte auch besser zum Forumsthema passen. Vielleicht ist aber auch das das richtige für Dich: http://www.fpga-talk.de/forum/viewforum.php?f=4
Eigentlich ist RAM ganz einfach, du instanziierst das RAMprimitive so wie du es brauchst. Eventuell ist das dein Problem, zu erkennen wo man welche RAM-primitive einsetzt, insbesonders wo im Alltagsgebrauch immer nur von singleport ram die rede/Verwendung ist. da steht was: http://www.cypress.com/products/dual-port-srams https://www.idt.com/document/apn/91-most-commonly-asked-questions-about-async-dual-ports Registerbänke für prozessoren die Befehle wie ReggB := RegA + RegB ermöglichen kann man aals DualPort RAM aufbauen; für die Picoblazevariante dort wird distributed RAM verwendet: https://www.mikrocontroller.net/svnbrowser/pibla/00_hw/src/pibla.vhd?annotate=2 Zeile 200 - 232 Dort laufen die ports am selben Takt. Weitere Anwendungen sind dadurch gekennzeichnet das sie mit unterschiedlichen Takt laufen, FIFO ist da der primitive Fall eines DP-RAMS zur Synchronisation. Ein anderer wäre die Bildwiederholspeicher von Vidointerface. Dort wird der eine Port, der in Richtung Monitor nur als readonly benutzt, der andere dagegen als write aber auch als readwrite. Code-Beispiel: https://www.mikrocontroller.net/svnbrowser/redz0mb1e/src/vhdl/video_ram.vhd?view=markup Dieses ältere Xilinx dokument erklärt wie der Blockram aufgebaut ist, welche Schnittstellen er besitz und welche typischen Anwendungen es dafür gibt: https://www.xilinx.com/support/documentation/application_notes/xapp463.pdf
>Eigentlich ist RAM ganz einfach, du instanziierst das RAMprimitive so >wie du es brauchst. Eventuell ist das dein Problem, zu erkennen wo man >welche RAM-primitive einsetzt, insbesonders wo im Alltagsgebrauch immer >nur von singleport ram die rede/Verwendung ist. Es gibt im Moment eigentlich noch keine Probleme. Ich habe eher strukturelle Fragen und will erst mal sehen, wie andere das Problem gelöst haben. Was mir bisher auffällt: Die Ram-Designs haben fast nie Tristate-Datenanschlüsse so wie es bei physischen RAM-Bausteinen der Fall ist, sondern immer getrennte Ein- und Ausgänge. Sehe ich das richtig? Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann man schneller Designs machen, braucht aber mehr Glue-Logic, weil man keinen Tri-State-Bus verwenden kann.
>> Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft. Lothar Miller schrieb: >Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen >Hersteller bleibst und das Design ein paar Jahre später "upgraden" >musst. Das würde bedeuten, dass Dein Fifo-Design http://www.lothar-miller.de/s9y/archives/21-FIFO.html nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft. Scheinbar läuft es aber auch auf meinem MachX02. Ich bin auf der Suche nach einen Dual-Port-Ram, welches allen FPGAs ( mit genügend Speicher ) läuft. Als mögliche Realisierung fällt mir das Round-Robin-Verfahren ein: Abwechselnd jeden Port des Rams "pollen" und dann die Verfügbarkeit des Ergebnisses mit einem Ready-Flag melden.
Weltbester FPGA-Pongo (Gast) >Zielführender fände Ich solche Themen wie: >"Wie bekomme Ich einen FPGA mit einem Microcontroller verbunden" >"Wann schalte Ich einen FPGA vor einen Microcontroller" >"Wann benutze Ich überhaupt einen FPGA bei den immer weiter wachsenden >Funktionen der Microsontroller" Ich sehe da jetzt nichts, was dagegen spricht, entsprechende Threads zu eröffnen, falls Fragen in der Richtung bestehen ;-)
>> Nun stellt sich aber die Frage, wie realisiert man am besten ein >> Dual-Port-Ram? Autor: Bitwurschtler (Gast) >mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer >Toolchains. Kann es sein, dass die erzeugten Cores nur auf Xilinx laufen? Eigentlich sollte VHDL ja für alle FPGAs kompilierbar sein. Ich vermute, dass viele Hersteller FPGAs mit ähnlichen Eigenschaften produzieren und dass sie zunehmend Versuchen, mit proprietären Tools die Benutzer an sich zu binden. Wenn man ein größeres Design mit einem der Tools gemacht hat, wird es einem sehr schwer fallen auf das FPGA eines anderen Herstellers umzuziehen. Dem möchte ich entgegen wirken, in dem ich nach "generischen" Designs suche, die überall laufen.
chris schrieb: >>> Nun stellt sich aber die Frage, wie realisiert man am besten ein >>> Dual-Port-Ram? > Autor: Bitwurschtler (Gast) >>mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer >>Toolchains. > > Kann es sein, dass die erzeugten Cores nur auf Xilinx laufen? > Eigentlich sollte VHDL ja für alle FPGAs kompilierbar sein. Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die Verifikation von Digitaler Logic (egal ob TTL-Grab oder ASIC). Ferner sollte der Coregen eine Netzliste (*.ncd) rauswerfen, den VHDL-code den du da siehst ist für die Simu oder ein Wrapper damiti die primitive in den Top-level passen. > Ich vermute, > dass viele Hersteller FPGAs mit ähnlichen Eigenschaften produzieren und > dass sie zunehmend Versuchen, mit proprietären Tools die Benutzer an > sich zu binden. Nein, die Hersteller binden den Kunden mit spezif Eigenschaften ihres FPGA's und über den Preis. Da die tools eh meist verschenkt sind kann man damit keine Kunden binden. bestenfalls die dummen/faulen die die Portierung Ihres design scheuen. > Wenn man ein größeres Design mit einem der Tools gemacht > hat, wird es einem sehr schwer fallen auf das FPGA eines anderen > Herstellers umzuziehen. Nein. > Dem möchte ich entgegen wirken, in dem ich nach "generischen" Designs > suche, die überall laufen. Das ist doch easy, mach einfach für jede Architektur jeweils den passendn Code und schalte per Präprozessor (#ifdef) um. Oder benutze/entwickle einen Coregenerator der den für die jeweilige Architektur optimalen VHDL-Code auswirft.
chris schrieb: > Was mir bisher auffällt: Die Ram-Designs haben fast nie > Tristate-Datenanschlüsse so wie es bei physischen RAM-Bausteinen der > Fall ist, sondern immer getrennte Ein- und Ausgänge. Sehe ich das > richtig? Nicht ganz, bis auf historische FPGA's (Spartan/Virtex 2?) sollte kein FPGA interne Tristates besitzen. > Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann > man schneller Designs machen, braucht aber mehr Glue-Logic, weil man > keinen Tri-State-Bus verwenden kann. wenn du "schnell designs machen" meinst dann nein wenn du aber schnell*ere* designs machen" meinst dann ja. Der Tristatebus ist einfach erweiterbar, denk mal an Steckkarten und wirklich aufwendig sind multiplexer im FPGA nicht wirklich. Beitrag "Open Collector und Tristate" Beitrag "Problem mit tristate Bus" https://books.google.de/books?id=D0_pBQAAQBAJ&pg=PA336&lpg=PA336&dq=FPGA+++tristate+bus&source=bl&ots=16b9dpI9zm&sig=1iWC4efNNUq3f_jO_azTv-uzk7o&hl=de&sa=X&ved=0ahUKEwi7tKmk9JLXAhULExoKHWo7BfQQ6AEIfzAJ#v=onepage&q=FPGA tristate bus&f=false https://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs
chris schrieb: > Das würde bedeuten, dass Dein Fifo-Design > http://www.lothar-miller.de/s9y/archives/21-FIFO.html > nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft. > Scheinbar läuft es aber auch auf meinem MachX02. Glück gehabt, Lottoschein her! Natürlich wird der Fifo dort auf jedem FPGA implementiert. Nur kann es eben sein, dass kein RAM-Block verwendet wird, sondern alles auf Flipflops abgebildet wird. C. A. Rotwang schrieb: > Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die > Verifikation von Digitaler Logic Es funktioniert meiner Ansicht nach aber trotzdem gar nicht mal so schlecht...
:
Bearbeitet durch Moderator
C. A. Rotwang schrieb: > Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die > Verifikation von Digitaler Logic Tatsächlich, das steht hier beschrieben: http://www.gaisler.com/doc/vhdl2proc.pdf "When the language was first put to use, it was used for high-level behavioural simulation only . ’Synthesis’ into VLSI devices was made by manually converting the models into schematics using gates and building blocks from a target library." Jetzt erklärt sich mir auch die seltsame "Zweiteilung" dass manche Ausdrücke wie z.B. die "sensivity list ( process )" nur Einfluss auf die Simulation nicht aber auf die Synthese haben. Das Ganze ist schlich historisch gewachsen.
>> Das würde bedeuten, dass Dein Fifo-Design >> http://www.lothar-miller.de/s9y/archives/21-FIFO.html >> nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft. >> Scheinbar läuft es aber auch auf meinem MachX02. Lothar Miller schrieb >Glück gehabt, Lottoschein her! >Natürlich wird der Fifo dort auf jedem FPGA implementiert. Nur kann es >eben sein, dass kein RAM-Block verwendet wird, sondern alles auf >Flipflops abgebildet wird. Ich finde, dass sollte hier ein ausdrücklicher Hinweis hin, dass das nur für Xilinx-FPGAs gilt: http://www.lothar-miller.de/s9y/archives/20-RAM.html
chris schrieb: > Ich finde, dass sollte hier ein ausdrücklicher Hinweis hin, dass das nur > für Xilinx-FPGAs gilt: > http://www.lothar-miller.de/s9y/archives/20-RAM.html Ich finde, da sollte ein ausdrücklicher Hinweis hin, dass man beim allerersten Satz mit Lesen (und Verstehen) anfangen sollte.
Ja mit dem Lesen ist das so eine Sache. Denn wer schaut denn heute noch genau hin und versucht, etwas genau zu verstehen? Da steht: "Wer mit Xilinx FPGAs anfängt, der braucht früher oder später mal ein RAM." Da steht nicht, wer sich mit Lattice FPGAs beschäftigt, braucht kein Ram. Oder es steht auch nicht da, dass folgende Zeilen nur für Xilinx FPGAs gemacht sind. Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer Hersteller grundsätzlich so nicht geht.
chris schrieb: > Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs > beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet > sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer > Hersteller grundsätzlich so nicht geht. ... und ebensowenig einer, dass es mit FPGAs anderer Hersteller genauso geht ich persönlich bin froh (deshalb hier nochmal ein "Danke"), dass der Lothar das so einfach und übersichtlich aufgeschrieben hat (auch wenn ich möglicherweise mit meinen Alteras noch was ändern muss) und käme nie auf die Idee dranrumzumäkeln, dass ich doch tatsächlich noch ein wenig selber denken muss. Vielleicht solltest Du deine Anspruchshaltung kurz überdenken.
Ich verweise mal ganz lapidar auf die Doku der jeweiligen Toolchain. Denn etwas, das vor ein paar Jahren geschrieben wurde gilt nicht unbedingt immer und ewig. Manche sind auch heute noch der Meinung, ein "wait for rising_edge()" könne nicht synthetisiert werden...
chris schrieb: > Ja mit dem Lesen ist das so eine Sache. Denn wer schaut denn heute noch > genau hin und versucht, etwas genau zu verstehen? > > Da steht: > "Wer mit Xilinx FPGAs anfängt, der braucht früher oder später mal ein > RAM." > > Da steht nicht, wer sich mit Lattice FPGAs beschäftigt, braucht kein > Ram. Oder es steht auch nicht da, dass folgende Zeilen nur für Xilinx > FPGAs gemacht sind. > Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs > beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet > sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer > Hersteller grundsätzlich so nicht geht. Sag mal selber ausprobieren oder die Dokumentationen der Hersteller lesen ist nicht so Dein Ding? Die Beschreibung die Lothar auf seiner Seite hat funktioniert auch prima bei Alters/Intel. Dual Port sollte auch möglich sein ohne Coregen wenn man es sauber hinschreibt so dass es die Toolchain versteht. Probiere das doch mal aus und gucke was die Software macht.
>Sag mal selber ausprobieren oder die Dokumentationen der Hersteller >lesen ist nicht so Dein Ding? Das mit der Mühe ist so eine Sache. Nicht jeder macht sich z.B. die Mühe, so einen Thread durchzulesen. >Die Beschreibung die Lothar auf seiner >Seite hat funktioniert auch prima bei Alters/Intel. sonst hättest Du meine Bemerkung oben nicht übersehen: chris schrieb >Scheinbar läuft es aber auch auf meinem MachX02.
C. A. Rotwang schrieb: > Nicht ganz, bis auf historische FPGA's (Spartan/Virtex 2?) sollte kein > FPGA interne Tristates besitzen. Das waren FPGAs aus der Steinzeit. Genau genommen waren es keine FPGAs, sondern PLDs. Das Thema kann man abhaken. Dennoch gibt es selbstredend Tristates: C. A. Rotwang schrieb: > chris schrieb: >> Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann >> man schneller Designs machen, braucht aber mehr Glue-Logic, weil man >> keinen Tri-State-Bus verwenden kann. > wenn du "schnell designs machen" meinst dann nein wenn du aber > schnell*ere* designs machen" meinst dann ja. Redet ihr aneinander vorbei? Was hat denn ein schnelles design mit Tristates zu tun? @chris: Nochmal: Lies Dir bitte die einschlägigen Herstellerangaben durch, statt hier einen Anfängerartikel nach dem anderen aufzumachen. FPGAs haben sehr wohl Tristates und zwar an praktisch allen Ein-und Ausgangen. Gerade die Trennung in Ein-Aus IST die Voraussetzung für eine Tristatefunktion, nämlich, indem man den Ausgang wegschaltet und den Eingang aktiv lässt. Sonst ginge das nämlich gar nicht. Sieh Dir einfach mal die IO-Schaltung der Pins an.
>Was hat denn ein schnelles design mit Tristates zu tun? Bsp: Eine MasterDevice hat getrennte Daten Ein- und Ausgänge. Es kann daher gleichzeitig lesen und Schreiben, während mit einem Tristate-Bus immer nur eine Richtung möglich wäre. Kleiner Merker für mich selbst: VHDL Signaldefintion "buffer" => nur Ausgang mit Tristate Möglichkeit, man kann den geschriebenen Wert auch lesen, nicht aber den von außen zugeführten Wert, wenn hochohmig geschaltet. VHDL Signaldefintion "inout" => Kann hochohmig geschalten werden, externer Wert wird kann im hochohmigen Zustand gelesen werden.
chris schrieb: > Kleiner Merker für mich selbst: ... Ist insofern falsch, als natürlich jeder Ausgang am FPGA-Pin (egal ob out, buffer oder inout) hochohmig geschaltet werden kann.
Weltbester FPGA-Pongo schrieb im Beitrag #5192146: > Dennoch gibt es selbstredend Tristates: > > > C. A. Rotwang schrieb: >> chris schrieb: >>> Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann >>> man schneller Designs machen, braucht aber mehr Glue-Logic, weil man >>> keinen Tri-State-Bus verwenden kann. >> wenn du "schnell designs machen" meinst dann nein wenn du aber >> schnell*ere* designs machen" meinst dann ja. > Redet ihr aneinander vorbei? > > Was hat denn ein schnelles design mit Tristates zu tun? > FPGAs haben sehr wohl Tristates und zwar an praktisch allen Ein-und > Ausgangen. Es geht hier um interne Tristates, also die Ausgänge der RAM-Blöcke im FPGA und die haben keine Tristates, da wird alles gemuxed. Gründe dafür sollen "Signal integrety" und Stromaufnahme sein, https://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs ; wobei ich aber auch denke das point2point Verbindungen schneller takt- und umschaltbar sind als Busse.
C. A. Rotwang schrieb: > Es geht hier um interne Tristates das hatte Ich durchaus aufgenommen und auch beantwortet, zudem nur noch hinzugefügt, dass es ja die Externen gibt um das Thema vollständig darzustellen. Zu der Frage, ob Tristates schneller wären, würde Ich sagen: Auch für die Internen "Nein", weil Ich auf 2 Leitungen keine laufzeitbedingten Umschaltpausen brauche und mit 100% streamen kann. Es braucht nur viele Verschaltungsresourcen - besonders bei SOC-Systemen! Sowas wie 2 hoch n+1 , bei n = Zahl der Zeilnehmer. Wenn man aber weiß, wie FPGAs intern aufgebaut sind und dass sie aus topologischen Gründen mit sehr viel Verschaltungstechnik im Vergleich zur Logik daherkommen (müssen, wegen der vielen Optionen), der versteht, warum man dort nicht auch noch bidirektionale Leitungen gebrauchen kann. Die Informationen werden durch Relaisstationen allenthalben aufgefrischt, vor allem die Takte und Resets und dies geht nur in eine Richtung. Echte lange Leitungen, die von zwei Seiten getrieben werden gibt es dort nur über 1-2mm und weniger und damit ist nichts anzufangen. Bei PLDs zog sich das quer durchs Design. Mit einer Schleife über mehrere Knoten hinweg hattest Du da mal gegatete und umgedrehte Signalinformatinoen aber dafür gerne mal 10ns an der Backe. Das kann man in modernen Schaltungen nicht gebrauchen, in denen ein Signal wenn möglich binnen 100ps an jeder Ecke im FPGA sein muss. Das steht allerdings alles schon in den Grundlagenartikeln hier und anderswo. Immer noch mehr chris-Themen brauchen wir dafür wohl nicht.
@Lothar Miller Hallo Lothar, ist dann Deine Aussage auch aufs FPGA Wiki im MC-Forum anwendbar? >Denn etwas, das vor ein paar Jahren geschrieben wurde gilt nicht >unbedingt immer und ewig. Manche sind auch heute noch der Meinung, ein >"wait for rising_edge()" könne nicht synthetisiert werden... siehe https://www.mikrocontroller.net/articles/VHDL Richtlinien Für VHDL Anfänger >Kein "after", "wait for" o.ä. verwenden, das ist nicht synthetisierbar oder muss der o.g. Beitrag aktualisiert werden? Danke für Deine Erklärung im Voraus Markus
Markus W. schrieb: > oder muss der o.g. Beitrag aktualisiert werden? Nein, denn ein "wait for" ist tatsächlich noch nicht synthetisierbar. Das war ein Typo, ich meinte ein "wait until"... :-/ Und das geht schon lange, zwischenzeitlich dürfte das jeder können: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html Es ghte aber evtl. noch einiges mehr, wobei sowas dann schnell in Richtung "Trickserei" geht: http://www.lothar-miller.de/s9y/archives/47-wait-im-Prozess.html
Thread beobachten
Seitenaufteilung abschalten
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.