Mess- und Prüftechnik / HF-Systemdesign SystemVUE versus LabVIEW Communications

Erreichung der 5G-Designziele

D&E: Was bedeuteten Design-Ziele wie hohe Datenraten, Konnektivität und Low-Power auf Entwicklungsebene? Wie wird das in Ihrer Software adressiert?

NI: Die Verwendung von Hunderten von Antennen an der Basisstation reduziert die Strahlungsleistung, da die Energie mithilfe von Vorcodierungstechniken direkt auf die mobilen Endgeräte gerichtet wird. Gleichzeitig werden auch die Interferenzen mit anderen Nutzern gesenkt, sodass eine höhere Anzahl an Nutzern unterstützt werden kann. Die Leistung mehrerer Antennen summiert sich zu einer höheren Sendeleistung der Basisstation – selbst wenn die einzelne Antennenleistung gering ist – und damit kostengünstig – einer größeren Reichweite der Zelle, einem verbesserten Signal-Rausch-Verhältnis und einer höheren Datenrate. Das MIMO-Application-Framework für Mobilfunkanwendungen unterstützt bis zu 128 Antennen an der Basisstation für die Kommunikation mit bis zu zwölf Nutzern gleichzeitig auf derselben räumlichen und vollen Frequenzbandbreite mit denselben Zeitressourcen. Erreicht wird dies durch die auf Kanalreziprozität basierende lineare Entzerrung und Vorcodierung für Multi-User-MIMO.

Keysight: Teils müssen gegenläufige Ziele miteinander vereinbart werden. Das ist zwar größtenteils Aufgabe im Implementierungswerkzeug, moderne Schaltungen beinhalten heutzutage aber auch jede Menge digitaler Kontrolle zur benutzungsabhängigen Optimierung – sogar die HF-Komponenten und vor allem der PA. Teils müssen gegenläufige Ziele miteinander vereinbart werden. Wurden und werden analoger PA und beispielsweise digitales Envelope-Tracking zur Erhöhung der Energieeffizienz getrennt entwickelt und dann erst im Labor gemeinsam verifiziert, lassen sich in SystemVUE beide miteinander kombinieren und bereits vor der Fertigung auf ihre Wirksamkeit prüfen.
 

D&E: Wie können Parameterräume in der Software erkundet werden? Wie viele Parameter muss ein 5G-System in etwa simultan handeln? Wie geht das HMI mit der Parametervielfalt um?

NI: Im Allgemeinen lassen sich die Systemparameter jeder Plattform in zwei Bereiche unterteilen. Der erste Bereich ist die Hardwarekonfiguration, die vor der Systeminitialisierung feststehen sollte. Darüber hinaus müssen auch einige Systemparameter vor dem Systemstart konfiguriert werden. Der zweite Bereich sind dann die Systemparameter, die während der Ausführung neu konfiguriert werden können. So bietet beispielsweise das MIMO-Application-Framework für die 5G-Entwicklung eine Oberfläche für die Konfiguration und Darstellung des Systems.

Konfigurationsparameter wie die Anzahl der Basisstationsantennen und die Trägerfrequenz sollten vor dem Systemstart festgelegt werden.
Die Auswahl des Entzerrungs- und Vorcodierungsalgorithmus für MIMO sowie die Nutzeridentitäten können dann während der Ausführung geändert werden. Bild 1 zeigt einen Screenshot der Benutzeroberfläche.

