Hallo,
wie der Name des Betrags erahnend lässt, würde ich gerne mein Projekt
mithilfe des TTD-Verfahren entwickeln. Im Embedded-Bereich ist diese
jedoch nicht immer ganz einfach, deswegen habe ich einige Fragen zu dem
Thema sowie auch zur Toolchain.
Anstoß dazu gab folgendes Buch: Test Driven Development for Embedded C
Meine Umgebung sieht wie folgt aus:
Basis ist das zc706 Eval Board von Xilinx.
Als OS soll das im SDK 2016.2 mitgelieferte freeRTOS verwendet werden.
So viel zur Basis:
In dem Buch und im Netz habe ich Unity bzw. Ceedling als Test-Framework
gefunden, welches den Anforderungen entsprechen sollte.
Wie sind da die Erfahrungen?
Ist Unity mit dem Vivado/SDK kompatibel?
Wie wäre hier der Ablauf? Muss der JTAG-Debugger mit dem Device
verbunden sein, um die Tests auf dem Board zu durchlaufen, um dann die
Resultate des Testruns zu bekommen.
Mir würde als erster Schritt ausreichen die Testresultate im
Konsolenfenster (über das Serial-Interface) zu sehen.
Wo liegen die Grenzen des Testens mit diesem Framework? Einzelne
Methoden lassen sich sicher wie in anderen Frameworks (z. B. JUnit im
Java Bereich oder BOOST) mit Resultat und Erwartungswert abgleichen.
Aber wie sieht es aus, wenn Betriebssystem Funktionalitäten ins Spiel
kommen (Deadlocks, Race-Conditions, usw.).
Ist es im allgemeinen mögliche Interrupt-Verhalten strukturiert zu
testen?
Danke im Voraus für die Anregungen.
Andre
Leider kann ich dir keine selber erlebten Erfahrungen weitergeben, würde
aber gerne bei der Arbeit TDD mit dem Zynq machen. Bin also froh, wenn
sich dem jemand annimmt :-)
StoneA schrieb:> Wie wäre hier der Ablauf? Muss der JTAG-Debugger mit dem Device> verbunden sein, um die Tests auf dem Board zu durchlaufen, um dann die> Resultate des Testruns zu bekommen.
Idealerweise bist du in der Lage, deine kompletten Unit Tests ohne reale
Hardware durchlaufen zu lassen. Dann brauchst du weder Board oder
JTAG-Debugger.
Der Vorteil ist, dass die ganze Testerei, so wie üblich, auf einem
separaten automatisierten Buildserver laufen kann.
Damit das so weit kommen kann, braucht es mehrere Elemente.
Zum einen musst du deine Zynq Software ausführen können, das geht mit
einem Emulator wie QEMU. Eine kurze Suche brachte dazu sogar ein kurzes
Tutorial von Xilinx zu Tage:
http://www.wiki.xilinx.com/Testing+FreeRTOS+on+Zynq+QEMU
QEMU emuliert aber nur den CPU Kern und nur die wenigste Peripherie
(Kenne den Stand nicht, was dabei ist und was nicht). Also muss
sichergestellt sein, dass der zu testende Code so abstrahiert ist, dass
keine (simulierte) Peripherie benötigt wird für den Test. Wenn das nicht
geht muss für die benötigte Peripherie ein Simulationsmodel erstellt
werden und in QEMU eingebunden werden.
Also je weiter weg der zu testende Code von der Hardware ist, je
einfacher geht das. Benutzerinterfaces, Software Protokolle zu anderen
Systemen, Datenaustausch und Libraries dazu können so entwickelt und
getestet werden ohne Board.
Bootloader und low-level Treiber gehen so gut wie nicht.
Richtig cool wird es dann, wenn das selbe Testsystem nicht nur mit
Emulation läuft, sondern wahlweise auch per JTAG-Debugger und serieller
Schnittstelle mit einem realen Board.
Die SW Entwickler/Build Server arbeiten dann oft ohne Board bzw.
entwickeln schon Monate bevor überhaubt ein Board gebaut wurde. Sobald
dann Boards da sind können dann die Hardware Entwickler und Tester
verifizieren ob beide Welten zusammenpassen.
> Mir würde als erster Schritt ausreichen die Testresultate im> Konsolenfenster (über das Serial-Interface) zu sehen.
Das ist bei Embedded Systemen üblich das Serial-Interface für solche
Ausgaben zu nutzen. Es ist in jeder HW vorhanden und oft frei von
Datentransfer der eigentlichen Applikation.
Serial-Interface ist auch in der Emulation oft drin.
> Wo liegen die Grenzen des Testens mit diesem Framework? Einzelne> Methoden lassen sich sicher wie in anderen Frameworks (z. B. JUnit im> Java Bereich oder BOOST) mit Resultat und Erwartungswert abgleichen.> Aber wie sieht es aus, wenn Betriebssystem Funktionalitäten ins Spiel> kommen (Deadlocks, Race-Conditions, usw.).
Im Prinzip möglich, dass du solche Probleme siehst, da das OS ja
unverändert läuft.
Deadlocks etc. treten aber oft in Zusammenhang mit Peripherie oder
externer Hardware auf, da ist die Methode limitiert auf die genutzten
Simulationsmodelle und deren Fähigkeiten.
Vorteil ist natürlich, dass bestimmte Extrem- oder Fehlerzustände in der
Simulation einfacher herbeigeführt werden können als mit realer
Peripherie.
Wenn meine Hinweise gerade kompliziert oder nach viel Aufwand tönen,
nicht abschrecken lassen. Ausprobieren wie weit du kommst.
Der initiale Aufwand kann schon recht hoch sein aber die Idee ist ja,
dass alle zukünftigen Projekte auch nach dieser Methode entickelt
werden, sich der Aufwand also mit jedem neuen Projekt zurückzahlt.
Es ist auch normal, dass nicht beim ersten Projekt alle Aspekte und
Wünsche eingebaut werden. Dazu bekommt kaum jemand das nötige Budget.
Diese Sachen wachsen mit der Zeit, den Ansprüchen und dem was man auf
dem Weg dahin gelernt hat.
Christoph schrieb:> sich der Aufwand also mit jedem neuen Projekt zurückzahlt.
Soweit die Theorie. Die Praxis ist leider, dass es so viele Änderungen
von Projekt zu Projekt gibt, dass das Rückzahlen lange dauern kann.
Ferner ist es so, dass sich das absolut nicht in jedem Projekt lohnt.
Daher scheuen viele den overhead und entwickeln dasso knapp, dass es
noch ins Budget passt.
Wenn so ein Invest was werden soll, dann muss eine Firma dafür ein
Budget aufmachen und Leute abstellen, die die Entwickler gezielt
dahingehend beraten und unterstützen. Sie müssen geschult werden,
Vorgehendweisen müssen standardisiert und "genormt" werden. Sie müssen
gepflegt und kommuniziert werden. Das wird eine Selbstläufer, der Kosten
aufwirft.
Nicht jeder Projektleiter ist geneigt, das zu akzeptieren und dafür Geld
auszugeben, nur dafür dass nachher ein anderer PL mit seinen Projekten
sehr schnell durchkommt und sich die Prämien holt.
Der Projektleiter der so ein System erstmals einführt, der legt nälich
schwer drauf, weil die ganze Truppe erstmal in seinem Projekt die ganzen
Anfängerfehler machen muss. Ich persönlich hätte dazu keine Lust.
Projektmanager schrieb:> Wenn so ein Invest was werden soll, dann muss eine Firma dafür ein> Budget aufmachen und Leute abstellen, die die Entwickler gezielt> dahingehend beraten und unterstützen.
Das passiert noch am ehesten in sog. regulierten Märkten wie der
Medizintechnik oder der Avionik. Je nach Risiken sind da 100%
Testcoverage von den Normen gefordert.
Projektmanager schrieb:> Nicht jeder Projektleiter ist geneigt, das zu akzeptieren und dafür Geld> auszugeben, nur dafür dass nachher ein anderer PL mit seinen Projekten> sehr schnell durchkommt und sich die Prämien holt.
Danke für deinen Input aus der Praxis, der sich durchaus deckt mit dem
was ich erlebe und von Kollegen höre.
Unser Weg als Ingenieure in solchen Situationen ist, dass wir in jedem
Projekt neben bei etwas an unserer Vorgehensweise und unseren Tools
rumwerkeln. Führt dazu, dass wir zwar nach vielen Jahren dann dort sind,
wo wir (also mindestens ich und der Projektmanager) hin wollen aber
dazwischen gibt es zig Projekte die alle ihre Eigenheiten haben in den
Tools und der Vorgehensweise, weil eben genau nichts standardisiert und
"genormt" ist.
von Leid und Frameworks geprüfter schrieb:> Wieder mal ein Versuch den "unwissenden FPGA-Ingenieuren" irgendein> Softwerker-Korsett zum Testen überzustülpen, weil ja FPGA auch nur> Software ist.
Das macht in begrenztem Umfang aber durchaus Sinn, weil zwar nicht FPGAs
- aber der Entwicklungsvorgang des FPGAs - eine
Softwareentwicklungstätigkeit ist. Alle für die Softwareentwicklung
verfügbaren Methoden, Tests und Funktionalitäten lassen da anwenden.
Das ändert natürlich nichts an dem Umstand, dass FPGA-Entwicklung
bestimmtes Wissen benötigt, welches sich gänzlich von dem der Windows-
oder embedded-Entwicklung unterscheidet.
Ich frage mich immer, wo man eine gute Grenze zwischen Verifikation und
Implementation zieht. Insbesondere bei Ansätzen wie TDD klingt das nach
"wir schreiben ab sofort nur noch Testbenches".
Bestehen übliche Projekte aus 85% Testbench und 15% Implementation, oder
welche Verhältnisse sind allgemein üblich (und gut)?
S. R. schrieb:> Bestehen übliche Projekte aus 85% Testbench und 15% Implementation, oder> welche Verhältnisse sind allgemein üblich (und gut)?
Bei der FPGA-Entwucklung gibt viel mehr
Nicht-Implementations-Tätigkeiten als Testbench-Erstellung.
Manche Entwickler arbeiten nur mit Debug-Equipment am Target und
schreiben keine einzige Zeile Testbench. Das konkrete Verhältniss
zwiachen Implementierung und "Ans Laufen bringen" ist stark von der
Erfahrungstiefe des Entwicklers abhängig.
Mancher Quereinsteiger schafft garnix, weil er nur vorm Monitorsitzt und
nicht in der Lage ist reale Umstände durch Messung/Testläufe zu
erfassen, alte Hasen haben ihr designan Vorgängerprojekten soweit
entfehlert, das neue Revisionen quasi auf Anhieb laufen.
PS:
Mglw. hat keiner der Programmierer-Quereinsteiger je eine VHDL-Testbench
gesehen und meint jetzt das wäre das gleiche wie in der
Softwareentwicklung.
Ich habe den Threadersteller so verstanden das er TDD für die Software
auf dem ARM-Teil des Zync verwenden will. Vor dem gleichen Problem auf
der Alteraseite stehe ich gerade.
von Leid und Frameworks geprüfter schrieb:> Wieder mal ein Versuch den "unwissenden FPGA-Ingenieuren" irgendein> Softwerker-Korsett zum Testen überzustülpen, weil ja FPGA auch nur> Software ist.
Nur nebenbei: Der TO fragte nach Unittesting von FreeRTOS auf dem
embedded ARM Core im Zynq. Das ist Softwareentwicklung...
Aber zur eigentlichen Bemerkung:
Ich bin selber ein FPGA-Ingenieur und möchte mir selber einen
automatisierten Build- und Testflow auf einem Buildserver überstülpen,
damit ich jeden morgen ein E-Mail habe wenn etwas nach dem letzten
Commit nicht mehr geht.
Derzeit sieht es aber so aus, als wäre die grösste Hürde dahin, die
verfügbaren Lizenzen von Modelsim...
Es geht natürlich nicht, dass irgendwelche, ich nenne sie mal so,
Software-Manager da irgenwas einführen möchten, dass nur aus Buzzwords
besteht.
Wir Entwickler müssen da schon selber unser Wissen und unsere
Bedürfnisse einbringen, sonst wird es in der Praxis nicht genutzt und
ist wie geschrieben für die Tonne.
von Leid und Frameworks geprüfter schrieb:> Ich bin skeptisch, ob diesmal mehr als das x+1. akademische Konzept> rauskommt, dessen praktische Bedeutung nach 0 konvergiert.
In erster Linie bin ich in solchen Sachen faul und gucke mir gerne an,
was bei anderen täglich gut funktioniert und ich nur noch ein bisschen
für mich adaptieren muss. Da ist ein Blick über den Tellerrand nicht
verkehrt (den gibt es auf beide Seiten, zu den Softwareentwicklern aber
auch zu den ASIC Entwicklern).
Blechbieger schrieb:> Vor dem gleichen Problem auf der Alteraseite stehe ich gerade.
Ergänzung: für Linuxanwendungen auf dem ARM-Teil verwende ich
erfolgreich CPPUTEST mit Ausführung der Tests sowohl auf dem Host als
auch auf dem Target. Wo ich noch etwas kämpfe ist NIOS
Baremetal-Anwendungen. Und ich schätze Entwicklung am Linuxkernel bzw.
Linuxtreiber ist für Unittesting nicht zugänglich.
Christoph schrieb:> von Leid und Frameworks geprüfter schrieb:>> Wieder mal ein Versuch den "unwissenden FPGA-Ingenieuren" irgendein>> Softwerker-Korsett zum Testen überzustülpen, weil ja FPGA auch nur>> Software ist.>> Nur nebenbei: Der TO fragte nach Unittesting von FreeRTOS auf dem> embedded ARM Core im Zynq. Das ist Softwareentwicklung...
Schob aber die Anfrage ins FPGA-Forum, wohl weil der ZYNQ als FPGA gilt,
wäre aber, da er ausschließlich auf den µC Anteil fokussiert, m.E. mit
dem µC-Unterforum besser bedient.
Und dann kommt einer mit:
"Das macht in begrenztem Umfang aber durchaus Sinn, weil zwar nicht
FPGAs
- aber der Entwicklungsvorgang des FPGAs - eine
Softwareentwicklungstätigkeit ist. Alle für die Softwareentwicklung
verfügbaren Methoden, Tests und Funktionalitäten lassen da anwenden."
Und bei den typischen FPGA-Designs (alles ausser Zybo/Aria 10) kann man
die angedeudeten Methoden wie JUnit, BOOST, Ceedling, Unity eher nicht
anwenden. testen/Verifikation auf dem FPGA nutz eben einen erweiterten
Satz an Soft- und Hardwaretools die einem Embedded Softwareentwickler
eben nicht zur Verfügung steht.
S. R. schrieb:> Bestehen übliche Projekte aus 85% Testbench und 15% Implementation, oder> welche Verhältnisse sind allgemein üblich (und gut)?
Gut ist, was dich effizient zu einem zuverlässigen System bringt.
Eine Simulation ist gut, weil du den Zustand deines Systems ganz präzise
herstellen kannst, jedesmal. Gut ist sie auch, weil du jedes einzelne
Signal, egal wie tief vergraben im Design, analysieren kannst.
Effizient ist sie, wenn es nur kurze (simulierte) Zeit geht um einen
bestimmten Zustand zu erreichen (System initialisieren, eine
Funktionalität testen, verifizieren).
Testen auf der echten Hardware ist gut, weil du Probleme erkennst, die
erst durch reales Timing entstehen (liegt dann meistens an
fehlenden/falschen Constraints) und ob deine Annahmen über die Umgebung
(andere Chips, Prokokolle etc.) stimmen.
Effizient ist es, weil es möglich ist in sehr kurzer Zeit (verglichen
mit der Simulation) sehr viele repetitive Tests zu machen (Simulation
ist oft nur der Test ob es ein/zwei mal tut, in HW geht auch das Testen
ob es 100'000 mal oder 24h funktioniert).
Ein Trick hierbei kann sein, wenn die FPGA Implementation während der
Entwicklung zusätzliche Hardware beinhaltet, um Daten auf Korrektheit zu
prüfen. So zu sagen einen Teil der Testbench (der Checker) zu
synthetisieren. Im Endprodukt lässt man diesen Overhead dann wieder weg.
In HW erkannte Fehler sind meistens einfacher zu analysieren und zu
beheben, wenn die Simulation so erweitert werden kann, dass genau dieser
Fehler nach kurzer Simulationszeit auftritt. (Das ist dann das nächste
Buzzword DDT – Defect Driven Testing :-) )
Also nachdenken und schlau das beste von beidem kombinieren.
S. R. schrieb:> Bestehen übliche Projekte aus 85% Testbench und 15% Implementation, oder> welche Verhältnisse sind allgemein üblich (und gut)?
Vergessen zu erwähnen: Kommt auch darauf an, wie hoch das Risiko ist die
reale Hardware zu zerstören (und was es dann kostet). Hat hier jemand
Leistungselektronik gesagt? :-) (obwohl es kein Witz ist, explodierende
Leistungselektronik kann dauerhafte Hörschäden verursachen...)
C. A. Rotwang schrieb:> Bei der FPGA-Entwucklung gibt viel mehr> Nicht-Implementations-Tätigkeiten als Testbench-Erstellung.> Manche Entwickler arbeiten nur mit Debug-Equipment am Target und> schreiben keine einzige Zeile Testbench.
Ja, das ist natürlich schon klar, dass Simulation alleine nicht
ausreicht, die Verifikation also auch (oder größtenteils) am Gerät
stattfinden muss.
Ich habe zwar bis zum letzten Jobwechsel mit FPGAs zu tun gehabt, aber
als ziemlicher Anfänger alleine. Inzwischen habe ich damit (zum Glück)
beruflich nichts mehr zu tun. Das bestand halt zu 90% aus Implementieren
und "am Gerät testen" und hat mehr oder weniger schlecht funktioniert.
C. A. Rotwang schrieb:> Mancher Quereinsteiger schafft garnix, weil er nur vorm Monitorsitzt und> nicht in der Lage ist reale Umstände durch Messung/Testläufe zu> erfassen, alte Hasen haben ihr designan Vorgängerprojekten soweit> entfehlert, das neue Revisionen quasi auf Anhieb laufen.
Das klingt, als ob bei euch eher wenig simuliert wird, sondern eher die
Hardware in situ verifiziert wird. Oder lese ich da was falsches rein?
Christoph schrieb:> Gut ist, was dich effizient zu einem zuverlässigen System bringt.> [...]> Also nachdenken und schlau das beste von beidem kombinieren.
Naja, ich wollte halt wissen, wie andere sowas lösen. Irgendwie kriege
ich das auch alles hin, aber es fühlt sich weder effizient noch gut an,
mit Halbwissen irgendwelchen Text zusammenzuprobieren und zu
synthetisieren.
Christoph schrieb:> Kommt auch darauf an, wie hoch das Risiko ist die> reale Hardware zu zerstören (und was es dann kostet).
In Software habe ich für solche Fälle einen Failsafe direkt vor dem
Ausgang (d.h. in der Funktion, die am Ende die Pins setzt), um definitiv
verbotene Zustände zu verhindern und laut ins Log schreit (falls
vorhanden).
Mit gefährlicher Hardware habe ich aber auch nichts zu tun.
Schlimmstenfalls macht es leise "plopp" oder "tickticktick" und ich muss
jemanden mit echt guten Lötfähigkeiten finden... und ein Ersatzmodul.
StoneA schrieb:> Wo liegen die Grenzen des Testens mit diesem Framework? Einzelne> Methoden lassen sich sicher wie in anderen Frameworks (z. B. JUnit im> Java Bereich oder BOOST) mit Resultat und Erwartungswert abgleichen.> Aber wie sieht es aus, wenn Betriebssystem Funktionalitäten ins Spiel> kommen (Deadlocks, Race-Conditions, usw.).> Ist es im allgemeinen mögliche Interrupt-Verhalten strukturiert zu> testen?
Das Stichwort dazu ist Co-Simulation. Da habe ich vor Jahren mal ein
relativ teures Tool von Cadence (möglw. war's Incisive) zu Gesicht
bekommen, wo insbesondere für den Zynq der ARM-Core im Emulator und die
zugehörige HDL im Simulator zusammen simuliert wird, das lief in der
Demonstration ganz ordentlich, insbesondere auch zyklengenaue
Darstellung der Wellenformen bei IRQ-Events.
Da hatte ich mir zu dem Zeitpunkt aber schon was mit ghdl und
C-Erweiterungen gestrickt.
Wenn du das von Hand machen willst, ist qemu schon mal ein guter
Hinweis, wenn du die CPU nicht in der HDL simulieren willst, bzw.
kannst, da für den Normal-Otto die ARM-HDL nicht einfach vom Laster
fällt.
Ich habe schliesslich aus anderen Gründen die ganze CPU auch noch in der
HDL in die Simulation gesteckt, um 'FailSafe' nachzuweisen. Das geht mit
dem ARM aufgrund seiner Komplexität nur bedingt, bzw. je nach
Implementierung gar nicht (Coverage), das würde jetzt aber zu weit
führen.
Mit GHDL und einer einfachen Soft-CPU kannst du schon potentielle
Dead-Locks, TaskSwitching-Verhalten usw. unter div. Testszenarien
ausloten. Dauert halt einfach sehr lange.
Wenn deine HW irgendwie über einen GDB proxy kommunizieren kann, kannst
du auch die funktionierende Referenz (qemu) und die reale HW miteinander
vergleichen, d.h. dasselbe Programm läuft auf Emulation und HW, und wird
durch dasselbe gdb-script im stop'n'go Betrieb mit Breakpoints auf den
beiden Targets verglichen.
Damit erkennst du aber keine fehlerhaften Programme, wie
uninitialisierte Register (sowas rutscht bei manchen Code-Check-Farcen
gnadenlos durch die Lappen), o.ä. - dann kommst du nicht drumrum,
zumindest den IRQ-Controller in HDL vorliegen zu haben.
S. R. schrieb:> C. A. Rotwang schrieb:>> Mancher Quereinsteiger schafft garnix, weil er nur vorm Monitorsitzt und>> nicht in der Lage ist reale Umstände durch Messung/Testläufe zu>> erfassen, alte Hasen haben ihr designan Vorgängerprojekten soweit>> entfehlert, das neue Revisionen quasi auf Anhieb laufen.>> Das klingt, als ob bei euch eher wenig simuliert wird, sondern eher die> Hardware in situ verifiziert wird. Oder lese ich da was falsches rein?
Du liest eher wenig raus. OK es steht nicht explizit drin, das natürlich
auch alle reports von Sythese mapping sta pinreport etc ganau
durchgelesen, verstanden und analysiert worden, alle warnings
abgearbeitet und beseitigt, kritische designteile (Taktübergange)
identifiziert und im Code review paarweise abgecheckt worden, ein style
guide eingehalten wurde und in situ mit jeder menge monitoring
(signaltap, scope) und special test cases (µC basierte User-Emus) lief.
Ansimuliert wurde natürlich auch und für den fall einer brauchts steht
eine funktionierende Simu-umgebung bereit.
S. R. schrieb:> Ich habe zwar bis zum letzten Jobwechsel mit FPGAs zu tun gehabt, aber> als ziemlicher Anfänger alleine. Inzwischen habe ich damit (zum Glück)> beruflich nichts mehr zu tun.
Habe das auch vier Jahre lang alleine gemacht mit ähnlicher Frustration.
Das war für mich der Auslöser um mir eine Firma zu suchen wo wir mehrere
FPGA Entwickler sind um Erfahrungen auszutauschen. Das hat geholfen.
Das Forum hier war auch einer der besten Anlaufstellen.
> Christoph schrieb:>> Kommt auch darauf an, wie hoch das Risiko ist die>> reale Hardware zu zerstören (und was es dann kostet).>> In Software habe ich für solche Fälle einen Failsafe direkt vor dem> Ausgang (d.h. in der Funktion, die am Ende die Pins setzt), um definitiv> verbotene Zustände zu verhindern und laut ins Log schreit (falls> vorhanden).
Ja, sowas ist schlau.
Ich habe solche Failsafes im FPGA gebaut für Leistungselektronik mit 50
kVA, damit die DSP Entwickler machen konnten was sie wollten. Diese
Blöcke habe ich freiwillig über viele Wiederholungen mit randomisierten
Stimuli simuliert :-)
Wenn du diese Failsafe Routine z. B. als Makro (heute besser als inline
function) implementierst, ist das auch gleich ein guter Anker um die
Pinzuweisung von der Hardware zu abstrahieren. Auf dem Target und in der
Testumgebung musst du nur diese eine Routine wechseln (#ifdef...) um die
Pins zu setzen oder ein Log zu schreiben und einen Checker zu füttern.
