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