Announcement: there is an English version of this forum on Moin, ich probiere gerade mal ein paar Paper aus, die zum Thema High Resolution Timer in fpga sich auslassen. Z.B.: https://cds.cern.ch/record/1158663/files/p383.pdf https://cds.cern.ch/record/1158663/files/p383.pdf Allerdings hab ich keine Idee wie man so eine Schaltung dann umsetzt? Ich meine wie kann ich dann die ganz bestimmten resourcen auf dem fpga konfigurieren. Ich benutze VHDL und ISE14.6. Da kann ich zwar in "Design Goals and Strategies" ein xds Strategie File angeben :(. Muss man das dann tatsächlich per Hand über Map&Place machen? Wo kann ich das genau "constrainen"? Wie macht ihr das? gruß J
:
Bearbeitet durch User
Hallo, schau mal im Repositoty vom Cern nach, da kann man sich angucken, wie das umgesetzt wurde. Und ja, in dem Fall muss viel mit Placement Constraints gearbeitet werden. https://ohwr.org/explore/projects/ PS: Darüber hinaus schreiben die wirklich schönen Code ;) Viele Grüße Achim
Jonas B. schrieb: > Muss man das dann tatsächlich per Hand über Map&Place machen? Letztlich ist das genau so ein Gefrickel. Das Bild 5 zeigt dir, wie das zu verschalten ist. VHDL ist dafür viel zu abstrakt und die Toolchain hat eine ganz andere Verwengung für die CarryChain, als die, wofür sie in diesen TDC eingesetzt wird. Und da helfen auch keine Constraints weiter (ausser dem, dass der Optimizer die Finger von diesen manuell platzierten "Fine-TDC" Blöcken lassen soll).
Lothar M. schrieb: > Jonas B. schrieb: >> Muss man das dann tatsächlich per Hand über Map&Place machen? > Letztlich ist das genau so ein Gefrickel. Das Bild 5 zeigt dir, wie das > zu verschalten ist. > VHDL ist dafür viel zu abstrakt und die Toolchain hat eine ganz andere > Verwengung für die CarryChain, als die, wofür sie in diesen TDC > eingesetzt wird. Und da helfen auch keine Constraints weiter (ausser > dem, dass der Optimizer die Finger von diesen manuell platzierten > "Fine-TDC" Blöcken lassen soll). Ja ich sehe es ein, das macht absolut kein Spaß. Warum config Dateien binär Formate haben müssen, weiß auch niemand, kann man nicht mal abschauen. Joachim S. schrieb: > Hallo, > > schau mal im Repositoty vom Cern nach, da kann man sich angucken, wie > das umgesetzt wurde. Und ja, in dem Fall muss viel mit Placement > Constraints gearbeitet werden. > > https://ohwr.org/explore/projects/ > > PS: Darüber hinaus schreiben die wirklich schönen Code ;) > > Viele Grüße > > Achim ui...ja das sind feine Sachen :D white rabbit :D danke
Jonas B. schrieb: > https://cds.cern.ch/record/1158663/files/p383.pdf > https://cds.cern.ch/record/1158663/files/p383.pdf Hat jemand eine Ahnung, von WANN diese papers sind? Sollte das nicht eigentlich draufstehen? Oder ist das nicht üblich? So einen TDC haben wir mal in einem S3 gemacht, allerdings schon Mitte der 2000er. Das paper referenziert eine Publikation von 2008 - ist also sicher später. Schon komisch, was so alles an paper produziert wird. Alles doppelt und dreifach. Sicher gibt es ähnliche Veröffentlichungen aus Indien von letzer Woche.
>Hat jemand eine Ahnung, von WANN diese papers sind? >Sollte das nicht eigentlich draufstehen? Ich meine ca. 2006. Gruß J
Angehängte Dateien:
-
PubSearch.PNG
25 KB
Murkser schrieb: > Jonas B. schrieb: >> https://cds.cern.ch/record/1158663/files/p383.pdf >> https://cds.cern.ch/record/1158663/files/p383.pdf > > Hat jemand eine Ahnung, von WANN diese Papers sind? Einfach mal den Titel bei google eingeben und dann tröpfelt unten das Publikationsjahr raus. (siehe Anhang) Solche IEEE sachen scheinen prinzipiell kein datum zu tragen, wenn sie ausserhalb der IEEE-Schrift veröffentlicht werden. Dann muss man anderswie das 'Datum des Druckes' ermitteln.
>Solche IEEE sachen scheinen prinzipiell kein datum zu tragen, wenn sie >ausserhalb der IEEE-Schrift veröffentlicht werden. Ja, das kommt vermutlich vom Anspruch, dass die Ergebnisse wissenschaftlicher Forschung zeitlos gültig sein sollen. Mich ärgert das auch immer, weil die Technik sich so schnell ändert und Paper von 1960 eher nur noch wenig relevant sind.
Murkser schrieb: > Schon komisch, was so alles an paper produziert wird. Alles doppelt und > dreifach. Sicher gibt es ähnliche Veröffentlichungen aus Indien von > letzer Woche. Du hast das Paper gelesen? Da steht gleich am Anfang, dass es TDCs schon gibt und die verwendet werden. In dem Paper geht es drum eine noch bessere Zeitauflösung zu schaffen. Als Prior Art werden 100 ps genannt, da schafft dieses Paper ein besseres Ergebnis. Ich weiß auch nicht was das mit Indien zu tun haben soll, außer eine abfällige Bemerkung über Leute anderer Hautfarbe.
Es gibt viele papers zu TDC in FPGA aber fast alles nichts konkretes. Mir mit auch schon ein Verfahren mit 2 gegenläufigen Delay Lines begegnet, welches noch höhere Auflösung verspricht. Schau dir mal diese Seite an: https://cas.tudelft.nl/fpga_tdc/TDC_basic.html Im beiliegenden code siehst du wie man die Delay-Line generiert und direkt in vhdl plaziert.
Joachim S. schrieb: > Hallo, > > schau mal im Repositoty vom Cern nach, da kann man sich angucken, wie > das umgesetzt wurde. Und ja, in dem Fall muss viel mit Placement > Constraints gearbeitet werden. > > https://ohwr.org/explore/projects/ > > PS: Darüber hinaus schreiben die wirklich schönen Code ;) > > Viele Grüße > > Achim CERN schreibt schönen Code? Was habe ich verpasst? Schonmal in dem Kicad Code geschaut? Da kräuseln sich einem alle Nägel.
Dennis E. schrieb: > CERN schreibt schönen Code? Was habe ich verpasst? Schonmal in dem Kicad > Code geschaut? Da kräuseln sich einem alle Nägel. Zum Glueck wissen wenigstens die Wissenschaftler am CERN, dass ein Messpunkt noch keine statistische Signifikanz aufweisst. Erst recht nicht 5 sigma. ;-)
Einfach den Link kürzen https://cds.cern.ch/record/1158663 und man bekommt die Angaben: Proceedings der 2008 TWEPP. Steht nicht im pdf da es offenbar auseinander geschnitten wurde (und es ist keine IEEE Veranstaltung). Und zum Thema Neuheit: insbesondere Konferenz-Proceedings haben da nicht unbedingt den Anspruch. Man bekommt so aber etwas was referenzieren kann und es ist u.U. die einzige öffentliche Doku.
>Schau dir mal diese Seite an: >https://cas.tudelft.nl/fpga_tdc/TDC_basic.html >Im beiliegenden code siehst du wie man die Delay-Line generiert und >direkt in vhdl plaziert. Danke schön, das sieht recht gut aus.
Dennis E. schrieb: > CERN schreibt schönen Code? Was habe ich verpasst? Schonmal in dem Kicad > Code geschaut? Da kräuseln sich einem alle Nägel. KiCAD wird von Cern unterstuetzt, nicht geschrieben...
>KiCAD wird von Cern unterstuetzt, nicht geschrieben...
Soweit ich weiß wurde das speziell für das HLC Projekt entwickelt um
Linzensgebühren zu sparen (Bei einem mulitmilliarden Projekt...)
Gustl B. schrieb: > Ich weiß auch nicht was das mit Indien zu tun haben soll, außer eine > abfällige Bemerkung über Leute anderer Hautfarbe. Wer redet von Hautfarbe? Es ist ein offenes Geheimnis, daß u.a. in Indien, aber auch China und andere aufstrebenden Nationen im akademischen Bereich viele Themen mehrfach kopiert und neu aufgewärmt werden. Da nimmt man bestehende (westliche) Arbeiten (neudeutsch papers) und macht die Versuche nach, ne Prise Eigenanteil, und sei es nur ne andere Schriftart ;-) und fertig ist das "neue paper". Der akademische (Neu)wert hält sich in Grenzen. Das und nichts anders wollte der Diskussionsteilnehmer damit ausdrücken. Ich mein, was sollen die Abermillionen von Absolventen in China und Indien auch "neu" machen, sooo innovativ ist die E-Technik nun auch wieder nicht. Aber wenn man so ab und an die Themen der westlichen/deutschen Geisteswissenschaftler so mitbekommt, u.a. bei aufgeflogenen Plagiaten von Doktorarbeiten, geht es denen noch viel schlimmer ;-)
Falk B. schrieb: > Der akademische > (Neu)wert hält sich in Grenzen. Wird aber fleißig abgedruckt, z.B. auf IEEE! Ich lese auch gerade wieder einige in jüngster Zeit aufgekommene Wellenformgenerator-papers, wo jemand auf die Idee gekommen ist, einen Musik-Synthesizer in einem FPGA zu machen. Grandios wie dort Sachen aufgewärmt werden, die zu Zeitpunkten erstmalig realisiert wurden, als die Schreiber noch im Kindergarten waren. Richtig neu ist dabei nichts. Im Gegenteil: Vieles erkennt man sofort wieder und kennt sogar die Quelle, wo sie es sich zusammengeklaubt haben. Man kann die "copy papers" schon im ersten Satz erkennen, wenn sie darauf hinweisen, dass in "jüngster Zeit FPGAs eine wachsende Bedeutung bekommen haben und immer mehr eingesetzt werden". Meistens sind das Abgänger irgendwelcher halbakademischer Schulen, die von der Existenz solcher Bausteine vor 3 Wochen erfahren haben und nun in ihrer "Master Class" irgendwas bauen, was man in ein paar Monaten hinzimmern kann, wobei dann gleich 3 Leutchen in einer Gruppe arbeiten und zusammen das paper machen, damit es für einen nicht zu viel wird. Unser eins täte sich gar nicht getrauen, das zu publizieren, weil das Meiste eben "engineering" ist, also logisch schlussfolgernd das umgesetzt, was sich aus vorhandenen Überlegungen stringent ergibt. Hinzu kommt, dass es zu meiner Zeit nicht üblich war, dass Studenten einfach was raushauen. Selbst akademisch Wertvolles wurde erst nach internen reviews publiziert, wenn es einen gewissen Stand hatte, weil sich das Institut nicht vor anderen diskreditieren wollte. Und: Eine Reihe der publizierten Dinge, die tatsächlich interessant und wertig wären, sind nur scheinbar neu, sondern hat sie an anderer Stelle schon in Entwicklungen gesehen, an denen man beteiligt war. Die dortigen Ingenieure sind ja auch nicht denkfaul und so gibt es viele Dinge, Verfahren und Methoden, die schon in Produkten stecken, die aber aus gutem Grund nirgends publiziert wurden: Weil es die INGs nicht dürfen und deren AG auch gar kein Interesse daran hat, dass es woanders abgekupfert und nachgebaut wird. Gerade in FPGAs lässt sich allesmögliche Einbauen, ohne dass Urheberrechte zu verteidigen wären, weil keiner reinschauen kann, was einer wie nachbaut. Nachgebaut wird aber sofort, wenn du es publizierst. Daher verzichten Firmen oft auch auf Patente, weil sie nur Zeit und Geld kosten und die Konkurrenz an die Lösung heranführen, statt sie fernzuhalten. Patentiert wird dann lieber irgendwas Banales, was man in den gemeinsam genutzten Topf der Branche einfließen lassen kann. Für akademischen Ruhm kann man sich immer weniger kaufen. Hast du was erfunden, wird es dir auch nicht mehr aus der Hand gerissen, da es in der Firma, wo es eventuelle gebraucht würde, schon lange vor Dir einer stillschweigend entwickelt und eingebaut hat, bzw, man hat sich einen Selbständigen eingekauft, der es entwickelt hat. Der darf aber schon mal gar nichts von dem publizieren, was er verkauft hat.
von Jürgen S. >Ich lese auch gerade wieder einige in jüngster Zeit aufgekommene >Wellenformgenerator-papers, wo jemand auf die Idee gekommen ist, einen >Musik-Synthesizer in einem FPGA zu machen. Hast du eventuell einen Link auf so ein Paper? Mich würde mal interessieren, wie aktuell so gedacht wird und wo die Schwachstellen liegen.
Bei dem Thema gibt es eigentlich keine Schwachstellen mehr, jedenfalls nicht bei denen die Ahnung von der Materie haben. Neues ist da kaum zu finden und soweit es dazu Innovatives gibt, wird keiner was publizieren. In den offiziellen papers gibt es praktisch nur Aufgewärmtes, das teilweise von überall her zusammengebastelt wurde. Musik kommt aus den Kisten sowieso keine raus, weil die Implementierung von einigen Standard-Tongeneratoren und deren Ansteuerung mit MIDI mehr oder weniger trivial ist, der Aufbau einer dynamischen Polyphonie und einer DSP-Sektion mit musiktauglichen Filtern sofort ans Eingemachte geht, wo den Neulingen das Wissen fehlt. Was links angeht: Ich will hier nicht einzelne Ergüsse diskutieren, zumal das thread Thema ein anderes ist. Soweit es Dokumente gibt und gab, die kritikwürdig waren, weil man sich ungefragt Infos von meiner Seite ausgeliehen hatte (inklusive der Rechschreibfehler und der Art des englischen Ausdrucksweise), wurde die entsprechende "Uni" kontaktiert. In 2 Fällen sind die Publikationen dann auch verschwunden.
Ich habe gerade mal auf google scholar (scholar.google.de) nach FPGA-TDCs gesucht. Es gibt da mindestens 10 Veröffentlichungen (hatte keine Lust weiter zu blättern) auf IEEE.org alleine von 2020+2021. Es gibt da schon mehr Verfahren als nur Carry-Chains, aber natürlich nicht 100 verschiedene. Ich finde die aufgewärmten Papers da aber trotzdem interessant, denn sie bieten Updates auf aktuelle Chips. Ist ja schön dass jemand vor langer Zeit auf einem Virtex 4 gezeigt hat, dass es möglich ist, aber wie soll man die Ergebnisse auf einen Artix 7 umrechnen ohne es auszuprobieren? Außerdem bedeuten viele Papers, dass es viele Leute ausprobiert haben, d.h. es gibt mehr Leute als nur ein einsames Genie, die sowas implementieren können.
Uwe B. schrieb: >> CERN schreibt schönen Code? Was habe ich verpasst? Schonmal in dem Kicad >> Code geschaut? Da kräuseln sich einem alle Nägel. > KiCAD wird von Cern unterstuetzt, nicht geschrieben... Und zudem dürften das völlig getrennte Gruppen sein. Es gibt kaum heterogenere Qualität im output von Entwicklern, als es an Hochschulen und wissenschafltichen Instituten der Fall ist. Hans-Georg L. schrieb: > Es gibt viele papers zu TDC in FPGA aber fast alles nichts konkretes. Das ist auch nicht verwunderlich, weil die Firmen, die da eche Anwendungen haben, ihre Konzepte eher für sich behalten, als sie zu veröffentlichen.
chris_ schrieb: >>Ich lese auch gerade wieder einige in jüngster Zeit aufgekommene >>Wellenformgenerator-papers Veröffentlichungen aus der Welt der Musik scheinen aber bezüglich FPGA schon irgendwie von Interesse, wie mir scheint. Hier ein Papier aus Japan mit einem verbesserten Sinus: https://www.researchgate.net/publication/269331819_The_flexible_sound_synthesizer_on_an_FPGA
Jonas B. schrieb: > Soweit ich weiß wurde das speziell für das HLC Projekt entwickelt um > Linzensgebühren zu sparen (Bei einem mulitmilliarden Projekt...) An den Großforschungseinrichtungen werden sehr viele Dinge entwickelt, die nicht unmittelbar mit der Hauptaufgabe zu tun haben, und das ist so auch völlig korrekt und gut. Kein Staat wäre so blöd, etliche Milliarden Euro nur in die Bestimmung von ein paar Teilcheneigenschaften auszugeben. Die technischen Innovationen sind ganz entscheidend dafür, dass sich solch eine Investition überhaupt lohnt. HTTP/WWW wurde z.B. am CERN als hausinternes Dokumentationssystem entwickelt, weil Gopher und Konsorten etwas eingeschränkt waren. Die großtechnische Herstellung von supraleitenden Magneten wurde im Rahmen das Baus etlicher Teilchenbeschleuniger entwickelt, insbesondere auch HERA am DESY. Vorher war so etwas nie nennenswert über ein Bastelniveau hinausgegangen. Als unmittelbare Folge wurde dadurch die großtechnische Herstellung von MRT möglich. Für den Bau von HERA wurde damals übrigens auch ein eigenes Schaltplan- und Layoutsystem entwickelt, damals lauffähig auf Sun-3-Workstations, weil die kommerziellen Systeme viel zu eingeschränkt und nicht für so große Projekte geeignet waren.
Wie passt das: Uwe B. schrieb: > KiCAD wird von Cern unterstuetzt, nicht geschrieben... ... mit dem: Andreas S. schrieb: > Für den Bau von HERA wurde damals übrigens auch ein eigenes Schaltplan- > und Layoutsystem entwickelt, damals lauffähig auf Sun-3-Workstations, ... zusammen? Warum entwickelt man auf der einen Seite ein high-Tech-Layout-System und schwenkt dann auf KiCAD? Hans-Georg L. schrieb: > Es gibt viele papers zu TDC in FPGA aber fast alles nichts konkretes. > Im beiliegenden code siehst du wie man die Delay-Line generiert und > direkt in vhdl plaziert. Wie genau lässt sich das in einem FPGA machen und wie klein sind die Schritte? Die Verzögerungen von Einzelelementen liegt im Bereich von 10..50ps und die Genauigkeit ist stark temperaturabhängig. So etwas baut man in einem ASIC und das tut auch CERN wie man weiß. Einen FPGA kannst du hier nur dazu nutzen, einen Prototypen zu evaluieren.
FPGA-Nutzer schrieb im Beitrag #6695052: > und die Genauigkeit ist stark temperaturabhängig. Naja die Temperaturabhängigkeit gilt ja für alle Elemente in der Delayline. Also man muss nicht jedes Tap neu kalibrieren. Eigentlich müsste es genügen das einmal zu kalibrieren und dann die Temperaturabhängigkeit zu kennen für die ganze Kette. Vielleicht kann man die Kette auch aus vielen IDELAYs bauen und dann die Eigenschaften der Kette zur Laufzeit über die IDELAY Werte verändern.
FPGA-Nutzer schrieb im Beitrag #6695052: > Wie genau lässt sich das in einem FPGA machen und wie klein sind die > Schritte? Die Verzögerungen von Einzelelementen liegt im Bereich von > 10..50ps und die Genauigkeit ist stark temperaturabhängig. So etwas baut > man in einem ASIC und das tut auch CERN wie man weiß. Und die Gatter in einem ASIC sind nicht temperaturabhängig? Schaut man bei den dedizierten Chips wie z.B. TDC-GPX2 so findet man dort unter "Offset error temperature drift" 0,5-1,5ps/K > Einen FPGA kannst > du hier nur dazu nutzen, einen Prototypen zu evaluieren. Und ab wieviel Stück rechnet es sich, einen ASIC statt eines FPGAs zu nehmen? Unter Berücksichtigung, dass man FPGAs für wenig Geld in 28nm bekommt.
Gustl B. schrieb: > ielleicht kann man die Kette auch aus vielen IDELAYs bauen Die sind leider viel zu grob. Die programmierbaren Delays haben so 50ps pro Schritt und sind zum Einstellen der Daten im Bereich <1GHz gegenüber dem Takt. Zudem haben die auch noch lageabhängige Vrzögerungen, d.h. die 50ps können auch 45sein. look-up-Tabellen-Elemente, die als Delay gefahren werden, haben eher so 10ps Verzögerung - von LUT zu LUT sind es 30 .. 40. Man bekommt mit einem FPGA nur zusammengesetzte lines hin, die schwer zu kalibieren sind. In ASICs lassen sich Ketten aus 1000 Elementen bauen, die alle gleich lang sind und vom ASIC compiler obendrein noch so gesetzt werden, dass sie faktisch dieselbe Laufzeit-Verzögerung haben. Die Varianz ist dann im Bereich von 1-2ps zzgl Temperatur. Infolge des gleichmäßigen Aufbaus ist der Temp-drift dann auch sehr gut kalibierbar. Und es kommt noch eines hinzu: Bei einem FPGA hat man einen Baum-artigen Takt, mit Varianzen an den Blättern. Im ASIC kann man den Takt entlang der Kette führen und so das Eintreffen der Flanke gleichmäßig verzögert steuern. Damit ergeben sich faktisch noch kürzere Erfassungszeiten, die zudem auch noch gleichmäßiger sind.
Andreas S. schrieb: > HERA am DESY Ich war Ende der 1980er mal am DESY und hatte mich anlässlich des Nobelpreises für Bednorz und Müller für die Entdeckung der "heißen" Supraleitung mal mit einem Doktoranden dort unterhalten und der meinte, dass man bei den Magneten im HERA noch keine Supraleitung einsetzt. Hat sich das inzwischen geändert?
Markus K. schrieb: > Und die Gatter in einem ASIC sind nicht temperaturabhängig? Schaut man > bei den dedizierten Chips wie z.B. TDC-GPX2 so findet man dort unter > "Offset error temperature drift" 0,5-1,5ps/K Ist das der Drift des Pins oder der gesamten TDC-chain?
Tobias N. schrieb: > Ist das der Drift des Pins oder der gesamten TDC-chain? Ich rate mal: Des Chips würde ich sagen. Da gibt es ja auch noch interne Kalibierketten, die versuchen, den Tempdrift zu messen und zu Null zu machen (was nicht 100% funktioniert). Von einer anderen Anwendung (Laser) kann ich sagen, dass - bei ausreichend intelligenter und aufwändiger Beschaltung - es durchaus möglich ist, eine Temperatur im Chip oder Bereichen des Chips so exakt zu messen und zu steuern, dass Verzögerungen weit darunter auftauchen. Man hat dann nur noch Jitter und Regelungseffekte. Das, was man nicht hinbekommt, sind die Exemplarstreuungen, weil ein und dieselbe Schaltung und Messkette eben in sich in jedem Chip etwas anders aufgebaut ist und reagiert -auch wenn das zu Messene exakt gleich ist.
Noch etwas hierzu: Bechtl schrieb: > chris_ schrieb: >>>Ich lese auch gerade wieder einige in jüngster Zeit aufgekommene >>>Wellenformgenerator-papers > Veröffentlichungen aus der Welt der Musik scheinen aber bezüglich FPGA > schon irgendwie von Interesse, wie mir scheint. Hier ein Papier aus > Japan mit einem verbesserten Sinus: > https://www.researchgate.net/publication/269331819_The_flexible_sound_synthesizer_on_an_FPGA Antwort: Das paper ist aus dem Jahre 2013 und erklärt, dass man mit einer Taktfrequenz von 100MHz in einem FPGA einen guten Sinus hinbekommt, wenn man durch den richtigen Faktor teilt. Wo ist da die Erkenntnis? Die Methoden der dynamischen Frequenzkorrektur über das hinaus, was DDS kann, sind eigentlich bekannt und werden praktiziert - und dies vor allem in früheren Zeiten, als die FPGAs noch langsam waren. Da war das essenziell. Wenn es richtig genau gehen soll, nimmt man die passende 2-stufige DDS mit (bei Musik) n x 12 Frequenzen mit der richtigen Temperierung. Was gibt es sonst noch: Eine Hüllkurve, die aus 4 Stationen besteht und deren Verhalten mit EXP interpoliert werden kann. Das kann meine 2011er Synthversion mit dem Cyclone IV auch, nur verwendet die bereits 6 Stufen für envelope, wie man es in ähnlicher Weise auch von einigen e-Mu Geräten kennt, die ihrerseits nochmal 10 Jahre älter sind. Meine Pyra arbeitet aktuell mit 8/10Stufen, frei programmierbar, ist loopbar und durchläuft einen Tiefpassfilter, mit dem man alles glätten und einem realen Spielverlauf anpassen kann. (Die Idee ist im Übrigen auch nicht neu, sondern der Methode der freien Spannungsprogrammierung vom pSPICE abgeguckt). Schnödes "4er-ADSR" verwenden heute nur noch Analogliebhaber und die, welche fest am MIDI kleben - und diejenigen Techniker, die sich gerade eben erst vor 3 Wochen in die Materie eingeklinkt haben. Man kann solchen Publikationen schon auf den ersten Blick entnehmen, dass die Macher selber mit Musik nicht viel zu tun haben, weil die praktisch wichtigen Sachen gar nicht in Angriff genommen werden. Sinus ist in der Musik ab einer gewissen Präzision gar nicht mehr gefragt. Wichtiger ist, wie sich die Frequenzkorrektur /-manipulation bei einem Vibrato verhält, wenn die Frequenzvorgabe kontinuierlich durchlaufen wird? Der sauberste Weg ist, das mit einem geeigneten Spektrum zu dithern und zu filtern. Davon lese ich da aber nichts.
Jürgen S. schrieb: > Sinus ist in der Musik ab einer gewissen Präzision gar nicht mehr gefragt. Ab welcher Präzision in der Musik ist ein Sinus nicht mehr gefragt?
Benno schrieb: > Jürgen S. schrieb: >> Sinus ist in der Musik ab einer gewissen Präzision gar nicht mehr gefragt. > Ab welcher Präzision in der Musik ist ein Sinus nicht mehr gefragt? Hier kannst Du den benötigten Dynamikumfang ablesen: https://de.wikipedia.org/wiki/Auditive_Wahrnehmung#Mensch_und_S%C3%A4ugetiere Duke
Ich meinte inhaltich eigentlich: Oberhalb einer bestimmten Präzision (beim Sinus) ist in der Musik nicht mehr weitere Genauigkeit gefragt (weil niemand danach mehr Unterschiede hört). Sinus ist ja auch mehr oder weniger langweilig - sogar informationstheoretisch gesehen birgt er praktisch keine Information :-) Den idealen Sinus braucht es eigentlich nur bei Wellensysnthesen, bei denen man per Multiplikation die Oberwellen ableiten will, weil sich dann die Fehler summieren würden und es dann eben doch relevante Abweichungen gibt. Siehe das hier: Vervielfachung der Frequenz mittels Multiplikation Auch für eine Anwendung in der Messtechnik braucht es keine 100 MHz. Da reichen 100kHz, wenn digitale Auflösung, Wandlung und analoge Filterung stimmen. Duke Scarring schrieb: > Hier kannst Du den benötigten Dynamikumfang ablesen: Das macht aber nur eine Aussage, ab wann man einen Ton überhaupt hört. Sind die klassischen Hörkurven. Wird mutmaßlich mit Sinus gemessen(?) und stimmt nicht mit moderneren Messungen überein, weil bei den pool-Mssungen auch immer Leute drin sind, die bei hohen Frequenzen den Schnitt nach unten ziehen, weil sie schon eine C4-Absenkung haben. Wie auch immer: Bei der Frage nach der nötigen Genauigkeit ist ja der maximale relative Oberwellenanteil wichtig, den jemand noch erkennt, um einen sauberen Ton als solchen zu erkennen. Der ist definitiv auch nicht konstant, sondern von Lautstärke und Frequenz abhängig. Dafür kenne ich aber keine solide Quelle. So allgemein geht man davon auß, dass man Klirrfaktoren unter 1% nicht mehr wahrnehmen kann.
Jürgen S. schrieb: > Duke Scarring schrieb: >> Hier kannst Du den benötigten Dynamikumfang ablesen: > Das macht aber nur eine Aussage, ab wann man einen Ton überhaupt hört. Ja, ok. Hier wird das auch bestätigt: https://en.wikipedia.org/wiki/Dynamic_range#Human_perception
1 | This wide dynamic range cannot be perceived all at once, however; the tensor tympani, stapedius muscle, and outer hair cells all act as mechanical dynamic range compressors to adjust the sensitivity of the ear to different ambient levels. |
> So allgemein geht man davon auß, dass man > Klirrfaktoren unter 1% nicht mehr wahrnehmen kann. Das entspricht 40 dB (bei Spannung) oder 20 dB (bei Leistung). Wenn dein System aber nur 40 dB Dynamikumfang hat, geht nur flüsterleise oder Schmerzgrenze, aber nicht beides :-) Duke
Duke Scarring schrieb: >> Klirrfaktoren unter 1% nicht mehr wahrnehmen kann. > Das entspricht 40 dB (bei Spannung) oder 20 dB (bei Leistung). Gemeint sind eigentlich -40dB(THD), also am Ohr. Ist das jetzt (auf die Elektronik rückgerechnet) eine Spannung (wegen SPL) oder eher eine Leistung?
Andreas S. schrieb: > Für den Bau von HERA wurde damals übrigens auch ein eigenes Schaltplan- > und Layoutsystem entwickelt, damals lauffähig auf Sun-3-Workstations, > weil die kommerziellen Systeme viel zu eingeschränkt und nicht für so > große Projekte geeignet waren. Gibt es das noch und ist es noch im Einsatz?
Mark schrieb: > Gibt es das noch und ist es noch im Einsatz? Keine Ahnung. Ich hatte es nur einmal bei einer Führung kurz gezeigt bekommen. Das muss so um 1989 oder 1990 gewesen sein.
Andreas S. schrieb: > Das muss so um 1989 oder 1990 gewesen sein Das könnte leicht veraltet sein, denke ich :-) Aber wer weis, gfs gibt es noch was Internes: Ich kenne 3 Firmen die intere eigene Layout- und PCB-Software im Einsatz haben, weil sich mal wer was gestrickt hat und das eingeführt wurde. So lange der in der Firma was zu sagen hat, bleibt das auch :-) Noch etwas dazu: Markus K. schrieb: > Und ab wieviel Stück rechnet es sich, einen ASIC statt eines FPGAs zu > nehmen? Unter Berücksichtigung, dass man FPGAs für wenig Geld in 28nm > bekommt. Schon ab 1 Stück, wenn man in den ASIC etwas einbauen kann, was man in den FPGA nicht hinein bekommt, z.B. eine schnelle PLL mit bis zu 5GHz, eine besondere IO-Treiberfunktionalität, die FPGAs nur unzureichend nachbilden oder wenn etwas hinein soll, von dem der Programmierer nichts wissen darf, damit er keinen CODE portieren kann. Alle diese Fälle hatte ich schon, inklusive dem, wo der ASIC (da nicht programmierbar) eine Zulassung bekommen hat. ASICs haben auch besonders beim Strom große Vorteile: In einem Fall haben wir ein Design von >8A (Kintex Proto) auf unter 2A runtergebracht. Die kleine Leistung vorort im Gerät war essenziell für das Thema Wärme. Hauptaspekt ist die maximale Geschwindigkeit: Ein auf einem Virtex geprototyptes Design, wurde von einem Drittanbieter mittels Synplify auf immerhin (damals gewaltige) 300MHz gebracht. Die gleiche Schaltung, ohne jegliche Überarbeitung ging dann zum ASIC-Produzenten, der uns aus der Hand nach erster Durchsicht >1GHz zugesichert und am Ende auch geliefert hat. ASIC-Compiler haben ganz andere Möglichkeiten, designs zu optimieren.
Thread beobachten
Seitenaufteilung abschalten