Keysight: Parameter lassen sich im SystemVUE durch den Matlab-Syntax beliebig miteinander kombinieren um Abhängigkeiten festzulegen. Sie können sowohl manuell als auch automatisch auf verschiedenste Weise verändert werden. Zu nennen wäre in diesem Zusammenhang das Tuning, bei dem einzelne Parameter vom Benutzer gezielt Schritt für Schritt verändert werden, der klassische, automatische Parameter-Sweep sowie Monte-Carlo-Analysen. Sogar eine Optimierung gibt es in SystemVUE. In den Kurven werden Variationen selbstverständlich übereinander gelegt. Es sind natürlich viele Parameter, die den 5G PHY Layer bestimmen, wenn auch lange noch nicht so viele wie bei LTE. Das liegt einfach daran, dass der Standard noch nicht so fortgeschritten ist. Auch hängt die Anzahl der Parameter von der Detailtiefe des modellierten Systems ab.
Meine 28-GHz-Vorlage zählt etwa 50 Parameter, die aber nicht alle gleichzeitig variiert werden. Sweeps gehen selten über eine handvoll Parameter hinaus. Es gibt mehrere Ebenen auf denen Parameter definiert werden können. Grundsätzlich kann zwischen globalen (Workspace) und lokalen (Design) Variablen unterschieden werden. Global sind alle Variablen, die in sogenannten Equation-Blöcken im Workspace berechnet werden. Jedes Modell, jede Funktion hat dann wiederum ihren eigenen Parameterraum, kann Werte natürlich vom globalen Speicher übernehmen. Für Schematic-Designs bedeutet dies, dass auf einem extra Tab sogenannte »Parameter« definiert werden können, die von oben her übergeben werden.

Daneben gibt es auch hier einen lokalen Equation-Tab, auf dem weitere lokale, sogenannte Design-Variablen berechnet werden können, die dann an die Blöcke im Schematic übergeben werden. Die Umgebung wiederum bietet zwei Fenster: eines für Workspace-Variablen und eines für die Design-Variablen des gewählten Designs. Im Debugger lassen sich alle Schritte und Variablen nachvollziehen.


D&E: Die Werkzeuge besitzen viele Softwareschnittstellen: Der Einsatz solch einer Werkzeugvielfalt, bedeutet im Schritt von Simulation zu Hardware-Prototyping oft einen Mehraufwand, vor allem durch Debugging von Inkonsistenzen zwischen den unterschiedlichen Sprachen. Sehen Sie dieses Problem?

NI: Mit LabVIEW Communications kann sowohl für Prozessoren als auch für FPGAs der Code in der nativen grafischen Programmiersprache geschrieben werden. Ein Entwickler kann also für das gesamte System eine einzige Softwareschnittstelle verwenden. LabVIEW Communications reduziert Inkonsistenzen, da keine verschiedenen Sprachen notwendig sind. Möchte ein Entwickler IP aus einer bestehenden Umgebung wiederverwenden, erlaubt LabVIEW Communications die Integration von Programmcode, der zum Beispiel in C, Matlab und VHDL geschrieben wurde. Das bedeutet, dass für die Anbindung an I/O nicht der gesamte bestehende Code umgeschrieben werden muss. Diese Flexibilität steigert die Produktivität deutlich, da dem eigenen Gedankenfluss folgend entwickelt werden kann, anstatt die Lösung in eine Sprache oder einen Designansatz zwängen zu müssen.

Keysight: Falls Sie mit unterschiedlichen Sprachen meinen, dass Simulanten (IP3) und Messknechte (EVM) nicht immer die gleiche Sprache sprechen und somit unterschiedliche Verifikationsmethoden zum gleichen Ergebnis führen sollen, so wollen wir genau das minimieren. Prinzipiell kann in allen Disziplinen die gleiche Testbench verwendet werden. Darüber hinaus sind die Algorithmen in SystemVUE und unserer Messtechnik-Software Signal Studio beziehungsweise VSA identisch.

Mit Ausnahme der Fixed-Point-Blöcke sehe ich das Problem der Synthese von Systemsimulation zu echter Hardware als ein klassisches der Implementierungswerkzeuge. Die Softwareschnittstellen im SystemVue dienen eher der Verifikation von Hardware-Modellen im Systemzusammenhang.
 

D&E: Wie kompliziert oder einfach fällt die Testsignalerzeugung in der Simulation aus?

NI: Das LTE-Application-Framework ermöglicht die einfache Erzeugung von Signalverläufen in Übereinstimmung mit ausgewählten PHY- und MAC-Funktionen des LTE-Release 10 von 3GPP.  Mit dem 802.11-Application-Framework lassen sich durch sofort ablauffähige Software ebenso problemlos WLAN-Signale erzeugen.

