Hier im Forum gibt es ja immer wieder Threads dazu, wie man einen reziproken Frequenzzähler baut: Beitrag "STM32F429-Discovery Recycling: 90 MHz Frequenzzähler mit TFT" Es gibt sogar einen Artikel zum Verfahren: https://www.mikrocontroller.net/articles/Frequenzz%C3%A4hlermodul#Messverfahren Mich würde die Frage interessieren, wie man einen reziproken Frequenzzähler im FPGA auf einfache Art realisieren könnte. Es soll dabei aber auf die Verwendung eines CPU-Kerns für die Division verzichtet werden.
Also spontan fallen mir ein: - Statt einer Division eine LUT verwenden. - Divions in Logik durchfuehren, fertige IPs gibts hierzu zuhauf
Schau die das Service Manual vom HP5345A an, da ist alles ohne CPU nur mit TTL und ECL. Irgendwo gibt es auch noch ein altes HP-Journal wo die State-Machine die alles steuert näher beschrieben ist. Es gibt auch die Realisierung eines Zähler mit 7-Segment Anzeigen komplett in einem CPLD aber ich bin mir jetzt nicht sicher ob der reziprok ist.
>Schau die das Service Manual vom HP5345A an,
Faszinierend, dass es damals solche Service-Manuals gab. Das sind ja
quasi die ganzen Konstruktionsunterlagen.
Ich glaube der Zähler ist aber so aufwändig, dass sich selber denken
eher lohnt.
Georg schrieb: > Es soll dabei aber auf die Verwendung eines CPU-Kerns für die Division > verzichtet werden. Ja nun, ein "CPU-Kern" verwendet ja auch nur eine Divisionseinheit, die irgendwo in Hardware realisiert wurde. Diese Divisions-Hardware musst du jetzt nachbauen. Und das einfachste ist, es so zu machen, wie du es in der dritten Klasse gelernt hast: Stelle für Stelle. Die Hardware hat dabei den Vorteil, dass es wegen des Zweiersystems nur ein "passt nicht rein" oder ein "passt rein" gibt und dann 0 oder 1 rauskommt. Siehe den Beitrag "Division in VHDL"
:
Bearbeitet durch Moderator
> von Hans-Georg L. (h-g-l) >Hier noch der Link zum Journal vom Juni 1974 >http://hparchive.com/Journals/HPJ-1974-06.pdf Wow, was für eine geniale Zeitschrift. Ich wusste gar nicht, dass es so was gab. War das nur HP-intern verfügbar oder auch für die Allgemeinheit? Wenn man sich überlegt, dass dir Artikel von 1974 waren und der Referenztakt 500MHz war ... echt High-Tec und vermutlich nicht ganz billig damals.
Georg schrieb: > Wow, was für eine geniale Zeitschrift. Ich wusste gar nicht, dass es so > was gab. War das nur HP-intern verfügbar oder auch für die > Allgemeinheit? Die waren denke ich schon allgemein verfügbar, sind auch sehr bekannt. Damals war das keine so große Gefahr, denn einem Konkurenten hätten eh die Teile gefehlt bzw. der Nachbau wäre mindestens gleich teuer wie das Original gewesen. Zumal man die ASICs oder Programmcode eh selber machen hätte müssen. Das ist ja wie mit dem Coca Cola Rezept, das kann man auch in jedem Chemielabor nachmessen, aber was hat man davon? Cola ist schon billig genug und wie es andere Marken zeigen kommt man mit einer anderen Geschmacksrichtung (Pepsi) eh besser an.
Für mich sieht es so aus, als wenn die State Machine ein selbstgebauter Prozessor ist. Interessant: Der Artikel ist von 1974 und 1971 gab's schon den Intel 4004. Der Einfachheit halber hätten sie vielleicht den nehmen sollen. Der Aufwand für den Eigenbauprozessor scheint mir immens.
Georg schrieb: > Es soll > dabei aber auf die Verwendung eines CPU-Kerns für die Division > verzichtet werden. Geht es Dir dabei um die "Sportlichkeit" oder soll es besonders günstig werden? Ein "Reziproker Zähler" trägt die Division schon im Namen ;-) Lothar M. wird sicherlich wissen, wieviel "Einheiten" für Fließkommaberechnungen benötigt werden und wie sich das kostenmäßig auswirkt. Für hohe Auflösungen (> 7 Stellen) braucht man Berechnungen im double Format (64 bit). Die schafft selbst ein kleiner µC (ATtiny85) in ca. 1 - 3 ms. Kann da ein passendes FPGA günstiger sein - ganz abgesehen vom Entwicklungsaufwand?
>Geht es Dir dabei um die "Sportlichkeit" oder soll es besonders günstig >werden? Mehr um die Sportlichkeit. Im Moment bin ich noch in der Analysephase und schaue, was es so gibt. Interessant an dem HP-Zähler finde ich die Eingangsstufe für 500MHz, für die ja ein eigener Chip entwickelt wurde. Hier im Forum gibt es ein Projekt bis 100MHz mit MCU, bei dem ein TTL -93 Zäher als Vorteiler verwendet wird. Hier gibt's noch eine Version interessante Version mit STM32H750 Beitrag "8-stelliger Frequenzzähler, reziprok, STM32F7xx" Wie schnell könnte ein FPGA ohne externen Vorteiler zählen? z.B. ein MAX1000 Dev-Board?
Georg schrieb: > Wie schnell könnte ein FPGA ohne externen Vorteiler zählen? > z.B. ein MAX1000 Dev-Board? Darin sind 2 Fragen versteckt: 1. wie schnell könnte das FPGA zählen? 2. welche Frequenz "kann" das erwähnte Dev-Board? Und da bin ich mir recht sicher, dass nicht das FPGA die begrenzende Komponente ist. Denn schon ein uraltes S3 FPGA konnte 500MHz zählen (die untersten 2 Bit werden manuell zum 2-Bit-Zähler verdrahtet und der Rest des Zählers läuft mit 100MHz). Für die Übernahme des Zählerwerts in eine andere Taktdomäne muss der aber natürlich angehalten werden. Sonst geht schon das Zwischenspeichern schief. m.n. schrieb: > wieviel "Einheiten" für Fließkommaberechnungen benötigt werden Ich sehe da jetzt erst mal keinen Bedarf für Fließkommaberechnungen. Im FPGA kann ich einen Integer ja so lang machen wie es mir gefällt...
Georg schrieb: > Für mich sieht es so aus, als wenn die State Machine ein selbstgebauter > Prozessor ist. > Interessant: Der Artikel ist von 1974 und 1971 gab's schon den Intel > 4004. > Der Einfachheit halber hätten sie vielleicht den nehmen sollen. Der > Aufwand für den Eigenbauprozessor scheint mir immens. Eigentlich nicht, die Logic für ne FSM entwickeln und zu optimieren ist im Informationstechnik-Studium ne einfache Übungsaufgabe, das geht schneller als der räudige 4 bit Prozessor von intel der in mehreren Chips daher kommt: http://www.vintagecalculators.com/assets/images/NCR18-36_4.jpg Einfach ein kariertes Papier nehmen und die Logiktabellen aufschreiben und daraus die Gatter/Muxer ablesen. vieles kann man auch mit zwei PROMS erschlagen oder a bisserl PAL/GAL. Und für die Programmierung hatte man 1973 auch nicht viel mehr als kariertes Papier zum Zeichnen des PAP und zum Assembler-Coden per Hand zur Verfügung. Siehe auch die Original Unterlagen von Steve Wozniak (Apple-Gründer, Ex-HP): https://www.cnet.com/pictures/the-original-apple-os-documents-pictures/13/
In der Seite 11 des HP Journal wird von einem 15 digit BCD Rechner der mit TTL realisiert wurde. Es hat warscheinlich eine nähere Ähnlichkeit mit dem Rechnerwerk des HP 35 (der war aber PMOS), denke ich. Das finde ich faszinierend.
Lothar M. schrieb: > m.n. schrieb: >> wieviel "Einheiten" für Fließkommaberechnungen benötigt werden > Ich sehe da jetzt erst mal keinen Bedarf für Fließkommaberechnungen. Im > FPGA kann ich einen Integer ja so lang machen wie es mir gefällt... Theoretisch ja, bei hoher Auflösung kann die Umsetzung eine Qual werden, wobei insbesondere Unterläufe verhindert werden müssen. In C programmiert hatte ich das einmal mit 32 Bit Variablen gemacht, was lediglich vier Dezimalstellen brachte. Aber gut, andere Leute können das vermutlich besser ;-) Ein Rat bezüglich der Eingangsfrequenz: Es reichen schon max. 10 - 50 MHz. Für höhere Frequenzen (GHz-Bereich) braucht man sowieso einen Vorteiler, der die Auflösung nicht vermindert. Wichtig ist allein, die Zeitmessung so hoch wie möglich aufzulösen. Mit 500 MHz Referenztakt kommt man auf knapp 9 Stellen/s.
m.n. schrieb: > Wichtig ist allein, die Zeitmessung so hoch wie möglich aufzulösen. Mit > 500 MHz Referenztakt kommt man auf knapp 9 Stellen/s. Hiefuer moechte ich mal gerne das Stichwort "Time-to-Digital Converter" einwerfen. Da gibt es ein paar echt tolle Ansaetze wie man das im FPGA realisieren kann um eine hohe zeitliche Aufloesung zu realisieren. Ob das im Kontext mit dem reziproken Frequenzzaehler Sinn macht, muss aber jemand anderes beurteilen.
Irgendwer hat mal die PLL-Teile eines FPGA in einem Reziprokzähler zur höheren Auflösung eingesetzt, also Phasenversatz zum Zähltakt. Beitrag "Re: Frequenzmessung ATmega 16/32" da hatte ich es erwähnt https://ukw-tagung.org/_downloads/UKW-Tagung_Vortraege_1981_bis_2014.pdf 2005 Boven, Paul PE1NUT Erhöhung der Auflösung bei Reziprok-Zählern der wars Beitrag "Re: LWL Laufzeitmessung" da hatte ich sogar eine Seite aus dem Skript gepostet. >Time-to-Digital Converter https://www.ti.com/lit/ds/symlink/tdc7200.pdf Resolution:55 ps Beitrag "2 x Musteraufbau 10-stell. Frequenzzähler" ein Frequenzzähler damit, kein FPGA sondern STM32F407
:
Bearbeitet durch User
Zur Kehrwertberechnung: Ich hatte damals auf dem Weinheimer Flohmarkt mehrere 8 1/2 stellige LC-Displays gefunden, und wollte damit einen reziproken Frequenzzähler bauen. Dafür hatte ich den AVR 8515 ( noch ohne "mega") ausgeguckt. Eine längere Internetrecherche fand mathematische Routinen bis zur 32 Bit Division in AVR Assembler, ohne Multiplikationsbefehl. Sollte für 8 1/2 Stellen eigentlich reichen, 2^32 Bit sind 4294967296, also deutlich mehr als 199999999. 2^24 = 16777216 reicht noch nicht. Aber für Integerarithmetik müssen es ganze Zahlen sein. Ein Kehrwert in Integer muss aber auch als Ergebnis wieder ein Integer 32 Bit ergeben. Statt 1/x, was gebrochene Binärstellen liefert, muss ich (2^32 / (2^32*x)) berechnen. Also eine Division durch eine 64 Bit Zahl. Dann ist der ganzzahlige Nachkommaanteil der Kehrwert von x. Gibt es einen anderen Weg, der das vermeidet, oder muss man das für jeden Reziprokzähler so machen? Ich habe das Projekt dann aufgegeben, testweise hat die Kehrwertbildung funktioniert, hier mein letztes Programm dazu, völlig unfertig, nur zur Abschreckung (oder Motivation).
Die Formel mit 2^32 war Unsinn, ich dividiere eine 64-Bit-Zahl (hier z.B. 10^16= 100 Mio^2) durch das 32 Bit-Zählergebnis (hier 10^8 bzw. 2*10^8 =100 Mio bzw. 200 Mio) und erhalte einen 32 Bit-Kehrwert (hier 100_000_000 bzw. 50_000_000 was noch auf das 8 1/2-stellige Display passte). Das wurde auch tatsächlich angezeigt. >Die schafft selbst ein kleiner µC (ATtiny85) in ca. 1 - 3 ms. Ich sollte mal die Ausführungszeit messen, eine Dauerschleife, die an eine Portpin einen Impuls pro Schleifendurchlauf ausgibt mit dem Oszilloskop gemessen ist genau genug, sonst müsste ich alle Takte der Schleifen abzählen. Die Diskussion zu Division in VHDL habe ich jetzt mal angeschaut, Lothars Text dazu auch. Sein Link zur Uni Ulm liefert leider 404 Error. http://www.informatik.uni-ulm.de/ni/Lehre/SS05/CompArith/ das geht nur bis ArithintegerD, -E fehlt Wie ist die Ausführungszeit im Vergleich zu einem Mikrocontroller?
:
Bearbeitet durch User
http://avr-asm.tripod.com/math32x.html Der Autor der math32-Library für AVR gibt die Anzahl Taktzyklen für div32b an mit min/max 528|688, bei 16 MHz Takt wären das 33-43 µs, scheint mir etwas optimistisch. Ich sollte mal nachmessen. Schneller als das Auge ablesen kann macht für ein Display sowieso keinen Sinn. Nutzt ein Multiplizierer bzw. ein Multiplizierbefehl etwas? Wenn man einen festen Divisor hätte, könnte man dessen Kehrwert vorab berechnen und damit multiplizieren, aber hier ist der Dividend fest und der Divisor variabel. Gibt es einen anderen Berechnungsweg, bei dem eine Multiplikation hilft?
:
Bearbeitet durch User
Hallo, ich möchte nochmal auf die Frage vom Anfang zurück kommen. Es geht ja gar nicht um AVR Controller sondern um FPGAs. Zur Division: Einen CPU Kern braucht man ja nicht für die Division. Aber einen Modul, das dir die Division macht schon. Lothar Miller hat auf seiner Seite was stehen: http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html Das funktioniert sehr gut. Ich habe das auch für meine Sachen schon verwendet. Ich habe das allerdings auf signed Werte erweitert. Ist es das was noch fehlt? Oder hast du was anderes gemeint? Grüße, Jens
>Ist es das was noch fehlt? Oder hast du was anderes gemeint? Ach es ist mehr eine Art Sammlung, was man alles braucht. Ich überlege aber mittlerweile tatsächlich, ob ich vielleicht einen Zähler real bauen sollte. Vielleicht mit dem MAX1000 für 25 Euro und einem Siebensegmentboard für 5Euro. Würde nur noch ein guter Eingangsverstärker fehlen. Wobei einen TCO bräuchte man vielleicht noch, weiß jemand eine Quelle?
Georg schrieb: > Würde nur noch ein guter Eingangsverstärker fehlen. > Wobei einen TCO bräuchte man vielleicht noch, weiß jemand eine Quelle? Mach Dir erst einmal keine Gedanken über spezielle Hardware; etwas zu kaufen ist immer die einfachste Sache bei einer Entwicklung. Reziproke Zähler sind besonders gut für niedrige Frequenzen geeignet. Nehmen wir an, Du möchtest 50 Hz auf vier Stellen genau messen mit einer Messrate von einer Messung pro Sekunde. Die Referenzfrequenz beträgt 10 MHz. Der Ereigniszähler liefert bei jeder Messung über eine Sekunde einen Stand von 49 oder 50. Die Zeit wackelt ein wenig mit der Eingangsfrequenz und der zugehörige Zähler liefert Werte im Bereich von beispielsweise 9998011 bis 10001836. Um zu sehen, ob Du mit Deinem Vorhaben erfolgreich sein kannst, schreibe den Code, der aus diesen Zählerständern korrekte Ergebnisse liefert. Nicht mehr - nicht weniger. Wenn es nicht klappt, mußt Du garnicht weiter über TCXO, hochfrequente Eingangsstufe und viele, viele Stellen Auflösung nachdenken. Wenn es klappt, weißt Du, was Du ergänzen mußt, um höhere Leistung zu bekommen.
Für 7,10€ gäbe es noch ein Gowin GN1 FPGA-Board ... das Problem könnte dann vielleicht die Entwicklungsumgebung werden.
Christoph db1uq K. schrieb: > Die Diskussion zu Division in VHDL habe ich jetzt mal angeschaut, > Lothars Text dazu auch. Sein Link zur Uni Ulm liefert leider 404 Error. > http://www.informatik.uni-ulm.de/ni/Lehre/SS05/CompArith/ > das geht nur bis ArithintegerD, -E fehlt Die Berechnung ist jetzt in http://www.informatik.uni-ulm.de/ni/Lehre/SS05/CompArith/ArithIntegerD2.pdf zu finden. Ich habe den Link angepasst. > Wie ist die Ausführungszeit im Vergleich zu einem Mikrocontroller? Weil es "den" Mikrocontroller nicht gibt und zudem auch solche mit Divisioneinheiten in Hardware oder solche, bei denen die Division in Software ausgekaspert werden muss, ist eine Antwort auf diese unverbindliche Frage mindestens genauso unverbindlich und nutzlos. Aber auf dem FPGA braucht diese "Dritte Grundschulklasse"-Division jeweils 1 Taktzyklus pro Ergebnisbit. Der Rest ist leicht zu rechnen.
:
Bearbeitet durch Moderator
Interessant ist auf jeden Fall der Stanford SR-620. 12 digits bei 1 sec "Torzeit". < https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiQstCdr8PtAhVxMewKHQfqCwUQFjAAegQIBBAC&url=https%3A%2F%2Fwww.thinksrs.com%2Fdownloads%2Fpdfs%2Fmanuals%2FSR620m.pdf&usg=AOvVaw0FDNn-67G9Y4gfH71sSPLs > Als im März 2018 die europäischen Uhren falsch gingen, wegen irgendwelcher Streitigkeiten auf dem Balkan: < https://www.flickr.com/photos/137684711@N07/38870750440/in/album-72157662535945536/lightbox/ > Ich frage mich, wie der klitzekleine Netztrafo das schafft, die ganze Platine zu ernähren. Der Zähler hat übrigens einen Z80 und wird, glaube ich, noch immer gebaut. Gruß, Gerhard
Ein Frequenzzähler mit Arduino, bei dem die obige LED-Anzeige verwendet wird: https://hackaday.com/2020/12/10/easy-frequency-counter-looks-good-reads-to-6-5-mhz/
Schade, dass die Schaltpläne fehlen. Die Schaltungsbeschreibung ist aber sehr ausführlich und in der Stückliste stehen viele MC10H... ECL-Typen, damit wird schon mal eine direkte Zählung bis 250 MHz möglich. Der 10 MHz Quarzofen-Ausgang wird anscheinend verneunfacht, und die 90 MHz mit Quarzfiltern gesäubert. Auf PDF-Seite 30 steht ausdrücklich, dass es ein reziproker Zähler ist. Der Prozessor ist ein Super-8 Z8800 mit 20 MHz Takt https://datasheetspdf.com/pdf-file/1412045/Zilog/Z8800/1 der hat einen DIV-Befehl "DIV dst, src" Datenblatt der CMOS-Version: https://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTl3Y3pBeE5EWXVjR1Jt. "Improved Z8® instruction set includes multiply and divide instructions"
Gerhard H. schrieb: > Interessant ist auf jeden Fall der Stanford SR-620. > 12 digits bei 1 sec "Torzeit". Wo steht das genau? Georg schrieb: > Ein Frequenzzähler mit Arduino, bei dem die obige LED-Anzeige > verwendet > wird: > https://hackaday.com/2020/12/10/easy-frequency-counter-looks-good-reads-to-6-5-mhz/ Was hast Du vor? Wird das FPGA auf das Gehäuse geklebt?
m.n. schrieb: > Gerhard H. schrieb: >> Interessant ist auf jeden Fall der Stanford SR-620. >> 12 digits bei 1 sec "Torzeit". > > Wo steht das genau? > Weil ich einen habe und bis 12 zählen kann? Oder weil das Ding Einzelpulsbreiten auf etwa 20 ps ausmessen kann? Das ist nicht ein simpler Invers-Counter, der benutzt eine Art Nonius-Verfahren wie eine Schieblehre mit time-tagging der Nulldurchgänge. Aus dem Kopf kann ich's jetzt auch nicht mehr erklären, Hauptsache er tut's. Er funktioniert jedenfalls nicht wie sein Hauptkonkurrent, der HP5370A / B, der Start/Stopp-Oszillatoren benutzt. < http://www.hoffmann-hochfrequenz.de/downloads/SR620_Universal_Time_Interval_Counter_Schematics.pdf > (bleibt nicht lange dort) Ich glaube, in meinem einen Z80H gesehen zu haben. Ich hatte ihn aber nur offen um zu kontrollieren, ob er die gute Zeitbasis hat (Wenzel). Die machen sicher auch Produktpflege. Gruß, Gerhard ed. der Z80H ist auch drinnen. Die analoge Aufbereitung ist wohl ein grösserer Teil als das was ins FPGA könnte. Ich habe auch mal überlegt, einen 10 GHz-Serdes im FPGA als Zähler zu benutzen.
:
Bearbeitet durch User
>12 digits bei 1 sec "Torzeit" - Wo steht das genau?
Ich sehe hier auch nur in dem Diagramm für 1 sec etwas zwischen 10^10
und 10^11. Das ist allerdings die "fraktionale Auflösung"
Der Z80H macht anscheinend die "Bildschirmausgabe" auf ein Oszilloskop.
Auf PDF-Seite 92 im Handbuch ist das erklärt.
:
Bearbeitet durch User
Gerhard H. schrieb: > Weil ich einen habe und bis 12 zählen kann? Ich kann auch bis 12 zählen! Nur hier habe ich Probleme, Dir zu folgen. Im verlinkten Datenblatt steht als Fehlerangabe zur Frequenmessung: +/- 100 ps [350 ps max] bezogen auf 1 s Messzeit. 100 ps sind 1e-10 s und ergeben somit 10-stellige Genauigkeit zzgl. Fehler der Referenzfrequenz.
Dass die letzte Stelle noch stimmt, das glaub' ich auch nicht.
:
Bearbeitet durch User
Der Standard-Zähler macht ein Tor z.B. für genau eine Sekunde auf und zählt, wie viele Eingangsimpulse in dieser Zeit ankommen. Sind es 100 Millionen -> 100 MHz am Eingang. Das macht sich nicht so gut, wenn die Eingangsfrequenz niedrig ist. Bei 9.5 Hz am Eingang bekommt man 9 oder 10 Pulse während der Sekunde Torzeit. Das hat mit Genauigkeit nix mehr zu tun. Dann nimmt man besser die Eingangsfrequenz als Tor und zählt mit einer möglichst hohen Frequenz, wieviel Referenzzyklen in die Torzeit passen. Dann bekommt man aber keine Frequenz als Ergebnis sondern die Periodendauer. Die Frequenz ist dann 1 / Dauer, daher Reziprokzähler. Beim Nonius-Verfahren täuscht man an, dass man z.B. die Eingangsfrequenz mit einem Reziprokzähler messen will, z.B. mit einer 100 MHz-Zeitbasis. Das gelingt auch, aber man hat am Anfang und am Ende der Eingangsperiode jeweils 0 bis 9.999nsec Fehler. Beim normalen Reziprokzähler ignoriert man das einfach. Beim Nonius-Verfahren braucht man einen time-stretcher, der 0-9.999 nsec auf 0-9.999 usec vergrößert. Man kann z.B. einen Kondensator mit viel Strom aufladen und nur mit 1/1000 entladen. Die Entladezeit kann man wieder mit 100 MHz auszählen und hat den Faktor 1000 an Auflösung gewonnen. Beim Generieren des Nonius-Signals kann man natürlich viel kapputtmachen, vor allem um die 0 nSekunden herum. Mit etwas Pipelining wird das einfacher, wenn man sich etwa 2 100MHz-Clocks Vorlauf gönnt und 20-29.999 nsec um den Faktor 1000 aufbläht. Dann muss sich der Stretcher nicht mehr mit einem unendlichn Tastverhältnis abmühen. Statt des Time-Stretchers kann man auch einen Kondensator in 20-29.999 nsec aufladen und dann mit einem 100MSPS 16 bit Flash-ADC auslesen und nach Gebrauch zurücksetzen. Damit gelingt eine deutlich bessere Mess-Rate. Denkbar sind auch Spielchen mit einer 100 und einer 110-MHz Referenz. Das ist dann wirklich wie bei der Schieblehre. Dort sind auch keine Striche näher als 1 mm, aber man kann auf 1/10mm messen. Gruß, Gerhard
:
Bearbeitet durch User
[quote] reziproken Frequenzzähler im FPGA auf einfache Art realisieren könnte [/quote] Bei einem Frequenzzähler misst man i.d.R. die Anzahl der Schwingungen in einem festen Zeitintervall. Will man auf einfache Weise den Kehrwert haben, dann muss man es umgekehrt machen. Z.B. die Zeit für eine Schwingung oder für eine feste Anzahl von Schwingungen messen.
m.n. schrieb: > Gerhard H. schrieb: >> Interessant ist auf jeden Fall der Stanford SR-620. >> 12 digits bei 1 sec "Torzeit". > > Wo steht das genau? > Im Datenblatt steht: 25 ps single-shot time resolution 1.3 GHz frequency range 11-digit frequency resolution (1 s) Und der darin verwendete analoge TDC ist für ein FPGA völlig ungeignet.
@Gerhard H. (ghf) Wirf nicht alle Begriffe durcheinander ... Der HP arbeitet mit dem Nonius Der SR 620 hat einen Time-to-voltage converter der dann mit einem ADC digitalisiert wird. Hier sind so ziemlich alle Varianten erklärt. http://rubiola.org/pdf-slides/2008T-femto-counters.pdf
Gerd K. schrieb: > [quote] > reziproken Frequenzzähler im FPGA auf einfache Art realisieren könnte > [/quote] > > Bei einem Frequenzzähler misst man i.d.R. die Anzahl der Schwingungen in > einem festen Zeitintervall. > > Will man auf einfache Weise den Kehrwert haben, dann muss man es > umgekehrt machen. > > Z.B. die Zeit für eine Schwingung oder für eine feste Anzahl von > Schwingungen messen. Und was machst du wenn du eine Zeit gemessen hast aber eine Frequenz Anzeigen willst ?
Hans-Georg L. schrieb: > Gerd K. schrieb: >> [quote] >> reziproken Frequenzzähler im FPGA auf einfache Art realisieren könnte >> [/quote] >> >> Bei einem Frequenzzähler misst man i.d.R. die Anzahl der Schwingungen in >> einem festen Zeitintervall. >> >> Will man auf einfache Weise den Kehrwert haben, dann muss man es >> umgekehrt machen. >> >> Z.B. die Zeit für eine Schwingung oder für eine feste Anzahl von >> Schwingungen messen. > > Und was machst du wenn du eine Zeit gemessen hast aber eine Frequenz > Anzeigen willst ? Dann schreib ich neben die Anzeige: 1/f oder f^-1
:
Bearbeitet durch User
Hans-Georg L. (h-g-l) >Hier sind so ziemlich alle Varianten erklärt. >http://rubiola.org/pdf-slides/2008T-femto-counters.pdf Ein sehr gutes Dokument. Mir gefällt, dass die Folien handgeschrieben sind, ich glaube, damit bekommt man immer mehr Informationen in die Folien als per Maus-Powerpoint. Die entscheidende Schwierigkeit bei dem Verfahren scheint mir die Detektion der Flanken-Koinzidenz zu sein. Wobei: Vielleicht wäre genau da der Vorteil eines FPGAs ...
Georg schrieb: > Hans-Georg L. (h-g-l) >>Hier sind so ziemlich alle Varianten erklärt. >>http://rubiola.org/pdf-slides/2008T-femto-counters.pdf > > Ein sehr gutes Dokument. Mir gefällt, dass die Folien handgeschrieben > sind, ich glaube, damit bekommt man immer mehr Informationen in die > Folien als per Maus-Powerpoint. > > Die entscheidende Schwierigkeit bei dem Verfahren scheint mir die > Detektion der Flanken-Koinzidenz zu sein. Und die Stabilität der Start Stop Oszillators. Mit der heutigen Technik kann man Start-Stop Oszillatoren im GHz Bereich bauen und bekommt so eine ps Auflösung auch ohne Nonius. Beispiel TDC7200 mit einem selbst kalibrierenden Start-Stop Oszillator und 55ps Auflösung. Schau mal auf http://www.mino-elektronik.de/ da gibt es einen Zähler mit diesem IC. > Wobei: Vielleicht wäre genau da der Vorteil eines FPGAs ... In einem FPGA wendet man andere Verfahren an. Phasenverschobene Takte oder delay der Carry-Logik, so kommt man auch in den ps Bereich.
Georg schrieb: > Mich würde die Frage interessieren, wie man einen reziproken > Frequenzzähler im FPGA auf einfache Art realisieren könnte. Es soll > dabei aber auf die Verwendung eines CPU-Kerns für die Division > verzichtet werden. Gar nicht. Und zwar aus Prinzip. Du hast IMMER einen Quotienten Ergebnis = Referenzfrequenz * (Zählrate / Referenzrate); und während man beim Geradeauszähler die Referenzrate so festlegen kann, daß man die Division durch schieres Setzen eines Kommas erledigen kann, ist diese beim 'reziproken' Zähler ebenso variabel wie die Zählrate. Ergo ist eine Division grundsätzlich erforderlich - und das dafür am ehesten geeignete Mittel ist eben ein µC, den man notfalls auch in ein FPGA integrieren kann. W.S.
W.S. schrieb: > Gar nicht. Und zwar aus Prinzip. Du hast IMMER einen Quotienten > > Ergebnis = Referenzfrequenz * (Zählrate / Referenzrate); Falls die Referenzrate fix ist, kann man die Division allerdings als Multiplikation mit einer Konstanten und anschliessendem Bitshift realisieren.
W.S. schrieb >Georg schrieb: >> Mich würde die Frage interessieren, wie man einen reziproken >> Frequenzzähler im FPGA auf einfache Art realisieren könnte. Es soll >> dabei aber auf die Verwendung eines CPU-Kerns für die Division >> verzichtet werden. >Gar nicht. Und zwar aus Prinzip. Du hast IMMER einen Quotienten Es gibt Sensor-Chips, die nach dem reziproken Frequenzzählerverfahren arbeiten und Quotienten lassen sich auch ohne CPU berechnen. Insofern liegst du erst mal falsch. Tobias B. >Falls die Referenzrate fix ist, kann man die Division allerdings als >Multiplikation mit einer Konstanten und anschliessendem Bitshift >realisieren. Die Referenzfrequenz der Chips kann man extern zuführen. Die Frage ist, lässt sich die Rechnung als minimalistische Logikschaltung realisieren.
chris_ schrieb: > Die Referenzfrequenz der Chips kann man extern zuführen. Die Frage ist, > lässt sich die Rechnung als minimalistische Logikschaltung realisieren Wenn man fixe Frequenzen hat kann man die Multiplikatoren im RAM ablegen. Und fuer die Multiplikation nimmt man einen DSP Slice, kein Grund das in Logik zu machen. Und falls man unbedingt will: Es laesst sich definitiv realisieren, die Frage ist nur wie schnell man das getaktet bekommt.
Tobias B. schrieb: > Wenn man fixe Frequenzen hat kann man die Multiplikatoren im RAM > ablegen. Wie naiv ist das denn? Wenn alles konstant ist, kommt man auch ganz ohne Elektronik aus. Man schreibt auf ein Blatt Papier "0815" und hat das "Ergebnis" damit direkt vor den Augen. Die Frequenz eines Signals ergibt sich aus Ergeinisse/Zeit. Braucht man etwas höhere Auflösung bei der Messung, wir man schnell sehen, daß womöglich die Anzahl der Ereignise nicht aber die dazugehörige Zeit konstant sind. Man kommt also um die "böse" Division nicht herum. > die Frage ist nur wie schnell man > das getaktet bekommt. Die Antwort: schnell genug.
Ich versuche immer noch aus Lothars VHDL-Text herauszufinden, wie schnell die Division ist. Die Taktfrequenz im Verhältnis zu einer kompletten Division ist aus dem "Oszillogramm" nicht zu ersehen. Für ein 32 Bit Ergebnis wären laut "1 Taktzyklus pro Ergebnisbit" 32 Takte nötig (oder gilt das für Quotient und Remainder nacheinander?). Dauert jede Division gleich lange? Die Ablaufsteuerung wartet jedenfalls auf den nächsten Start-Takt, also gibt es Pausen dazwischen. Ich nehme an, dass da ein Pipelining abläuft, also das erste Ergebnis länger dauert als die nächsten. Das kann ein Mikrocontroller eben nicht, das ist der Vorteil eines FPGA.
Christoph db1uq K. schrieb: > Das kann ein Mikrocontroller eben nicht, > das ist der Vorteil eines FPGA. Damit sich diese Gerüchte erst garnicht verbreiten: ein STM32H730 (Cortex M7) braucht für eine 64 Bit Fließkommadivision etwa 60 ns. Selbst ohne FPU-Unterstützung bleibt die Rechenzeit unter 1 µs. FPGAs sind gut für kompakte Logik (Zähler, Synchronisierung, Zeitinterpolator) aber Rechnen ist nicht ihre Stärke.
Oha, damit kann man viele Spatzen erschießen. https://www.rutronik24.com/search-result/qs:stm32h730/reset:0 und das für nur 4,52 € https://www.st.com/en/microcontrollers-microprocessors/stm32h730vb.html Wie schon gesagt, das Auge muss die Frequenzanzeige noch verfolgen können, sooo schnell muss die Division nicht gehen.
Christoph db1uq K. schrieb: > Wie schon gesagt, das Auge muss die Frequenzanzeige noch verfolgen > können, sooo schnell muss die Division nicht gehen. Weit gefehlt! Gehe hier (http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp_f730) etwas weiter nach unten und sieh Dir "Fmeter_H750_V2.zip" an. Gut, es sind im Wesentlichen Multiplikationen und nur ein paar Divisionen. Da werden ab 1 MHz Eingangsfrequenz pro Sekunde 1 000 000 Intervalle gemessen und bewertet. Das lastet den µC zu < 50% aus. Nun, Du brauchst es nicht. Aber wer drei weitere Stellen Auflösung bei der Messung haben möchte, wird nicht darauf verzichten wollen. Christoph db1uq K. schrieb: > https://www.rutronik24.com/search-result/qs:stm32h730/reset:0 > und das für nur 4,52 € Sag ich doch ;-)
ja für solche Erweiterungen ist das gut. HP hat mal einen "Frequency domain analyzer" gebaut, im Prinzip ein schneller Frequenzzähler, der Statistik über die einzelnen Messungen als Verteilungskurve darstellte. Damit lässt sich ein Oszillator-Einschwingverhalten (oder vielleicht auch seine Allen-Varianz) beurteilen. https://www.keysight.com/en/pd-1000001397%3Aepsg%3Apro-pn-53310A/modulation-domain-analyzer?cc=DE&lc=ger "Product Status: Obsolete"
Tobias B. schrieb: > Falls die Referenzrate fix ist, kann man die Division allerdings als > Multiplikation mit einer Konstanten und anschliessendem Bitshift > realisieren. Oh mann, .... Offenbar verstehen die meisten Schreiber in diesem Thema nicht, was ein sogenannter Reziprokzähler eigentlich ist. Also: Zum Anzeigen der Frequenz eines Eingangssignals muß man dieses mit einem Referenzsignal vergleichen. Das macht man am besten mit 2 Zählern, einer zählt die Perioden des Inputsignals, der andere die Perioden des Referenzsignals. Soweit klar? Natürlich kann man die Zähler nicht ewig laufen lassen, OHNE wenigstens gelegentlich mal die Zählerstände nachzuschauen und daraus eine Anzeige zu formulieren. Bei klassischen Zählern setzt man nach dem Auslesen die Zähler zurück, so daß beide wieder ab 0 loszählen. Bei sogenannten Zeitstempel-Zählern läßt man sie einfach durchlaufen und merkt sich nur die Zählerstände, um sie beim nächsten Mal abzuziehen. Im Prinzip läuft das auf's Gleiche hinaus, nämlich daß seit dem letzten Nachschauen der Inputzähler N Perioden des Inputsignals gezählt hat und der Referenzzähler R Perioden des Referenzsignals gezählt hat. Das führt dann immerzu bei ALLEN Zählervarianten auf: Ergebnis = Referenzfrequenz * (N / R); Der einzige Unterschied zwischen dem klassischen Geradeauszähler und dem Reziprokzähler besteht darin, daß beim Klassischen R eine echte Ganzzahl ohne Rest ist und beim Reziproken ist N eine Ganzzahl ohne Rest. Deshalb erhält man beim Reziproken auch eine gleichbleibende Auflösung unabhängig von N. Diese Auflösung hängt NUR von der Größe von R ab, genauer von: (Referenzfrequenz / R) versus (Referenzfrequenz / (R+1)) denn R enthält den Rest an Zeit bis zur nächsten Flanke von N eben NICHT und deshalb ist R mit einer Unsicherheit von 1 behaftet. Mit anderen Worten: der Reziprokzähler ist so aufgebaut, daß das Eingangssignal die Torzeit bestimmt, also die Zeitdifferenz zwischen dem aktuellen Nachschauen und dem vorherigen Nachschauen. Deshalb sind beide Stücke N und R in der ersten Formel KEINE Konstanten, sondern es sind beides Variablen. Zur Frequenzanzeige braucht es also eine Division und eine Multiplikation gemäß obiger Formel. Natürlich kann man prinzipiell diese Berechnungen auch in Hardware tun, schließlich erfolgt das bei einem Cortex M4F ja auch in Hardware. Aber einfacher hat man es mit einem µC. Das muß kein externer 8051 sein, es reicht dafür auch ein Core, den man in ein FPGA implementieren kann. Der Grund, weswegen es mit einem Controller einfacher geht ist, daß dieser das matehmatische Problem in sequentiell abzuarbeitende sehr viel einfachere Operationen aufzulösen gestattet. Die nötige Zeit hat man ja, denn es müssen ja wenigstens einige Perioden des Referenzsignales in R zusammenkommen. W.S.
W.S. schrieb: > Oh mann, .... > > Offenbar verstehen die meisten Schreiber in diesem Thema nicht, was ein > sogenannter Reziprokzähler eigentlich ist. Ich hab mich einfach nur auf die angegeben Formel bezogen: W.S. schrieb: > Ergebnis = Referenzfrequenz * (Zählrate / Referenzrate); Wenn ich sagen wir als Referenzfrequenz 1 MHz habe, dann zaehle ich den Referenzzaehler z.B. bis 1 Mio. und das Ergebnis entspricht der Zaehlrate. Und das kann ich beliebig fortfuehren, kann ja die Referenzrate beliebig fix machen und dann kann ich die Division immer in eine Multiplikation mit einer Konstanten + Bitshift ueberfuehren. Wenn ich das mit dem Reziprokzaehler richtig verstanden habe, dann will man hier auch nicht die Frequenz messen sondenr die Periodendauer. Und fuer dessen Kehrwert brauche ich die Divion, da gehts nicht anderst. Aber wenn die obige Formel der gewollte mathematische Zusammnhang ist, dann kann man das ganz ohne Division hinbekommen.
Tobias B. schrieb:
Wenn ich sagen wir als Referenzfrequenz 1 MHz habe, dann zaehle ich den
Referenzzaehler z.B. bis 1 Mio. und das Ergebnis entspricht der
Zaehlrate. Und das kann ich beliebig fortfuehren, kann ja die
Referenzrate beliebig fix machen und dann kann ich die Division immer in
eine Multiplikation mit einer Konstanten + Bitshift ueberfuehren.
Die Messzeit (Start/Stop) bzw. die Timestamps werden mit der Flanke der
Eingangsfrequenz synchronisiert und treffen nicht immer mit einer Flanke
des Referenzsignales zusammen. Deshalb hast du eine Unsicherheit von +/-
1er Periode Ref.
Hans-Georg L. schrieb: > Die Messzeit (Start/Stop) bzw. die Timestamps werden mit der Flanke der > Eingangsfrequenz synchronisiert und treffen nicht immer mit einer Flanke > des Referenzsignales zusammen. Deshalb hast du eine Unsicherheit von +/- > 1er Periode Ref. Ja das ist alles klar. Versteh aber den Zusamenhang zu meinem Post nicht. ;-) Nochmal: Ergebnis = Referenzfrequenz * (Zählrate / Referenzrate); Wenn ich die Referenzrate konstant lassen kann, dann brauch ich keine Division. Ob man sie konstant lassen kann steht auf einem anderen Blatt, prinzipiell: Je hoeher die Frequenz, desto geringer der Fehler. Die +/- spielt dann kaum noch eine Rolle. Ob das tolerierbar ist oder nicht, muss man die Anwendung Entscheidung. Fehlerrechnung ist zum Glueck ziemlich easy erledigt. :-)
Ich habe mal eine Suche angeworfen ... Meinst du das hier "Division by Invariant Integers using Multiplication" : https://gmplib.org/~tege/divcnst-pldi94.pdf Das ist Software und wie bringst du das ganze in ein FPGA in Hardware mit VHDL ohne einen Soft Prozessor ?.
Ich bin jetzt mal so frei und gehe das Paper nicht durch. Vll ein kleines Beispiel: Man moechte f(x) = x/10 haben, also eine Zahl durch die Konstante 10 teilen. Dann ist das identisch zu einer Multiplikation mit 0.1, also f(x) = x * 0.1. Soweit so trivial. Und die Multiplikation mit 0.1 realisiert man jetzt durch Multiplikation mit einer natuerlichen Zahl c und anschliessendem Bitshift (teilen durch 2^n). Damit wird: f(x) = (x*c)/2^n. c und n haengen nur noch von der benoetigten Genauigkeit ab. Nehmen wir mal ein Beispiel: f(x) = (x*102) / 2^10 102 / 1024 = 0.0996, also schon ziemlich nah an 0.1, in dem Fall 4 Promille Abweichung. Ich hoffe das ist soweit verstaendlich und wir reden nicht aneinander vorbei. Funktioniert natuerlich nur wenn man wirklich durch eine Konstante teilen (in diesem Falle 10) muss. Wenn der Divisor auch variable ist, dann liesse sich c und n wieder nur durch Division bestimmen, das System bricht also zusammen. Daher der Einwand, wenn man ein Satz fixer Werte hat, dann kann mn diese auch in einer LUT speichern. Aber ganz allgemein zum Frequenzzaehler noch: Das Divisionsproblem hat man natuerlich immer bei kleinen Frequenzen. Wenn ich hohe Frequenzen hoch aufgeloest messen moechte, dann erstelle ich mein Start/Stop Signal aus dem Referenzzaehler und zaehle die eingehenden Pulse innerhalb des Zeitfensters. Wenn ich das Zeitfenster geschickt waehle, z.B. genau 1s gross mache, dann muss ich nichtmal Bitshiften. Sobald aber geringe Frequenzen im Spiel sind, wird das Start/Stop Signal aus dem Eingangssignal erzeugt und man zaehlt das Referenzsignal zwischen 2 Eingangspulsen. Hier geht es ohne Division nicht mehr. Und genau dieser Fall ist das was ich unter dem reziproken Zaehler verstehe. Daher verstehe ich schon die Einwaende, das man immer Dividieren muss. Da sage ich nichts dagegen. Jedoch kann man vll die Referenzfrequenz entsprechend verschieben, so dass man aus dem Fall wo eine Division zwingend noetigt ist raus kommt. Alles eine Sache der Abwegung und je nachdem wie hoch die Frequenzen sind, kommt man da auch raus aus dem technisch machbaren.
:
Bearbeitet durch User
Tobias B. schrieb: > Aber ganz allgemein zum Frequenzzaehler noch: > > Das Divisionsproblem hat man natuerlich immer bei kleinen Frequenzen. Belassen wir es bei dieser Aussage und ignorieren den Rest.
m.n. schrieb: > Tobias B. schrieb: >> Aber ganz allgemein zum Frequenzzaehler noch: >> >> Das Divisionsproblem hat man natuerlich immer bei kleinen Frequenzen. > > Belassen wir es bei dieser Aussage und ignorieren den Rest. Keine Ahnung was dein Problem ist. Bei allen Zeit / Frequenzmessungen hast du immer das gleiche Prinzip: Du hast ein definiertes Zeitfenster und innerhalb dieses muessen Pulse gezaehlt werden. Je mehr Pulse in dem Fenster liegen, desto geringer ist dein statistischer Messfehler. Zur gesamten Messgenauigkeit kommt entsprechend noch der Mesfehler des Zeitfenster hinzu. Und abhaengig von deinem zu messenden Signal zaehlt man eben die Referenzpulse und generiert das Zeitfenster aus dem Eingangssignal (wenn Messsignal Frequenz klein gegenueber Referenzfrequenz) oder eben genau umgekehrt (wenn Messsignal Frequenz gross gegenueber Referenzfrequenz). In der ersten Variante musst du zwingend dividieren in der zweiten kann man das vermeiden. Mehr Wissenschaft steckt da nicht dahinter.
Tobias B. schrieb: > Bei allen Zeit / Frequenzmessungen > hast du immer das gleiche Prinzip: Du hast ein definiertes Zeitfenster > und innerhalb dieses muessen Pulse gezaehlt werden. Einen ICM7216 habe ich hier; wie der arbeitet ist bekannt. Es ist ein "vintage" Zähler aus vergangener Zeit. Meine letzte Verwendung dafür war ein Impulszähler, um die Umdrehungen einer Pyramide mit Engeln zu zählen. Man muß ja wissen, wie lange die Lager noch durchhalten ;-) Willst Du ernsthaft in einen Zähler zwei verschiedene Messverfahren einbauen, eines mit Torzeit und eines reziprok? Dann ist die "böse" Division ja doch wieder dabei und man muß noch je nach Messwert jedesmal umschalten. > Das Divisionsproblem hat man natuerlich immer bei kleinen Frequenzen. Wo enden bei Dir denn kleine Frequenzen? Sind es 50 Hz, 32,768 kHz, 10 MHz? Frag doch mal Gerhard H. (ghf) oder Hans-Georg L. (h-g-l), ob sie bei der Messung von 10 MHz mit sieben Stellen etwas anfangen können. Wer will denn eine Quarzuhr mit 32,768 kHz abgleichen und immer 30 Sekunden warten, um das nächste Ergebnis mit 1 ppm Auflösung ablesen zu können? Gut, manche werden diese Probleme nicht haben und die "Arduino-App" als Wohltat empfinden (s.o.) Beitrag "Re: FPGA reziproker Frequenzzähler" Eine zeitgemäße Lösung für den hiesigen Betreff ist das nicht.
>ICM7216
auch der konnte Periodendauern messen. Mit dem 10 MHz Takt bekommt man
für 50 Hz jedenfalls mehr Stellen als im Frequenzzählbetrieb. Die
anschließende Division kann ja auch ein Taschenrechner erledigen.
:
Bearbeitet durch User
m.n. schrieb: > Willst Du ernsthaft in einen Zähler zwei verschiedene Messverfahren > einbauen, eines mit Torzeit und eines reziprok? Dann ist die "böse" > Division ja doch wieder dabei und man muß noch je nach Messwert jedesmal > umschalten. Wieso nicht, wo ist das Problem? Viele Messgeraete schalten ab einem gewissen Arbeitsbereich um, das ist nichts ungewoehnliches. m.n. schrieb: >> Das Divisionsproblem hat man natuerlich immer bei kleinen Frequenzen. > > Wo enden bei Dir denn kleine Frequenzen? > Sind es 50 Hz, 32,768 kHz, 10 MHz? Hab ich doch geschrieben. Klein ist relativ zur Referenzfrequenz. Je groesser der Unterschied zwischen Messfrequenz und Referenzfrequenz ist, desto genauer kannst du messen. Am besten du machst zu Uebungszwecken einfach mal eine einfache Fehlerrechnung und schaust dir an wie der Fehler von der Eingangsfrequenz abhaengt. Die Kurzen kannst dann abhaengig von der Referenzfrequenz parametrieren. Und wenn du das jetzt noch fuer beide Konzepte kombinierst, kannst die Graphen uebereinander legen und der Schnittpunkt zeigt den sinnvollen Uebergang beider Methoden. Alles keine Raketen Wissenschaft. :-) Kleiner Exkurs: Idealerweise hast du gleichzeitig noch eine super genaue und stabile Referenzfrequenz. Schau mal die Definition der Sekunde, Arbeitsweise von Atomuhren, etc. an. Da lassen sich parallelen erkennen, das Konzept ist immer das gleiche. ;-)
@Tobias B. Es zweifelt doch keiner daran, das man so rechnen kann. Aber den Nutzen in einem Frequenzzähler finde ich fraglich, wie alle mir bekannten Hersteller auch.
Hans-Georg L. schrieb: > @Tobias B. > Es zweifelt doch keiner daran, das man so rechnen kann. Aber den Nutzen > in einem Frequenzzähler finde ich fraglich, wie alle mir bekannten > Hersteller auch. Den Nutzen von was?
Tobias B. schrieb: > Hans-Georg L. schrieb: >> @Tobias B. >> Es zweifelt doch keiner daran, das man so rechnen kann. Aber den Nutzen >> in einem Frequenzzähler finde ich fraglich, wie alle mir bekannten >> Hersteller auch. > > Den Nutzen von was? Den Nutzen deiner Rechenart in einem Frequenzzähler. Kennst du einen Hersteller von Frequenzzählern der das benutzt ?
Welche Rechenart? Das Multiplizieren mit einer Konstante und anschliessendem Bitshift? Falls ja, das ist gaengig Praxis (gerade in der FPGA Welt in der man haeufig Multiplizieren quasi geschenkt bekommt) wenn man durch eine Konstante dividieren moechte. Welcher Bereich, ob Frequenzzaehler oder was anderes spielt da keine Rolle.
Hans-Georg L. schrieb: > Wenn du "nur" von FPGA mit DSP redest und die Referenzfrequenz 2^n > ist > gebe ich dir recht. Nein, du kannst mit dieser Methode immer durch eine Konstante teilen. Und ja, die DSPs hab ich als gegeben vorrausgesetzt, deshalb auch "gerade in der FPGA Welt in der man **haeufig** Multiplizieren quasi geschenkt bekommt". Aber wie bereits geschrieben: Bei dem Reziproken Ansatz funktioniert das alles nicht mehr, da man hier nicht durch eine Konstante dividieren kann. Ich habe lediglich einwerfen wollen, dass es Faelle gibt in denen man nicht zwingend zu Fuss dividieren muss und zwar immer dann, wenn der Divisor eine Konstante ist (alles unabhaengig vom Thema "Frequenzzaehler"). Dass das einen derartigen Trigger ausloest haette ich allerdings wissen sollen, ist irgendwie nichts ungewoehnliches hier. Den Schuh muss ich mir wohl doer uebel anziehen. ;-)
Tobias B. schrieb: > Wenn ich sagen wir als Referenzfrequenz 1 MHz habe, dann zaehle ich den > Referenzzaehler z.B. bis 1 Mio. und das Ergebnis entspricht der > Zaehlrate. Das ist der klassische Geradeauszähler. Dort ist R eine glatte Integerzahl und N ist mit einer Unsicherheit von 1 behaftet. Am besten, du liest dir meinen obigen Beitrag noch einmal durch und versuchst, ihn tatsächlich zu verstehen. Und ja, wenn man schon ein CPLD oder FPGA benutzt, dann ist die Umschaltung zwischen Reziprokzähler und Geradeauszähler gar kein Problem. W.S.
Hallo zusammen, ich verstehe diese heftige Diskussion nicht, die vom eigentlichen Problem weit weg führt. Die Division in VHDL ist doch kein Problem! Und da brauche ich auch keinen Softcore dazu. Wie ich oben schon gepostet hatte, so kann man das machen. Die Division, in der Umsetzung, braucht pro bit (vom Eingangsvektor) einen Takt. Macht bei 32bit Variablen 32 Takte. Das ist doch in einem Messgerät kein Problem, wenn die Division nur einmal durchgeführt wird pro Update auf dem Display. Ich kann das doch takten ohne Ende. Bei mir läuft das mit 160MHz. Und da ist noch nicht Ende. Macht bei 32bit 0,2µs/Division. Ich denke die kann man sich erlauben und braucht keine Umwege machen mit dem Shiften. P.S.: Das habe ich auch schon gemacht. Funktioniert prima. Ein Stichwort für die Suche: Kettenbruch Damit kann man den Multiplikator bestimmen, wenn die Bitweite zum schieben bekannt ist. Alles recht simpel und ist sehr schnell. Aber das macht keinen Sinn, wenn ich oben lese "eine DSP wird vorausgesetzt". Multiplizieren und shiften macht Sinn, wenn ich einen 8biter habe. (Vorausgesetzt wir reden von Messgeräten, bei dem die Anzeige von Menschen gelesen werden soll). Alles andere ist doch eh rasend schnell. Ich hätte da einen Vorschlag: Lasst uns nicht über Divisionen streiten, sondern lasst uns eine sinnvolle Architektur für das oben beschriebene Messgerät machen. Da hätten alle viel mehr davon. Die meisten hier sind sehr erfahren, da wird doch das Ergebnis super sein! Was meint ihr? Grüße, Jens
>Lasst uns nicht über Divisionen streiten, sondern lasst uns eine >sinnvolle Architektur für das oben beschriebene Messgerät machen. Da >hätten alle viel mehr davon. Mir wäre eine gute Bedienbarkeit wichtig. Ablesbarkeit ist auch ein Thema, deshalb fände ich Siebensegmentanzeigen ganz gut. Die Frage ist, ob man 8 Stellen an ein FPGA hängen kann und das den Strom liefert.
Jens W. schrieb: > Ich hätte da einen Vorschlag: > Lasst uns nicht über Divisionen streiten, sondern lasst uns eine > sinnvolle Architektur für das oben beschriebene Messgerät machen. Da > hätten alle viel mehr davon. > Die meisten hier sind sehr erfahren, da wird doch das Ergebnis super > sein! > Was meint ihr? Das ist natuerlich stark. Sich darauf besinnen dass sich alle lieb haben sollen, aber selbst mit Jens W. schrieb: > Aber das macht keinen Sinn, wenn ich oben lese "eine DSP wird > vorausgesetzt". > Multiplizieren und shiften macht Sinn, wenn ich einen 8biter habe. > (Vorausgesetzt wir reden von Messgeräten, bei dem die Anzeige von > Menschen gelesen werden soll). Alles andere ist doch eh rasend schnell. erstmal diskreditieren. Es ist ein grosser Unterschied ob etwas keinen Sinn macht oder man keinen Sinn darin sieht. ;-) Es gibt mehr als genug Anwendungen davon, z.B. wenn du die Division pipelinen moechtest oder dein Design auf Einfachheit runterbrechen moechtest. Das ist auch der Grund warum ich das mal in die Diskussion eingeworfen habe, ganz einfach weil man mit diesem Design Pattern so unfassbar einfach dividieren kann. So einfach, dass das jeder noch so am Anfang stehende Anfaenger es verstehen kann. Wo es allerdings keinen Sinn macht, ist wenn man durch etwas Teilen moechte das nicht konstant ist (und damit ist es leider fuer die Anwendung gestorben). Trotzdem darf man doch wenn es ums Thema FPGA und dividieren geht vll. mal was einwerfen was in der Diskussion vll. ueber den Tellerrand hinaus geht? Zugegeben ein Forum mit einer Baumstruktur ala Heise oder dem Usenet waere da besser geeignet. Aber wo ich dir zu 100% Recht gebe: Es ist unglaublich was dieser Beitrag mit dem Multiplizieren und Shiften fuer ein Fass aufgemacht hat. Es ist einfach eines von vielen Design Patterns um eben eine Division zu realisieren. Und es ist doch gut einen moeglichst grossen Pool mit verschiedenen Patterns zu haben, man pickt sich raus was man braucht. Scheitern tut es in dem Fall an dem reziproken Teil, weil man eben nicht durch eine Konstante teilen kann. Es ist einfach schockierend wie die Leute immer wieder angetriggert werden von so einem Kaese, als haette man sie persoenlich beleidigt oder ins Gesicht geschlagen. Und was ich fast noch erschreckender finde ist, dass dieses Design Pattern so unbekannt sein soll, das ich das fast nicht glauben mag. Meine Meinung nach haette die Diskussion eher so verlaufen sollen: - Jemand postet eine Formel mit Division. - Design Pattern zur Division bei konstantem Divisor wird erwaehnt. - Es folgt der Einwand, dass es in diesem Fall nicht funktioniert, da eben beim reziproken Zaehler kein konstanter Divisor vorliegt. - Subdiskussion beendet.
:
Bearbeitet durch User
Das FPGA muss nicht den Strom liefern, ein '574, '573 '244, '245 oder änlich kann es besser. Mann kann auch 1 Segment pro Zyklus leuchten lassen, muss man nicht alle 7 Segmenten einer Ziffer gleichzeitig treiben. Verilog für das hätte ich verfügbar :) (15 Ziffern à je 7 Segmenten). Ich hab es für ein MachXO2 realisiert und funktioniert ganz gut, die können bis 24 mA pro I/O. Wahrscheinlich nur 1 IO pro Bank, aber mehr braucht man nicht (2 I/Os).
Ale schrieb: > Das FPGA muss nicht den Strom liefern, ein '574, '573 '244, '245 oder > änlich kann es besser. Davon bin ich nicht überzeugt. Ich hatte mal einen Busfight zwischen einem mittlerweile antikem XC3020 und einem TI 74AS244. Der XC3020 hat das sehr überzeugend gewonnen. Man konnte kaum sehen dass der AS244 an der Sache beteiligt war, von der Wärmeentwicklung abgesehen. Viel Strom brauche heutige LEDs sowieso nicht mehr. Die kleinen LEDs an meinen BeagleBoneBlacks sind so hell, dass ich als erstes etwas drüberklebe. Ist nicht auszuhalten. > Mann kann auch 1 Segment pro Zyklus leuchten lassen, muss man nicht alle > 7 Segmenten einer Ziffer gleichzeitig treiben. Verilog für das hätte ich > verfügbar :) (15 Ziffern à je 7 Segmenten). Ich hab es für ein MachXO2 > realisiert und funktioniert ganz gut, die können bis 24 mA pro I/O. > Wahrscheinlich nur 1 IO pro Bank, aber mehr braucht man nicht (2 I/Os). Ich habe im Netz übrinx die Extrabreit-Version des SR620 gefunden.
:
Bearbeitet durch User
Gerhard H. schrieb: > Ich habe im Netz übrinx die Extrabreit-Version des SR620 gefunden. Wir haben hier im Labor einen SR620 mit 16 7-Segment anzeigen. Dank eurer Diskussion hier weiss ich jetzt auch, dass ich den auch pfleglich behandeln sollte. Hatte nicht angenommen, dass der so ein Schätzchen ist. Danke dafür.
Ja, das muss so. Meiner hat die extra-gute Wenzel-Zeitbasis und war sogar frisch kalibriert als ich ihn gekauft habe. Und für PowerUp immer den Prescaler abschalten, sonst gibt's Error 34! Ist aber harmlos.
Jens W. schrieb: > Ich hätte da einen Vorschlag: > Lasst uns nicht über Divisionen streiten, sondern lasst uns eine > sinnvolle Architektur für das oben beschriebene Messgerät machen. Da > hätten alle viel mehr davon. Das sehe ich ganz genau so. Aber es ist ein gewisses Grundverständnis der Teilnehmer vonnöten, sonst wird das nix. Also: Vorgabe. Es soll ein Reziprokzähler sein. OK. Für den gewöhnlichen menschlicheg Gebrauch soll es gewiß auch sein, also sollten die Messungen erstmal so etwa zwischen 0.5 und 1 Sekunde dauern, damit man gut ablesen kann, es nicht flimmert und man auch nicht gelangweilt wird. Auch OK. Wieviele Stellen sollen es sein? Ich plädiere für 8 signifikante Stellen, das ist schon ein wenig anspruchsvoll, aber in der Benutzung auch nicht zu mickrig. Wo soll bittesehr die obere Funktionsgrenze sein? Mit einem kleinen CPLD (32er Coolrunner) kommt man auf bis zu etwa 600 MHz, das ist bei FPGAs deutlich zu hoch - schließlich haben FPGAs keine langen AND-Gatter, so daß kaskadiert werden muß - also setzen wir mal schlichte 200..300 MHz als Obergrenze an. Ist ja auch was, gelle? Zumindest für NF-Techniker. So, machen wir ein erstes Resümee: 200 MHz sehen so aus: 199'999'999 Hz Und das sind 9 Ziffern. OK, da die erste nur 0 oder 1 ist, lassen wir das mal so durchgehen. Bei etwa 1 Sekunde Meßzeit (realiter ein Tick mehr, um sowas wie den 1PPS messen zu können) sieht das Ergebnis so aus: 0.99999999 Hz Wir brauchen also ein Rechenwerk, was zwar nur 8 signifikante Stellen berechnen muß, aber diese liegen im Bereich von 0.00000001 bis 100000000. Die großen FPGA-Spezis sind hier gefragt, ob sie so etwas im FPGA mit vertretbarem Aufwand berechnen können oder ob da vielleicht doch irgend ein kleiner µC oder µC-Core mit einer passenden GK-Arithmetik die handlichere Lösung wäre. Zum Frontend und zur Ablaufsteuerung: Das ist die leichteste Übung: Man braucht zunächst ein D-FF, das vom Input-Signal getaktet wird. Von der Steuerung aus kann man an dessen Eingang ein Tor-Wunsch-Signal anlegen und es wird am Ausgang dieses D.FF ein zum Eingangssignal synchrones Torsignal daraus. Man braucht dann zwei für einen maximal 200'000'000 großen Zählerstand ausreichend große Zähler, schließlich sollte das Referenzsignal ja ebenfalls 200 MHz sein, um auf den für 8 Stellen nötigen Zählerstand im R-Register zu kommen. Diese Zähler können beide simple Ripplecounter sein. Das erleichtert die Konstruktion im FPGA ungemein. Die allererste Stufe der Zähler hat dann als Tor ein XOR in der Rückführung, womit die Torung aus dem o.g. D-FF erledigt wäre. Am Meßende muß man dann eben vor dem Auslesen ein paar Takte warten, damit sich beide Zähler ausgerippelt haben. Anschließend kann man dann beide Zähler auslesen und das Ergebnis berechnen. Zwischendurch sollte man dann auch schauen, ob das D-FF überhaupt den gewünschten Zustand hat, also ob nach dem Start die Torzeit überhaupt begonnen hat oder ob nix anliegt - und am Meßende, wann denn nun die abschaltende Flanke des Inputs endlich angetrödelt kam - oder auch nicht, da sind separate Zeitbegrenzungen jeweils vonnöten, um keinen Mist zu messen. So. Das war das Exposé für so einen reziproken Zählfrequenzmesser. W.S.
Ale schrieb: > Mann kann auch 1 Segment pro Zyklus leuchten lassen, muss man nicht alle > 7 Segmenten einer Ziffer gleichzeitig treiben. Da bin ich völlig gegensätzlicher Ansicht: Für ein Meßgerät, das sich gerade wie ein Frequenzmeßgerät mit einer hohen Bandbreite befaßt, sollte man tunlichst danach trachten, im Gerät so wenig wie möglich digitale Störsignale zu erzeugen. Von daher wären 8 simple TTL-Schieberegister direkt hinter den Anzeigen und ein einmaliges Hineintakten der Segmentbelegung am Meßende weitaus sinnvoller. Nur wenige Leitungen zwischen Frontplatte und Meß-LP, statischer Zustand der Anzeige während der Messungen und nur ein paar wirklich billige TTL-Chips. Jegliches Multiplexen macht hingegen mehr Aufwand und Störungen. W.S.
Christoph Z. schrieb: > Wir haben hier im Labor einen SR620 mit 16 7-Segment anzeigen. Dank > eurer Diskussion hier weiss ich jetzt auch, dass ich den auch pfleglich > behandeln sollte. Ja, feines Teil. Da hat man auch gleich noch einen Grund einen alten analogen Oszi aufzuheben, der als Anzeige für die Diagramme dient. Und vor der Messung mindestens eine halbe Stunde warmlaufen lassen (wie bei jedem empfindlichen Messgerät...) Duke
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.