More than an open laboratory – insight into the testing of microelectronics
Roman Willi gab den Gästen einen Einblick in die Welt des Testens von mikroelektronischen Schaltungen. Im Gegensatz zur Arbeit beispielsweise von Software-Dienstleistungsunternehmen, können solche Schaltungen nicht beim Endkunden getestet werden, da dies fatale Folgen haben könnte. Sie müssen gründlich geprüft werden, bevor Sie zum Endkunden kommen.
Willi zeigte in seinem Referat auf, was alles zu einer erfolgreichen Verifikation gehört. Genannt wurden die Process, Voltage and Temperature (PVT) Corner Analysis sowie der Code Coverage Test. Beides sind wesentliche Tests der dynamischen Verifikation. Statische Tests wie der Design Rule Check (DRC) durften selbstverständlich auch nicht fehlen.
Der nächste Schritt in jeder erfolgversprechenden Testkette ist die Validierung, die das Messen der gefertigten Schaltung beinhaltet. Dabei wird das Device Under Test (DUT) in den Messaufbau eingespannt und je nach Test durch Temperaturzyklen thermisch belastet, während die Kennlinien des DUT aufgenommen werden. Hierfür werden z.B. Temperaturschränke, Präzisionsquellenmessgeräte (SMU) und ggf. ASIC-Prober eingesetzt.
Der letzte Testschritt ist der Produktionstest. Mit Hilfe von Stimuli, die in den DUT eingespeist werden, kann die Funktionalität des DUTs überprüft und bestätigt werden. Somit können intakte und defekte mikroelektronische Schaltungen effizient getrennt werden.
Abschliessend wies Roman Willi darauf hin, dass all diese kalibrierten Geräte für die verschiedenen Testschritte ab sofort im neu eröffneten OpenLab@OST zur Verfügung stehen. Das Lab kann ganz- oder halbtags gemietet werden. Bei vertraulichen Projekten ist Diskretion garantiert.
Robotframework used to realize automation in the validation, production test and infrastructure monitoring use cases
Anschliessend gab Franz Haas von der ams International AG den Anwesenden einen Einblick in die Welt des Robotframework (RF), einem Framwork, welches in verschiedenen Testinfrastrukturen eingesetzt werden kann.
Ein grosses Problem beim Schreiben von Testfällen sei, dass die Testbeschreibung oft vom verwendeten Code abweicht. Anhand verschiedener Codeausschnitte demonstrierte er, dass mit Hilfe des RF die Testbeschreibung mit dem Code kombiniert werden kann. Anstelle des herkömmlichen Codes kann eine Programmiermethode gewählt werden, die der englischen Sprache ähnelt. Die Ergebnisse werden schliesslich tabellarisch im Browser angezeigt.
Franz ging auch auf die Problematik ein, dass die Verfügbarkeit und der Kalibrierstatus von Testinfrastrukturen mit herkömmlichen Testwerkzeugen oft nicht oder nur mühsam ermittelt werden kann. Er zeigte uns, dass es durch den Einsatz von RF möglich ist, den Status von Testinfrastrukturen einfach abzufragen und durch Push-Benachrichtigungen via Telegram oder E-Mail über den Status der Infrastruktur informiert zu werden.
Schliesslich zeigte Haas auf, wie einfach es ist, RF in eine bereits bestehende Testumgebung zu integrieren, dank der zahlreichen verfügbaren Schnittstellen wie Python, C, aber auch LabView und andere.