Keysight: Es hängt vom Anwendungsfall ab. Bei ausgereiften Standards wie LTE reicht manchmal schon die simple Auswahl eines vordefinierten Testmodels. Das Aufsetzen der gesamten Basisbandsignalverarbeitung für ein ganz neues, eigenes Signal bedeutet schon etwas Aufwand. Grundsätzlich ähnelt das Setup dem auf den Messgeräten, was früher nicht der Fall war und immer wieder Schwierigkeiten verursachte.

D&E: Ist das applikationsnahe Studium der Modulationsverfahren möglich? Wie wird Performanz vs. Effizienz gemessen?

NI: Ja. Dank der Flexibilität der LabVIEW-Communications-Software können Anwender verschiedene Modulationsverfahren ausführen und untersuchen. Hierfür lassen sich Leistungs- und Effizienzgrößen festlegen wie zum Beispiel Durchsatz, Spektrumeffizienz (Bit/s/Hz), Bitfehlerrate (Bit Error Rate, BER) und Eb/N0 (SNR pro bit). Die Anwendungs-Frameworks für 802.11 und LTE bieten ebenfalls integrierte Durchsatz- und Effizienzgrößen, die bei WLAN-Verbindungen zur Leistungsmessung von MCS-Indizes (Anm.: Modulation and Coding Scheme) verwendet werden können.

Keysight: Ein Ziel der Systemsimulation ist es doch die Eignung verschiedener Modulationsverfahren für eine Applikation wie bei 5G zu untersuchen. In SystemVUE kann das Modulationsverfahren in Zusammenhang mit der HF-Architektur sowie dem Übertragungskanal in realistischen Szenarien betrachtet werden. In SystemVUE gibt es keinen Stromumsatz. Der entsteht erst im Schaltungsdesign. Dies lässt sich somit in Kopplung zu einem Schaltungssimulator bestimmen.


D&E: Und im MIMO-Entwurf: Ist die Anzahl der strahlbündelnden Antennen einfach modifizierbar?

NI: Ja, insbesondere mit dem LabVIEW Communications MIMO Application Framework, das Erweiterungen von zwei bis auf 128 Antennen und Mehrantennen-Mobilstationen mit bis zu zwölf räumlichen Streams unterstützt. Das MIMO Application Framework ist ein FPGA-basiertes Softwarereferenzdesign, das eine auf LTE basierende Bitübertragungsschicht mit 20-MHz-TDD-Streaming-Uplink und -Downlink über eine Funkschnittstelle in Echtzeit bereitstellt.

Keysight: Das steuert prinzipiell nur ein Parameter: von 2 × 2 auf 4 × 4 umstellen geht unmittelbar, weiteres ist eine Frage der Detailtiefe.


D&E: Auf welchen Ebenen können Front-End-Komponenten, wie digitale Kommunikation, analoge Kommunikation und Logik-Komponenten entwickelt werden?

NI: Auch wenn das Entwickeln neuer Front-End-Komponenten natürlich wichtig ist, ist LabVIEW Communications nicht für den Entwurf von HF-Front-End-Komponenten ausgelegt. Für das Komponentendesign werden EDA-Tools (Electronic Design Automation) eingesetzt. Verstärker, Filter, Antennen, Oszillatoren und andere Komponenten lassen sich beispielsweise mit Tools wie Microwave Office (Anm.: Teil dee NI AWR Design Environment [2]) entwickeln.

Keysight: In SystemVUE auf einer abstrakten Verhaltensebene – Algorithmen. Einfache passive, analoge Netzwerke und Logikschaltungen ließen sich zwar direkt in SystemVUE entwickeln. Das ist aber wenig spannend. In der digitalen Signalverarbeitung kommt man bis zur Fixed-Point-Darstellung.

D&E: Die Simulationszeit für ein generisches Receiver/Transceiver-Modell?

NI: Da LabVIEW Communications für die Prototypenerstellung mit echter Hardware gedacht ist, gibt es keinen typischen Zeitpunkt für eine Simulation.  Ein klassischer LTE-basierter Prototyp, einschließlich Verarbeitungszeiten und Latenz für die Codierung und Decodierung der Uplink- und Downlink-Verbindung, wird in diesem detaillierten Whitepaper zu LabVIEW Communications beschrieben [4]. Im ungünstigsten Fall – bei der maximalen Anzahl an Ressourcenblöcken (100) und dem höchsten MCS-Index (28) – liegt die Latenz des LTE-PxSCH-Kanal-Encoders bei 0,8 ms und die des LTE-PxSCH-Kanal-Decoders bei 0,94 ms.

