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
24,8 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?
Thread beobachten
Seitenaufteilung abschalten