 Hat irgendjemand mal hier mit LibUSB oder PiUSB gearbeitet? Wer denkt denn hier auch, dass USB furchtbar ist? Sergei und Alexander waren hier in den ersten Software Defined Radio vorgeführt. Und dieses Jahr sind sie wieder zurück. Und sie zeigen, wie sie einen neuen gebaut haben mit einem FPGA. Und sie kommunizieren damit über PCI Express. Und wenn ihr dachtet, dass USB fürchterlich war, dann hört man sowas über PCIe zu sagen haben. Willkommen für Alexander und Sergei zu einem Vortrag über Software Defined Radio. Guten Morgen und willkommen zum ersten Kongress-Tag. Hier mal ein bisschen Hintergrund, was wir vorher gemacht haben. Und warum wir das, was wir hier tun, überhaupt machen. Wer weiß denn überhaupt, was SDR ist? Ausgezeichnet. Und wer hat sowas schon mal benutzt? Ich würde gerne mal wissen, ob irgendjemand was teures benutzt hat. Vor 2008 habe ich überhaupt nicht gewusst, was es ist. Und habe mit Voice Over API gearbeitet. In 2008 habe ich überhaupt ein BTS gehört. Und ich wollte es wirklich mal funktionieren lassen. Und das hat uns zu dem heutigen Zustand geführt. In 2009 haben wir in Hardware einen Clock Tamer gebaut, der uns ermöglicht hat, GSM ohne Probleme zu fahren. In 2009 war es nur eine Zeitquelle. Und USRP1 ist keine so gute Basis, wenn man Industrial Grade Base Stations bauen will. Und deswegen haben wir angefangen, unser eigenes zu bauen. Welches wir UMTX Umtricks nennen. Das haben wir in 2011 angefangen. Und unsere ersten Base Stations darauf basierend sind in 2013 rausgekommen. Aber ich wollte schon immer etwas Kleines und Günstiges haben. Aber damals war es nicht möglich. Meine ursprüngliche Idee in 2011 war eine PCI Express Karte, eine mini PCI Karte. Es gab Wi-Fi Karten. Und ich habe gedacht, es wäre toll, in diesem Formfaktor das zu haben, so dass ich in meinen Laptop reinstecken kann. Oder in einem embedded PC. Und es wäre klasse, dann ein schönes Software Defined Radio Equipment zu haben. Aber damals war es nicht möglich, weil die Elektronik größer war und mehr Strom brauchten. Und es hat einfach nicht funktioniert. Und deswegen haben wir UMTX über Gigabit Ethernet gebaut. Es war ungefähr so groß wie zwei Zigaretten-Schachteln. Und dieses Jahr haben wir etwas Neues entwickelt, was mich dahin bringt, wo wir hin wollten. Der Xtricks ist ein mini PCI Express. Und das ist sogar noch kleiner als mini PCI. Und es ist so gebaut, dass man es in embedded Geräte reinstecken kann. Es funktioniert in Laptops. Und du hast ein sehr, sehr kleines SDR Software Defined Radio. Und wir wollten es sehr, sehr günstig machen. Wie viele haben damit gearbeitet? Und der Gap zu dem hier ist sehr, sehr groß. Wir wollen das wirklich zu den Massen bringen. Wir haben es so günstig für möglich gemacht. Der Preis wird ein bisschen größer sein, aber hoffentlich kann sich jeder leisten. Wir wollten wirklich hohe Performance bringen. Und mit hoher Performance, das ist ein volles Transmit mit zwei Channels. Er hat zwei Channels Transmit, zwei Channels Transmit. Und Radio-Welt heißt das zweimal zwei MIMO. Und wir wollten das zu 160 Megasampels pro Sekunde bringen. Und das sind ungefähr 120 Megahertz Radiopandpreite. Was haben wir geschafft? Also das ist der Mini PCI Express Formfaktor. Das hat einen kleinen und den günstigsten FPGA, den RTX 7. Der mit PCI Express funktioniert. Es hat diesen LMS 7000 Chip für sehr hohe Leistung, für enge Koppelung. Es hat sogar einen GPS-Chip mit drin. Auf der rechten Seite oben kann man den GPS-Chip sehen. Das heißt ihr könnt also euer Software-defined Radio mit GPS-Uren abgleichen. Und dann habt ihr keine Probleme mit Telekommunikationssystemen wie GSM oder so was wegen Urzeitproblemen zu fahren. Es hat ein Interface für SIM-Karten. Und ihr könnt also einen Software-defined Radio Modem bauen. So weiter und so weiter. Es ist sehr sehr in gepackt. Und wenn man es mal so genauer anschaut, so fing das an in 2006. Und das ist jetzt, was wir 10 Jahre später haben. Es ist sehr sehr beeindruckend. Das ist aber der Applaus für die ganze Industrie, die das hingekriegt hat. Wir haben nur ein bisschen Zeug auf das Board getan. Aber wir haben nicht die Chip selber gebaut von daher. Das Spannende ist, dass dieser erste Rangehensweise, die wir hatten, dass wir alles auf dieses enge PCB-Design packen, auf 8 Schichten. Also wir haben versucht, einen Rost zu finden, wie viel das kostet. Das sind ungefähr 15.000 Dollar pro Stück. Natürlich bei ganz kleinen Stückzahlen, aber trotzdem ist es immer noch ziemlich viel. Und deshalb mussten wir das alles ein bisschen umgestalten. Das erste, was wir gemacht haben, war, dass wir so viele Schichten haben, diese 8 Schichten. Dass dies wirklich, egal ob man 6 oder 8 Schichten hat, der Preisunterschied ist nicht wirklich groß. Aber wir haben das Ganze rerouted. Und wir haben zwei Verbindungen einfach nur genutzt, die nicht so tief vergraben waren. Das Ganze hat den Preis um einen großen Teil zurückgebracht. Also das ist ein bisschen Geekporn. So sieht unsere Platine aus. Lass uns mal ernsthaft werden hier. Warum haben wir PCI Express benutzt? USB ist wirklich ein Schmerz im Hintern. Es ist ein industrielles System für ganz, ganz viele verschiedene Systeme. Aber es ist nicht wirklich stabil. Also haben wir Ethernet für viele Jahre benutzt. Ethernet hat aber ein Problem, dass es geht so, ein Gigabit geht gerade so. Aber es bietet nicht so die Bandbreite, die wir brauchen. Man braucht viel Strom und so weiter und so weiter. Und PCI Express ist eine gute Wahl, weil es nicht viel Strom verbraucht. Weil es kaum Latenzen hat. Es hat eine hohe Bandbreite. Und es ist relativ universell verfügbar, wenn man mal so in die Hardware guckt. Sowohl AIM Boards haben ganz oft mini PCI Express Anschlüsse. Nur die Probleme sind halt, wenn man im Vergleich zu USB muss man eben die eigenen Kerneldriver schreiben. Und das ist halt, es geht halt kein Weg dran vorbei. Es ist wirklich schwierig, diese Treiber zu bauen, vor allem diese universell zu bauen. Deswegen mussten wir sie halt für Linux bauen. Aber wenn man das Ganze für Windows oder für Mac umschreiben möchte, dann müsste man sehr, sehr viel arbeiten. Und deshalb machen wir das bisher nur auf linungsweise kompliziert ist. Und das Schwierste ist Debugging. Wenn man schon einen kleinen Fehler hat und der hängt halt der komplette Computer, weil wir einen Fehler gemacht haben. Man muss den Neuhof fahren und alles wieder starten. Deshalb ist es etwas schwierig. Und es wird noch schlimmer. Es ist kein Plug and Play Interface. Also wenn man eine PCI Express Karte hat, wenn man die Neustarten will, dann muss man halt das komplette Entwicklungssystem neu starten. Das ist nicht wirklich schön, es ist wirklich kompliziert. Das erste, was wir gemacht haben, ist, dass wir Thunderbolt 3 benutzen. Es ist ja gerade relativ frisch veröffentlicht. Das hat die Möglichkeit, dass man direkt PCI Express arbeiten kann. Es hat ein Modus, in dem man PCI Express in Plug and Play verarbeiten kann. Und bei Thunderbolt 3 kann man das halt sehr gut nutzen, um Plug and Play wiederherzustellen. So dass man das Gerät halt an und wieder abschließen kann und das Ganze einfacher wird. Aber das sind immer noch Probleme. Es wird nicht einfach. Es gibt keine Dokumentation. Thunderbolt 3 ist nicht kompatibel mit den alten Standards von Thunderbolt. Also mussten wir einen speziellen Laptop kaufen, der Thunderbolt 3 hat, der entsprechende Kabel hat. Und wenn man Dokumentation haben will, dann muss man halt ein NDA unterschreiben. Man muss auch so eine Art von Businessplan haben, was man damit anstellen will. Die müssen halt zustimmen, dass dein Businessplan irgendwie Sinn ergibt. Also haben wir gesagt, okay, das wird nicht unsere Lösung. Wir haben jemanden gefunden, der halt diese speziellen PCI Express und Thunderbolt Converter baut. Und das hat uns sehr, sehr viel Zeit und vor allem auch Geld gespart, sodass wir es halt einfach bestellen konnten. So sieht dieser kleine Converter aus, den man dazu benutzen kann. Man stöpselt die jeweils dazwischen und man tut es einfach an den Laptop. Da kann man halt die 6 Tracks einschließen. Üblicherweise hat das UEFI so eine Security Check. Wenn ein Thunderbolt-Gerät, was auch immer, da reinkommt, dann könnte das halt diesen PCI Express-Slot nutzen. Man könnte da irgendwas einfach in den Ramm schreiben. Es ist nicht wirklich gut implementiert, vor allem unter Mac. Unter Windows wird es halt einfach nicht antreten, weil es nicht zertifiziert ist. Bekommen da die Frage, so will man das wirklich benutzen oder auch nicht. Und auf Liedung funktioniert das einfach mal gar nicht. Wir haben das versucht, daraus zu finden, wie man da dran vorbeikommen kann. Wir haben Chips von Intel probiert und das hat immer noch nicht funktioniert. Wir mussten diese Sicherheitsmechanismen dann einfach deaktivieren im Laptop und man muss halt aufpassen, man macht damit sein System auch ein bisschen unsicher. Wir vermuten, dass Mac-Nutzer können das eventuell noch nicht mal deaktivieren. Von da ist es ein bisschen unpraktisch für Mac-Nutzer. Vor allem, vielleicht ist es auch ein guter Ansporn für Leute, diesen Treiber endlich mal zu schreiben. Jetzt mal zu unserem Ziel. Wir wollten 160 Megasample pro Sekunde bei 2x2 MIMO auf 12 Bitschaffen um 12 Beats, das sind insgesamt 7.680 Megabits pro Sekunde. Als wir die Sport halt bekommen haben, dann haben wir halt auch immer ausprobiert und es hat nicht funktioniert. Das erste Ding, was uns aufgefallen ist, das FPGA-Hatware, das Blockteil dieses PCI-Hatwares, implementiert sich halt damit. Das Problem ist aber, die Numerierung ist halt falsch rum sozusagen. Wenn man FPGA-Lay 0 hat, dann ist PCI-E-Lay 1 und andersrum. Wir haben das jetzt hier auch mal so ein bisschen dargestellt, das sieht man nicht so gut, aber eben außerdem rausgefunden, dass halt eine der Komponenten kaputt war, die halt irgendwie in diesen Dead-Bug-State hatten, die halt noch nicht so richtig funktioniert haben und die dann falsch rum angelötet wurden. Wenn man sieht, wie klein das ist, naja, man kann dann schon mal wirklich wahnsinnig was das für eine Arbeit ist. Und als ich mir diese Dead-Bugs angeguckt habe, habe ich einen Handbuch von der NASA gefunden, dass das Anzeige, wie man diese Dead-Bugs anlötet und dass damit es funktioniert. In den Folien gibt es auch einen entsprechenden Ding, könnte euch mal gerne durchlesen. Als wir diese Probleme dann endlich mal gelöst hatten, das nächste Versuch hat irgendwie funktioniert. Die nächste Stufe war, dass es Debugging vom FPGA-Code um das Ganze auf PCI Express zu bringen, weil er das jeweils da mit dem Kornel sprechen muss und mit den Treibern, der Treibern muss dann zum User, mit dem User kommunizieren. Peripheriegeräte sind total einfach, also es ging sofort quasi out of the box. DMA ging nicht, das war wirklich um praktisch, das ist nicht ging. Wir haben sehr, sehr viel Zeit damit verbracht, um DMA laufen zum Lauf zu kriegen. Das Problem mit DMA war, dass man das nicht einfach Breakpoints einbauen könnte, so wie in anderen Sprachen. Es ist ein Echtzeitsystem und es ist halt eine Hardware, die einfach so läuft. Wir haben dann, Sergei hat das entwickelt, dass wir so kleine Testsysteme entwickelt haben für jedes Modul Stück für Stück. Alle Teile des DMA-Codes wurden halt in kleine Happen aufgelöst und wurden dann geprüft. Wir haben ungefähr fünf bis zehn Mal so lange gebraucht, wie dafür den Code zu schreiben. Manchmal erreicht man da so Zeitstrecken, die man erwartet, gar nicht so lange gebraucht. Einige Vorschläge für Leute, die das nachverziehen wollen, es ist in Xilinx ein Logic Analyzer eingebaut. Den könnt ihr benutzen, der ist schön, manchmal hilft er. Aber man kann vorübergehende Fehler nicht damit debaggen. Das heißt, du musst Readback-Register implementieren. Du musst informieren, wie das System sich verhält, wie die DMA-Interfaces gefüllt werden, wie viel gesendet, wie viel empfangen wurde. Zum Beispiel können wir sehen, wenn wir den Bus auffüllen oder wenn der Host die Daten nicht schnell genug zur Verfügung stellt, wenn ein Underrun passiert. Das ist ein mehrschichtiges Problem. FPGA, DMA, PCI-Bus, Kernel und Treiber. Also das Ziel war das obere hier, 160 Megasamples. Die Software war einfach nicht schnell genug. Sie hat viel gemacht, aber das Wichtigste ist, dass man real-time Prioritäten verwenden muss und dass man Software-Banks in Nordrhein-Westfalen holen muss. Die Buffers haben wir nicht sofort freigegeben. Die waren beschäftigt, länger als es hätten sein sollen. Das hat extra einen Zyklen gebraucht und das hat die Bandbreite reduziert. Jetzt lass uns mal darüber reden, wie man High-Performance-Treiber implementiert für Linux. Wenn man echte Performance rausholen will, dann muss man mit dem richtigen Design anfangen. Es gibt drei Ansätze dafür und ein ganzes Spektrum in der Zwischenzeit. Zwei Ansätze und das Spektrum in der Zwischenzeit. Also IO-Control ist der erste. Der Kerneldreiber hat alle Logik, das Gerät zu kontrollieren und im User-Space wird das exportiert. Der User-Space sieht die Details zwar nicht, aber das Problem ist, dass der langsamste Einsatz ist. Der andere Weg ist das Zero-Copy-Interface. Unsere einzige Kontrolle ist, wo Daten im Kernel gehalten wird und wir machen kein Memory-Copy und dadurch das wir das nicht tun, wird es immer schneller. Ah, und es passiert noch ein Kontext-Switch zwischen Kernel und User-Space und damit verliert man immer noch mal Zeit. Der allerschnellste Ansatz ist Full-User-Space-Control. Also der Kernel zeigt dem Benutzer alles und sagt so, dass er selber ist und dann hat man keine Kontext-Switches mehr und der Benutzer kann wirklich selber darauf zugreifen und alles optimieren. Was gibt es für Probleme damit? Der Vorteil ist die Geschwindigkeit. Der Vorteil ist, dass ich also keine Switches zwischen Kernel und User-Space habe, dass es geringe Latenz hat und dass eine hohe Bandbreite hat. Wenn die höchste Performance mir nicht das Wichtigste ist, dann kannst du die Latenz hacken, weil du keine Notifikationen aus dem Kernel kannst, dass die Ressourcen mehr Daten gibt. Also ich kann angegriffen werden. Es macht es angreifbar, wenn der Benutzerbereich das zugreifen kann, dann kann man es halt auch von außen leichter angreifen. Noch eine wichtige Sache. Wie regt man tatsächlich die beste Performance aus dem Bus aus? Also entweder Polling oder Notifications. Polling ist, wenn ich regelmäßig nachfrage, bist du fertig, bist du fertig, bist du fertig, und dann kriege ich die Daten. Ein Busy-Luke, also eine Schleife, die die ganze Zeit läuft und immer wieder prüft. Zum Glück haben wir mehrere CPUs und man würde ein ganzes Core nehmen, denn nur die ganze Zeit immer wieder fragt. Und die ganze Zeit immer nur schaut, ob was Neues da ist. Wenn ich aber nicht diese höchste Performance brauche und diese CPU nicht verschwenden möchte, am Schluss haben wir eine Architektur gewählt, die kombiniert ist. Es ist möglich, das Polling zu verwenden und es ist auch möglich, das über Interactive Notifications zu machen. Und das ist der beste Ansatz, wenn man beide Welten bedienen will. Hier ist die Architektur unserer Bibliothek. Wir haben versucht, das Motabel zu halten und Flexibles zu machen. Es gibt einen Kerneldriver, der Kerneldriver spricht mit einer Low-Level Bibliothek. Das sind die Dinge, die wir rausgenommen haben, um PCIe Express zu kontrollieren und mit EMA zu reden. Und die Details, die wir haben, und die Details der Busimplementierung zu abstrahieren. Und dann haben wir eine High-Level Bibliothek, die mit dieser Low-Level Bibliothek geredet, um die Peripherie-Geräte zu kontrollieren und insbesondere unser XTRI, unser PCIe Express, unser XTRI, wir können das vielleicht zu anderen Betriebssystemen mitnehmen. Und das ist unser Ziel gewesen. Ein weiteres Interessant des Problems ist, wenn man ein Linus-Triver schreibt, wenn man also sich auch auf die Linus-Tribe schreibt, ist es gut, wenn man sich auch auf die Linus-Tribe schreibt, ist es gut, wenn man sich auf dieses Buch bezieht, das LDD, das ist nicht mehr aktuell. Linus-Device-Triversbuch, ja, LDD. Also, dieses Buch ist nicht aktuell genug, deswegen muss man alle Handbücher von den Geräten selber lesen. Wenigstens kriegt man up-to-date Informationen. Wir haben uns entschlossen, das alles einfach zu machen. Deswegen haben wir TTI-Device für GPS verwendet. Alle existierenden Anwendungen können sofort funktionieren. Wir wollten die System-Uhr mit dem GPS synchronisieren. Also, wir wollten die System-Uhr mit dem GPS synchronisieren. Das ist wichtig, wenn man viele Geräte um die ganze Welt betreiben will. Wir haben rausgefunden, dass es zwei verschiedene Programme gibt. Das eine, das andere, das andere. Was noch interessant ist, wie wir es jetzt hier erklärt haben, wir wollten ein Pool-System, sodass wir Informationen aus dem Köln bekommen können, wenn sie vorhanden sind. Wir müssen nicht immer gucken, was da gerade los ist. Als wir das alles ein bisschen optimiert haben, haben wir immerhin zehn Megasamples erreicht. Es ist immer noch sehr weit von dem entfernt, was wir eigentlich bekommen wollten. Eigentlich sollten hier ein paar Erklärungen zu PCI Express sein. Als wir alles runtergeschrieben haben, was wir sagen wollten, werden es am Ende zwei Stunden über PCI Express gewesen. Deswegen machen wir das nicht, aber ich gebe euch ein paar Highlights mit auf den Weg, die interessant sind. Wenn es da ernsthaft Interesse gibt, wir können irgendwie einen Workshop machen, irgendwann heute oder später, und können uns über PCI Express unterhalten. Die Sache ist, es gibt keinen Open Source Course für PCI Express, die vor Leistungen gehen. Auch was gerade was Echtzeitanwendungen angeht. Wir haben Siliboss gefunden, das ist ganz nett. Aber das ist nicht wirklich, das lief halt keine hohe Bandbreite. Es ist aber dafür sehr beliebt. Wenn ich recht in Sinne, dann kann es ungefähr 50% der Schnittstelle nutzen. Dann gibt es Silings. Wenn man Silings benutzt, ist man wirklich in dieses System eingeschlossen. Es ist nicht sehr effizient in Sachen Ressourcen, weil wir möchten das sehr, sehr einfach und sehr, sehr günstig machen. Deshalb müssen wir alles in diesen kleinen Artics 7 FPG hereinschmeißen. Das ist sehr, sehr aufwendig und sehr, sehr kompliziert. Wir können keine Ressourcen verschwenden dafür. Also war dann am Ende die Entscheidung, dass wir diese Immentation selber bauen und so sieht die aus. Ich werde das jetzt nicht mit euch diskutieren. Da waren verschiedene Interaktionen und es ging erst mal nicht so richtig und das ist jetzt unsere Entlösung. Noch ein paar interessante Sachen über PCI Express, das funktioniert sehr, sehr gut auf Item Prozessoren, weil wir darauf gearbeitet haben, weil wir sehr viel mit Embedded-Produkten zu tun haben und als wir versucht haben, das in einen ganz normalen Core i7 zu stecken, dann ist es zum Teil aufgehängt. Wir haben wirklich einige Tage damit zugebracht, dass zu debugging. Wir haben dann festgestellt dass der Wert 0 im ByteCount steht nicht für 0 Bytes, sondern für 4096. Das ist eine wirklich sehr, sehr seltsame Anpassung und das ist halt nicht wirklich im Standard. Eine andere Sache ist Completion. Es ist ein Begriff im PCI Express, der für Anerkennung schon ist überträgt er doch Daten. Wenn man diese Completion nicht schickt, dann hängt es das System auf. Was dann passiert, ist das, das hat irgendwas mit historischen Sachen zu tun in den Prozessoren. Es wird FFF dann rausgegeben. Wenn man Register hat, wenn man da eins setzt, um zu sagen, es ist okay, dann wird halt immer gelesen, dass dieses Device okay ist. Deswegen darf man eins nicht als Status für OK nutzen, wenn man, man sollte lieber 0 wählen oder irgendeine 2-Bit Info, um diese Fehler nicht zu erhalten. Wenn du ein Gerät hast, was auf irgendeiner Schicht kaputt geht oder nicht funktioniert, es ist sehr schwierig zu debacken. Gerade was auf Speicherprobleme angeht, wird ein Softwarefehler der DMA-Adressen falsch geschrieben. Und wir haben uns gefragt, warum wir gar keine Daten in unserem Buffer kriegen und nach ein paar Neustarts des Systems ist es einfach irgendwann aufgehangen. Und das ist der Grund dafür, warum wir diese UEFI-Einstellung nutzen. Wenn man Geräte einen wieder abstöpsel, dann wurde halt das Hein in beliebigen Teil des Speichers geschrieben. Wir haben halt dann Tests gemacht und einzelne Test-Charges, um diesen Fehler dann am Ende zu finden. Eine Sache ist, wenn man Sachen initialisiert, dann kann man in eine Situation kommen, wo man in Speicher schreibt, der bereits freigemacht, freigemacht wurde von anderen Systemen. Das ist ein sehr bekanntes Problem, und das passiert auch hier. Aber warum ist DMA so schwer? Es gibt diesen Completion-Ding, diese Architektur für Schreiben, um Daten zu lesen. Wenn man sie abschickt, dann ist sie halt weg und ist auch raus. Aber wenn man sie liest, da muss man seine Daten irgendwie in einem Brauchbahnformat zurückkriegen. Und das sieht übrigens so aus. Wir hatten eigentlich hofft, dass wir euch irgendwie was zeigen können, aber um links kann man sehen, das sind die Anfragen zum Lesen. Jede Transaktion kann in verschiedenen Transaktionen aufgeteilt werden. Man muss all diese Teile wieder zusammensuchen und diese in die richtigen Stellen des Speichers schreiben. Das ist aber nicht alles. Die Sache ist, dass die Latenz zwischen Anfrage und Completion ist halt sehr, sehr hoch. Man hat ungefähr 15 Zyklen. Wenn man nur eine einzige Transaktion hat, dann hat man diese multiplen Transaktion-Sachen-Komplischen. Und Transaktionen können auch Daten in der beliebigen Reihenfolger raushauen. Das ist sehr, sehr kompliziert und sehr komplex vor allem. Und vor allem komplexer als wir vor allem gedacht hatten. Wir mussten das erstmal bemerken, als wir das eingebaut haben. Hier war auch so eine Beschreibung, wie das überhaupt alles so funktioniert hat. Aber das haben wir uns jetzt gespart. Jetzt, nachdem wir diese ganzen Optimierungen durchgeführt haben, haben wir 20 Megasamp pro Sekunde. Dann haben wir alles, was wir ursprünglich angepeilt hatten. Das Nächste ist, dass wir PCI-Express-Lanes-Scalability adressieren müssen. Also es ist ein serieller Bus und hat mehrere Spuren. Und die lassen uns heutzutage skalieren. Und je mehr Spuren man nimmt, desto mehr Performance kriegt man raus. So, das Problem ist, dass bei Mini-PCI der Standard standardisiert nur eine Spur und die zweite ist optional. Und die meisten Motherboards unterstützen das nicht. Und wir wollten das unbedingt. Deswegen haben wir ein extra Konverter gebaut, der Mini-PCI in einen vollen Breite reinstecken, damit man zwei Spuren hat. Und wir planen noch ein Board, was mehrere Slots hat, um XTRX auf eine gleiche Basisplatte stecken und das dann zum Beispiel in X16 reinstecken kann. Und hier werde dann das Problem haben, die ganzen Daten umgehen wollte. So, mit den zwei Spuren haben wir dann 50 Megasampes gekriegt. Das war jetzt nur noch 2,5 mal langsamer. Und jetzt mussten wir uns wirklich dran machen, das Fett abzuschneiden. Wir übertragen 16-Bit anstatt 12-Bits zu übertragen. Wir haben den Treiber ursprünglich entworfen, dass er 8,12 und 16-Bit übertragen kann. Und für den Test für den Test sind wir von 16 zu 8 gegangen. So, jetzt mit 8-Bit Samples sind wir auf einmal, wir hatten immer nur 15 Megasampes pro Sekunde. Was war denn hier los? Wir haben zwar keinen Fehler gemacht, aber wir wussten das einfach nicht während, als wir es entworfen haben. Wir hätten für den schnellen Bus eine höhere Wollzahl wählen müssen. Und mit 1,8 Volt ist der Bus einfach nicht so gut. Unser nächster Prototyp wird eine höhere Wollzahl auf dem Bus verwenden. Und das ist was wirklich das Design für Highspeed sehr, sehr schwierig macht, weil man tatsächlich auch auf solche Details achten muss. Und das ist was wirklich das Design für Highspeed sehr, sehr schwierig macht, weil man tatsächlich auch auf solche Details achten muss. Wir wollen 1,8 Volt für die anderen Sachen. Der MiniPCI Express Standard erlaubt nur 2,5 Watt für das Gerät und nicht mehr. Und der LMX7 hat so eine gute Performance und da hatten wir alle wirklich in anderen Sachen mit drauf. Aber mit einer höheren Wir können den Stromverbrauch einfach nicht hochgehen lassen. Wir sind bei 2,3 Watt und wir sind ziemlich am Limit. So, wenn wir den Bus auf die höhere Wollzahl bringen und das ist jetzt hier eine theoretische Übung, das haben wir noch nicht gemacht, dann sollten wir folgende Ergebnisse kriegen sollen und das ist dann 1,2 Mal langsamer. Und der nächste Schritt am Anfang haben wir einen falschen Chip gekauft. Eine Ziffer war anders. Ihr könnt es hier sehen. Es ist rot und grün und dieser Chip hat nur PCI Express Generation 1 unterstützt und das ist halb so langsam wie die nächste Version. Und hoffentlich können wir das nächste Mal einfach durch den Ersatz des Chips die Performance höher kriegen. Und das ist dann immer noch langsamer als wir es ursprünglich wollten. Und hier ist, wo die Differenz herkommt. Hier der Bus hat eine Overhead. Der Standard gibt uns 4 Kilo Byte Payload aber die eigentlichen Implementierungen, Laptop Computer sind da einfach anders. Die haben nur 128 Byte Payloads und damit gibt es ein großes Overhead auf dem Bus. Und theoretisch kann man mit so einem Payload nur 87% Effizienz erzielen. Und auf dem Xeon ist es doppelt so groß. Der schickt 256 Byte und 92% Effizienz. Das ist noch vor Overhead. Eine Sache, die wir nicht erwartet haben wir haben auf Intel Atom entwickelt und alles hat wunderbar funktioniert. Als wir das dann in ein Laptop reingesteckt haben mit Multicore ein richtig kräftiges Gerät und ein Core 7 sollte eigentlich besser funktionieren. Aber das war nicht so. Und der Laptop hat da eine eingebaute Videokarte auf dem gleichen PCI-Bus. Und der Hersteller hat höhere Prioritäten eingebaut für das Video. Alles für alles andere. Und er wollte nicht, dass der Bildschirm flackert. Und wenn man ein Fenster bewegt dann sieht man, dass die Pakete zum PCI-Gerät später kommen. Und man kann das mit dem PCI-Gerät nicht mehr implementieren. Um das auszukletten. Der Xeon funktioniert echt gut. Der ist sehr optimiert. Und wir haben das mit einer diskreten Videokarte getestet. Und wir haben 5-7% mehr als aus dem Atom rausgekriegt und wir haben noch keinen Workshop. Aber wenn hier jemand das Gerät sehen möchte, wie es funktioniert oder wenn du mehr über PCI-E wissen möchtest, dann werden wir in den nächsten Tagen einen Workshop durchführen für euch. Vielen Dank. Vielen Dank. Wenn ihr die Fragen habt, please line up right behind the microphone. I think you just read, because we don't have anything from the signal angle. However, if you are watching on stream, you can hop into the channels and over social media to ask questions. And they will be answered. Minimal und maximal Frequenzen der Karte. Die Sampling-Frequenzen. Diese anderen Geräte können nur oberhalb von 50 MHz sammeln. Wenn man mal die Referenzwerten guckt, dann liegen sie bei ungefähr 0. Unter 15 MHz bis zu 3.8 GHz. Wenn es um die Sampling-Rate geht, aktuell geht es von 2 MHz bis 50 MHz, weil wir arbeiten gerade auf diese Zahlen zu kriegen. Vielen Dank. Habt ihr es geschafft, euren Kerneldreiber in den Mainline-Körnel reinzukriegen? Ich habe es schon am Anfang gesagt. Ich wollte es am Anfang schon sagen. Wir haben bis hier erst den ersten Prototypen, den wir hart debugt haben. Wir arbeiten am zweiten Prototypen, wo auch diese Fixes installiert werden. Was um Kerneldreiber geht und alles. Wir wissen nicht, wieviel versuchen wir dafür brauchen. Es sieht so aus, ob ihr durch Schmerzen durchgegangen seid, um das zu bekommen. Habt ihr irgendwelche Simulatoren für PCI-Boss gefunden? Dass man so ein System im Simulator entwerfen und dann debaggen kann? Es gibt Simulatoren, aber die Probleme sind, dass sie nicht gratis sind, sondern ob sie dafür bezahlen. Deshalb ist es etwas schwieriger. Sind diese Codes für den FPGA, für den Nennungstreiber und die Bibliothek öffentlich? Und kann man die irgendwo finden? Sie sind nicht veröffentlicht bisher. Die Bibliothek und die Bibliothek sollten demnächst irgendwann Open Source verfügbar werden. Wir werden die öffentlichen Bekanntgabe des ganzen Projekts. Habt ihr auf dem PCI-Boss irgendwelche Signalfehler gesehen? Habt ihr irgendwas gemessen? Oder Verlässlichkeitsprobleme gehabt? Mit PCI haben wir nie wirklich Probleme gehabt. Es hat einfach funktioniert. Das Bord ist so klein. Das sind nur kleine Spuren, aber es sind keine Probleme mit irgendwelchen Signalen. Das kleine Bord zu bauen ist echt viel einfacher. Das Problem ist nicht die Signalintegrität, die der Spuren angeht, sondern eher, dass das Signal ein bisschen abnachlässt. Je nach Geschwindigkeit. Es kommt irgendwie unter die Detektionslinie. Wir hatten ein paar Bilder dafür, aber die haben wir jetzt nicht dafür gezeigt. Die waren jetzt nicht so superinteressant. Danke für den Vortrag. Wie viel Arbeit wäre es diesen 2x2-SDR in einem 8-Input-Logic-Analyzer zu verwandeln, so dass man einen sehr schnellen Logic-Analyzer hat. Mit dem man unbegrenzte Traces aufzeichnen kann. Also einen schnellen analogen Digital-Converter. Und ich will fast Sampling. Und ich möchte eine große Menge Speicher um diese Traces zu speichern. Wir denken das ist einfach nicht die beste Anwendung dafür. Ich weiß nicht so wirklich. Vielleicht fährt Herr Sage irgendeine Idee. Ich glaube, es ist einfach so einfacher, schnelles ADC zu kriegen. Um das zu bekommen, was man möchte. Es gibt so viele Sachen, die halt speziell für REF sind. Man kann nicht einfach originale Daten sammeln. Und jeweils über die Frequenz schieben, das geht nicht einfach. Man kann das Original-System einfach nicht kopieren. Das ist wirklich schwierig. Auch diese ganze Analyse ist sehr kompliziert. Habt ihr die Sample-Rate? Habt ihr die Sample-Rate von dem neuen mit dem US-MPT verglichen? Und wenn ja, was sind die Ergebnisse? Wenn man diese niedrige Sample-Rate und die hohe Sample-Rate vergleicht, wir haben bisher nicht viel damit getestet, was die Performance angeht. Weil wir so beschäftigt waren mit diesen Dingen. Wir müssen noch abwarten, was niedrige Bittraten angeht und hohe Bittraten, die hohen Bittraten geben einem üblicherweise bessere Performance. Es verbraucht aber auch mehr Strom. Es ist eine Frage von dem, was wichtiger ist. Ich habe gesehen, es gibt keinen Mixer-Bypass. Ihr könnt also nicht direkt das Signal aufnehmen. Gibt es einen Send? Es gibt es tatsächlich. Aber es ist nicht wirklich ein Bypass. Es ist irgendwie so ein Umgang von dem Chip. Da wir nicht wirklich so viel Platz hatten, haben wir das eben ein bisschen umgeschrieben. Deswegen kann man das nicht einfach umgehen. In unserer Hardware ist das so. Grundsätzlich gibt es das aber in den Chips, der es möglich macht, dass man das Signal direkt auf ADC schreiben kann. Unabhängig von Mixern, Filtern, allen möglichen Dingen. Grundsätzlich ist es möglich. Wir haben auch tatsächlich darüber nachgedacht, das zu machen, aber wir haben uns dazu entschieden, mit anderen Antennen gemeinsam zu verwenden. Ich würde gerne die gleiche Antenne für Send und Empfangen verwenden. Das hängt davon ab, was du machen möchtest. Wenn man das ADC-System benutzen möchte, dann geht das. Wenn das FD-System benutzen möchte, dann braucht man halt ein Duplexer. Man kann das einfach an seinen Laptops stecken und die bereits vorhandenen Antennen benutzen. Das war einer der Gründe, warum wir Extracks benutzen. Weil da vier Anschlüsse sind. Was wir auch ein bisschen angerissen haben in den Folien, alle anderen SDRs, die es so gibt, egal ob Ethernet oder USB, können mit bestimmten WLAN-Systemen nicht zusammenarbeiten. Das bekannteste davon ist zum Beispiel Wi-Fi. Es ist, weil die Latents zwischen dem System und dem Radio so hoch ist, auf USB, kann man einfach nicht schnell genug reagieren auf Wi-Fi. Wenn das Spektrum frei ist, dann kann man halt übertragen. Wenn man weiß, dass das Spektrum damals frei war, dann ist es okay, aber mit Extracks kann man halt nicht mit Systemen arbeiten wie Wi-Fi. Da geht es halt um diese Software-Implimitation des Laptops. Es würde nicht so gut funktionieren wie irgendwie das kommerzielle WLAN, weil man halt sehr, sehr viel Prozessorleistung auf dem Hauptprozessor leisten muss. Man kann das natürlich experimentieren, aber das ist natürlich schon wertvoll. Welches PCB-Entwurfs-Ferkel-Shop dir verwendet? Es wäre toll, wenn dir den PCI Express Workshop tatsächlich heute noch durchführen würde. Ich hätte auch gerne den Workshop, wenn er passiert. Was sind die Synchronisierungsmöglichkeiten zwischen verschiedenen Tests? Kann man die Uhr synchronisieren? Und kann man das digital hergestellte IF synthesieren? Diese IF-Geschichte ist nicht möglich wegen der niedrigen Frequenz. Aber man kann das ganze digital pern. Wir haben verschiedene Lines für die Plox-Synchronisation, aber wir können sehr, sehr viel über Software bauen. Man kann zum Beispiel die Phasenunterschiede messen. Die Phase rotieren, bis es ausgerichtet ist. Man kann zum Beispiel die Phasenunterschiede messen. Die Phase rotieren, bis es ausgerichtet ist. Man kann zum Beispiel die Phasenunterschiede messen. Man kann zum Beispiel die Phasenunterschiede messen. Wir haben eine andere Frage von der Internet. Was ist der erwartete Preis für den nach dem Prototypen? Könnt ihr uns mehr über das Setup zum Debuggen von PCIe-Eschuess erzählen? Das ist nochmal die zweite Frage wiederholen. Das ist nochmal die zweite Frage wiederholen. Was ist der erste Frage? Die zweite Frage, die betrifft vor allem, ist es sehr kompliziert zu erklären. Wir haben ein sehr, sehr hartes Setup da gehabt. Was hardware angeht, so sieht unser Hardware aus. Wir haben diesen PCI Express auf Thunderbolt Adapter gekauft. Wir haben ein Laptop mit Thunderbolt 3 gekauft. und so haben wir es halt debugt. Also man muss nicht so einen mega krassen Computer haben, der irgendwie alles kann. Was dem Preis angeht, wir haben keinen festgelegten Preis bisher. Was ich bisher sagen kann, ist, dass wir so ungefähr auf nicht mehr als die üblichen Geräte sein wird. Könnte sogar einigen Versionen günstiger sein. Okay, we are out of time, so thank you again Sergei