Keysight: Das hängt stark davon ab, was Sie messen wollen. Spektrale Messungen (Anm.: Power, CCDF, ACPR...) fordern nur wenige Sekunden, BER bei einem generischen Modell unter einer Minute.

D&E: Wie wird ein Design verifiziert und getestet? Insbesondere neue Modulationsverfahren (Anm.: FBMC, UFMC, GFDM), MIMO-Antennenfelder und Strahlbündelung, mm-Wellentechnik oder fortschrittliche Receiverarchitekturen?

NI: Es wurden bereits einige Testbeds für neue Modulationsverfahren, MIMO-Arrays und mm-Wellen-Technologien mithilfe von LabVIEW Communications entwickelt. So hat beispielsweise die TU Dresden mit LabVIEW Communications ein Testbed für GFDM erstellt, um das Modulationsverfahren mit OFDM zu vergleichen. Mithilfe von LabVIEW Communications konnten sie die nötigen Erweiterungen für OFDM entwickeln – einschließlich Impulsformungsfilter für jeden Unterträger, um den Leistungswirkungsgrad zu optimieren –  und anschließend die Leistung durch die Übertragung der Signale zwischen USRP-SDR-Geräten testen.
Im Bereich Massive-MIMO haben die Universitäten Bristol und Lund ein Testbed entwickelt und damit sogar den Weltrekord bei der spektralen Effizienz aufgestellt. Seitdem wurden mit dem Testbed weitere Tests – in Zusammenarbeit mit British Telecom – im Adastral Park in Suffolk durchgeführt, um räumliches Multiplexing und das Verhalten von Massive-MIMO-Funkkanälen unter mobilen Bedingungen zu untersuchen.

Keysight: Wir können als Beispiel wieder den Transceiver nehmen. Das hängt in diesem Fall vom Schaltungssimulator ab. Unsere Werkzeuge ADS/GoldenGate verfügen über entsprechende Verfahren. Das Modulationsverfahren erhöht die Simulationszeit nicht wirklich dramatisch. Wir sprechen immer noch von Sekunden für EVM et cetera und Minutenbereich für BER und Throughput. Damit ist aber bereits die gesamte Kette enthalten. Ich hatte schon einen Fall, in dem SystemVUE zum virtuellen Drivetest zur Throughput-Verifikation seines LTE-Front-Ends durchgeführt hat. Da lief der Simulator Position für Position zwar insgesamt 2,5 Tage. Der Aufwand war aber im Gegensatz zum realen Fahrzeugexperiment mit Ausrüstung mehr als vertretbar.

D&E: Wie steht es um Softwaretests für BER oder EMV, ACPs? Wie funktioniert die Schnittstelle zu Hardwaretests – zum Beispiel zu Spektrumanalysatoren oder SDR-Plattformen?

NI: Wie bereits bei der Frage zur Leistung versus Effizienz erwähnt, lassen sich in LabVIEW Communications BER-Messungen durchführen. Die Software ist jedoch nicht für Gerätetests wie zum Beispiel EMV konzipiert. LabVIEW Communications unterstützt die Prototypenerstellung von Kommunikationssystemen und ermöglicht in Verbindung mit SDR-Plattformen den Aufbau echtzeitfähiger Prototypen und Testbeds für Funksignale.

Es ist nicht für die Anbindung an automatisierte Testgeräte und somit auch nicht für Hardwaretests bestimmt. Für Hardwaretests empfehlen wir Messtechnik wie zum Beispiel die modularen Messgeräte der PXI-Plattform, die mit Umgebungen wie LabVIEW und Treibersets wie NI-RFmx programmiert werden können.

