Hallo, Koennen die FPGA Experten mir Hinweise geben wie ein Multistop Zähler mit 27 Binärstellen bei 100 MHz Clock realisiert werden kann. Es geht um ein Timingsystem mit GPS 1pps Synchronisation. Gute GPS Uhren liefern nun ca 15 ns Genauigkeit (Trimble Resolution T) Wenn der 100 MHz Oszillator eine Stabilität von 10e-8 über eine Sekunde hat, dann lassen sich beliebig viele Ereignisse durch eine schnelle Auslese des Zählers in eine Art Fifo speichern und sind relativ zu UTC absolut auf ca 20 oder 30 ns bestimmbar. Dies ist etwa bei der Gewitterortung durch Laufzeiten interessant. Die Auslese des Fifos soll dann ein ATMega128 übernehmen. Man kann die Sache auch mit 74LV8154 oder 74HC590 machen: hat aber nur ein Register und auch nur 25 oder 40MHz. Beste Gruesse dvh
Hallo Daniel, Es mag sein das diese Bezeichnung hier unbekannt ist. Sie ist es jedoch nicht für Zeitmesssysteme etwa in der Teilchenphysik. Es geht darum, dass man mit einem Messkanal mehrere in der Regel dicht aufeinanderfolgende Stopereignisse messen kann. Denke an einen 100m Lauf und ich drücke bei jedem ankommenden Läufer auf die Uhr die dann alle Stopzeiten in eine Liste schreibt. Wenn mehrere 100 m Läufe parallel abgewickelt werden, kann man mit einer Uhr und Multistart und Multistop alles erledigen wenn zu jedem Start oder Stopereignis Zeit und Typ registriert wird. Später ergeben sich die Laufzeiten aus den Differenzen. Hier soll der Start ein GPS 1puls-pro-sekunde Signal sein und die Stops etwa Blitzereignisse die aus ganzen Gruppen von Impulsen im Abstand von us bestehen. Die Zeiten für diese in UTC koennen dann per Internet mit anderen Messstationen kommuniziert werden und der Ort des Geschehens aus 3 Messungen rekonstruiert werden. Siehe auch www.blids.de. Ich wollte von den Experten wissen 1) gibts das schon in FPGA 2) in welche FPGAs passt das rein 3) und nach welchen Regeln kann das vom Amateur entwickelt werden. Gruesse Dietrich
Hallo, ich habe nun einigermaßen verstanden, um was es geht. Zu den Fragen: 1. Weiß ich nicht 2. Mit einem Xilinx Spartan3 XC3s1000 bist Du auf der ganz ganz sicheren Seite. 3. Wer VHDL kann, Zeit hat und sich nicht dumm anstellt kriegt das schon hin(ich hoffe ich habe damit deine Frage beantwortet) Daniel
Hi, also ich denke, dass ein XC3s1000 hier total oversized ist. Soetwas sollte auch in sehr viel kleiner Chips Platz haben. Es werden ja nur 27Bit pro Stop gebraucht und das schuettelt jeder FPGA locker aus der Hemdtasche. Ich denke auch, dass soetwas in VHDL nicht sonderlich komplex sein sollte. Da ich aber bis jezt noch so gut wie nichts mit VHDL gemacht habe werd eich entsprechend auch kein Design aufweisen keonnen ;) Von der Machbarkeit wuerde ich aes aber als realistsich einschaetzen. So wie ich das sehe besteht die Sache aus einem 27Bit Zaehler, und mehreren 27Bit Registern, die nacheinander mit dem Zaehlstand gefuellt werden, wenn ein Stoperreignis auftritt. Diese koennen dann irgendwie ausem FPGA ausgelesen werden und in einem MC oder PC weiterverarbeitet werden. Ein CPLD wuerde vll. auch noch gehen, nur hat man da halt nciht so viele Flip-Flops um die Zwischenstaende zu speichern. Wenn aber die Zeit zwischen den Stops ausreicht, um jeden einzeln aus dem CPLD auszulesen reicht auch ein kleiner CPLD und ein MC, der staendig das Stopregister ausliest. Gruss Tobias
Für die Realisierung ist es viel besser, getrennte Zähler zu nehmen, statt nen Haufen Register. Dann kann man nämlich die Zähler asynchron aufbauen und muß nur jeweils die erste Stufe toren (count enable). Damit ergeben sich erheblich weniger Routingressourcen, weniger Lastkapazität des Zählers, schnellere Zählfrequenz, geringerer Stromverbrauch. Peter
Sehe ich das recht, es gibt einen einzigen 27Bit-Zähler mit 100 MHz Takt und viele damit verbundene 27+n Bit breite Register, die nacheinander zu unbekannten Zeiten den momentanen Zählerstand abspeichern, zusammen mit einer eindutigen Identifikation, welches von n verschiedenene möglichen Ereignissen zu diesem Zeitpunkt passierte ? Denn nur Zählerstände zu registrieren wäre etwas wenig, mit den Daten kann man hinterher nicht viel anfangen. Ich suche auch sowas ähnliches, für einen Scintillationsdetektor. Der kann auch im Mikrosekundenabstand Lichtpulse detektieren, die nach Größe klassifiziert abgelegt werden ( Histogramm-Darstellung.). Statt der vielen parallel am Zähler angeschlossenen breiten Register ist natürlich ein Fifo oder Ram die richtige Speicherart.
2 hoch n Ereignisse muß es heißen. Multistart ist hier nicht nötig, also viele Zähler scheinen mir unnötig. Alles ist auf den GPS-Startimpuls bezogen.
Warum eigenlich so kompliziert? Ein 27 MHz Zähler läuft durch, und bei jedem Zählimpuls wird der Zählerstand in ein FIFO übernommen. Die Länge des FIFO's bestimmt die Anzahl der Ereignisse, welche gezählt werden können. Wenn man das FIFO mit 32 Bit Busbreite auslegt, dann könnte man sogar noch 5 Bit als Zähler für die Ereignisse abspeichern. Über einen einfache Datenbus wird das FIFO vom Atmel ausgelesen. Braucht ein kleines FPGA, das allerkleinste geht schon. Grüße Klaus
welches FPGA du da brauuchst, hängt von der größe des FIFO ab.. der Zähler an sich ist kein Problem. Ich würde einen Zähler verwenden, dessen Wert immer beim Ereigniss mit eventuell nötigen Zusatzinformationen (z.B Ereignisquelle) in ein RAM-Basiertes FIFO geschrieben wird. Sowas sollte in eine winziges FPGA reinpassen (siehe auch Klaus) Und wenn du nen µC in ddas FPGA dazupackst, dann kannst auch gleich das FIFO im FPGA auswerten und die Daten z.B. über RS232 oder Ethernet oder sowas verschicken...
Ich dachte, es laufen X Zähler parallel... X hätte ja auch 200 sein können, deswegen habe ich zu einem XC3S1000 geraten. Aber wenn nur ein Zähler läuft geht auch schon ein XC3s50 oder XC3s200...
Hm, welhce datenmenge fällt an?, also wieviele Zählerstände in welcher Bit-Breite sind zu erwarten, also wie oft tritt ein ereignis ein schlimmstenfalls (Burst) ein? und sind 100 MHz das limit? Etliches kann man in die erwähnten Fifos zwischenspeichern und ab und zu in einen externen RAM o.ä ablegen. Fals du aber 150 MHz anpeilst (6 ns Auflösung -> 2.5 bessere auflösung als GPS) und dir bretzeln die ereignisse nur so rein (jeden takt ein neues -> BTW, was heisst Ereignis, ist das ein Impuls?, der sollte auch nicht zu lang oder zu kurz sein, bei 100 MHZ Takt (samplefrequenz eigentlich mind 10 ns + setup +holdzeit) dann wirst haarig mit in den speicherschreiben (Jennfalls bei SDRAM und Konsorten, ein SDRAM Interface mit 166 MHz am Spartan3 ist kein gesellenstück) . Dann schau mal bei altera die haben viel RAM auf dem FPGA, oder nimm als speicher (zusätzlich zu den Fifos) schnellen SRAM. Also viele Ereignisse (zuviele für Fifo aus internen RAM) -> Altera-FPGA sonst spartan3 (da kenn ich mich besser aus). Mit geschick sollten 150 MHz für 28 bit counter machbar sein. bei höheren frequenzen würde ich auf schnelle (höher speedgrad) kleine (der kleinste) Virtex-2 schielen. Bei größer 250 MHz würd ich vorsichtshalber die weiße Fahne bereit legen und ein paar testdesigns synthetisieren. Aber, die Krux liegt IMHO im erkennen der ereignisse, also die breite der Impulse die zu zählen sind. Liefert dein Aufbau überhaubt so kurze Impulse?
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.