Forum: FPGA, VHDL & Co. FPGA reziproker Frequenzzähler


von Georg (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Also spontan fallen mir ein:

- Statt einer Division eine LUT verwenden.
- Divions in Logik durchfuehren, fertige IPs gibts hierzu zuhauf

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Georg (Gast)


Angehängte Dateien:

Lesenswert?

>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.

von Hans-Georg L. (h-g-l)


Lesenswert?

Hier noch der Link zum Journal vom Juni 1974

http://hparchive.com/Journals/HPJ-1974-06.pdf

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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 Georg (Gast)


Lesenswert?

> 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.

von F. M. (foxmulder)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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?

von Georg (Gast)


Lesenswert?

>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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von C. A. Rotwang (Gast)


Lesenswert?

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/

von Alex (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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
von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

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).

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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
von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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
von Jens W. (jensw)


Lesenswert?

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

von Georg (Gast)


Angehängte Dateien:

Lesenswert?

>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?

von m.n. (Gast)


Lesenswert?

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.

von Georg (Gast)


Angehängte Dateien:

Lesenswert?

Für 7,10€ gäbe es noch ein Gowin GN1 FPGA-Board ... das Problem könnte 
dann vielleicht die Entwicklungsumgebung werden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Gerhard H. (ghf)


Lesenswert?

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

von Georg (Gast)


Lesenswert?

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/

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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"

von m.n. (Gast)


Lesenswert?

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?

von Gerhard H. (ghf)


Lesenswert?

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
von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

>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
von m.n. (Gast)


Lesenswert?

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.

von Gerhard H. (ghf)


Lesenswert?

Dass die letzte Stelle noch stimmt, das glaub' ich auch nicht.

: Bearbeitet durch User
von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Zu dem Nonius-Verfahren gibt es dieses Diagramm im Handbuch

von Georg (Gast)


Lesenswert?

Was ist der Unterschied zum Reziprokzähler?

von Gerhard H. (ghf)


Lesenswert?

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
von Gerd K. (8bit-opa)


Lesenswert?

[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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Angehängte Dateien:

Lesenswert?

@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

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?

von Gerd K. (8bit-opa)


Lesenswert?

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
von Georg (Gast)


Angehängte Dateien:

Lesenswert?

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 ...

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von chris_ (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 ;-)

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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"

von W.S. (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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. :-)

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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
von m.n. (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

>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
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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. ;-)

von Hans-Georg L. (h-g-l)


Lesenswert?

@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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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?

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

Wenn du "nur" von FPGA mit DSP redest und die Referenzfrequenz 2^n ist 
gebe ich dir recht.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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. ;-)

von W.S. (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von chris_ (Gast)


Lesenswert?

>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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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
von Ale (Gast)


Lesenswert?

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).

von Gerhard H. (ghf)


Angehängte Dateien:

Lesenswert?

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
von Christoph Z. (christophz)


Lesenswert?

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.

von Gerhard H. (ghf)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.