Keysight: In SystemVUE gibt eine spezielle Instrumentenbibliothek. Daraus lassen sich entsprechende Senken/Quellen instanzieren, die dann direkt mit den Instrumenten kommunizieren. In der Regel reicht dazu einfach die LAN-IP. In den Speicher der Signalgeneratoren werden die Signalsamples geschrieben und diese auf Wunsch bei der gewählten Trägerfrequenz auch gleich gestartet.

Auf der Analyseseite nutzt man zum Einlesen der Signale meistens die VSA-Software mit ihrer Unterstützung für eine Vielzahl von Instrumenten vom High-End 110-GHz-SA, über das 1-GHz Feld-Wald-und-Wiesen-Scope bis hin zum Logic-Analyzer für die einzelenen Bits. Ich persönlich favorisiere in diesem Zusammenhang unsere modularen PXI-Lösungen. Da hat man gleich Signalgenerator und Analyse in einer Box.

D&E: Wie übersichtlich werden dabei LTE-Parametrierungen gehandhabt?

NI: Im LTE-Application-Framework werden die unterstützten physischen Kanäle und Signale generell in Übereinstimmung mit den Spezifikationen des LTE-Release 10 von 3GPP (Anm.: im speziellen 3GPP TS36.211, TS36.212 und TS36.213) implementiert. Spezifische Abweichungen, Erweiterungen, Vereinfachungen oder Konfigurationseinschränkungen beschreibt unser Whitepaper [3].

Keysight: Signal-Setup und Analyse erfolgen ganz ähnlich und komfortabel wie in der Messgeräte Software. Auch die Darstellung der Ergebnisse ist vergleichbar. Optional lässt sich sogar die Messgerätesoftware, insbesondere die VSA-Software, direkt aus dem SystemVUE starten und Sie arbeiten als ob Sie am Messgerät sitzen.

D&E: Wie gestaltet sich der Arbeitsfluss bei FPGA- und SoC-basierten Plattformen? Ist eine Konversion zu unterschiedlichen Plattformen möglich?

NI: LabVIEW Communications kann mit SDR-Hardware von NI integriert werden und bietet eine durchgängige Entwicklungsumgebung, mit der Programmcode sowohl für Prozessor- als auch für FPGA-Hardware bereitgestellt werden kann. Sie lässt sich auf mehrere SDR-Systeme skalieren, sodass mit einem einzigen Designtool eine komplette Prototypenlösung definiert und verwaltet werden kann, einschließlich der schnellen Bereitstellung neuer Algorithmen auf Hardware. LabVIEW Communications unterstützt verschiedene Ansätze für die Definierung von Algorithmen auf dem Prozessor und dem FPGA. Um den Wechsel von vorhandenen Entwicklungswerkzeugen zu erleichtern, bietet LabVIEW Communications Textknoten mit Syntaxhervorhebung, Funktionsvervollständigung, Funktionsdokumentation und anderem für C und .m.

Darüber hinaus können Entwickler ohne viel Aufwand bestehenden Programmcode einbinden, um Prototypen noch schneller zu erstellen.

Keysight: Aufgrund der breiten Anwenderschar und den relativ offenen Designumgebungen ist die FPGA-Anbindung sehr viel einfacher zugänglich. Aus SystemVUE kann man direkt in die Werkzeuge von Xilinx und Altera wechseln.

Von Xilinx können Sie direkt IP aus dem CoreGen ins SystemVUE-Design einfügen und Sie können ausgewählte Evalboards als HiL wieder in die Simulation hängen. Auch kann man Code direkt in unsere FPGA-Plattformen in den AWGs und Digitizern implementieren. ASIC-basierende SoC-Flows sind in der Regel sehr kundenspezifisch und proprietär, mit einer dedizierten Kombination aus Werkzeugen und Prozessen. Wir haben im Kundenauftrag individuelle Einbindungen von SystemVUE in deren SoC-Flow erstellt. In der Verifikation ist SystemVUE die Plattform eigentlich egal. Die schaltungstechnische Implementierung ist immer Aufgabe der spezifischen Werkzeuge. Hat man HDL-Code, ist der Wechsel zwischen FPGA-Plattformen relativ einfach: im SystemVUE das andere Device wählen und wieder in die FPGA-Umgebung wechseln.