Ich bin Projektmanager für Software in der Medizintechnik und habe unter anderem die Aufgabe, die tool chain auf Nachhaltigkeit und Konformität zu prüfen. Das betrifft auch die tools, die in der HW-Entwicklung eingesetzt werden, also Microcontroller- und FPGA-Programmiersoftware. Konkret geht es um das Thema Vivado und Qualifizierung von designs, also Einhaltung von Dokumentationsstandards etc und daher poste ich meine Frage hier im FPGA Unterforum. Dasselbe gilt natürlich auch für die uC-Thematik, allerdings ist das weitgehend geklärt. uCs haben wir ja schon eine Weile im Gebrauch. FPGAs sind in den vergangenen Jahren mehr und mehr in den Fokus gerückt, weil immer mehr Software auf ihnen läuft. Anders, als bei UCs ist aber die HW, auf denen die Programme arbeiten, nicht für sich qualifizierbar, weil sie "weich" ist, wie wir sagen. Will heißen: Es reicht nicht, einmal einen UC zu qualifizieren und sich dann ausschließlich um die SW zu kümmern, sondern die komplette konfigurierte HW muss mitgezogen werden. Die Frage, die sich daher ergibt, ist, wie das die Entwickler handhaben (sollten) und was in dem Bezug die tools anbieten. Was kann konkret eine Software wie Vivado leisten, um Versionierung, Teamwork, Qualifizierung, Test und QM-Konformität sowie Zulassung zu unterstützen? Wie weit ist das System? Aus den bisherigen Diskussionen mit unseren eigenen Entwicklern habe Ich den Eindruck, dass das Vivado zwar in der Lage ist, ganze Recher- und Bussysteme in einen FPGA zu bringen, aber was Stabilität angeht, noch nicht so ausgereift zu sein scheint. Wie ist da die Meinung der Profis?
R. K. schrieb: > Wie ist da die Meinung der Profis? A fool with a tool is still a fool. Meint, Vivado ist nie besser als der Ingenieur der damit arbeitet.
Robert K. schrieb: > Wie weit ist das System? > > Aus den bisherigen Diskussionen mit unseren eigenen Entwicklern habe Ich > den Eindruck, dass das Vivado zwar in der Lage ist, ganze Recher- und > Bussysteme in einen FPGA zu bringen, aber was Stabilität angeht, noch > nicht so ausgereift zu sein scheint. > > Wie ist da die Meinung der Profis? Ist die Frage ob es überhaupt irgendein "ausgereiftes" Tool für moderne FPGAs gibt? Wie "ausgereift" ist denn ISE im Vergleich dazu? Du könntest Dich aber mal zum Thema "FPGAs im Weltraum" umsehen, da gibts ja Rad-Hard FPGAs und die Zuverlässigkeit spielt da auch eine extrem große Rolle, vielleicht hat das da schonmal wer untersucht.
Robert K. schrieb: > Versionierung, Teamwork, Qualifizierung, > Test und QM-Konformität sowie Zulassung zu unterstützen? Das würde ich alles außerhalb von Vivado abdecken. Betrachte Vivado als eine Art Compiler für FPGAs. Euer Compiler für den Mikrocontroller macht ja auch keine Versionierung oder erledigt das Teamwork... Duke
Moin, ich fürchte, jegliche Antworten auf diese Frage sind nicht beweisbar. Das eigentliche Problem unterteilt sich ja ansich so: 1) Ist die HDL vom funktionalen Design/Simulation verifiziert 2) Wird diese HDL auch korrekt von Synth/Mapper/PnR umgesetzt 3) Kann die Post-Place-Timing-Sim entprechend korrekt verifiziert werden Unter dem Motto "traue nie einem einzigen proprietären Tool" checkt man obiges sowieso nochmal mit seiner goldenen Referenz (Lieblingssimulator) gegen. Vivado kann ja auch mal crashen, aber der Robustheit der Logikschaltung muss das nicht unbedingt Abbruch tun. Schlussendlich zählt Testbench/menschliche Sorgfalt/Abdeckung Fehlerszenarien. Wo gerade Xilinx echte Mängel aufweist: 1) Umsetzung des VHDL-Standards (da sind einige üble Sachen "erlaubt", die im Standard nicht gehen 2) Simulation - aber das gehört teilweise auch zu Phänomen (1). Ansonsten schliesse ich Dukes Aussage an. Es gibt vielleicht noch einen Aspekt, der bei grafischen IDEs nervt, und bei dem man sich oft mal mit fast allen Flickwerk-Tools ins Knie schiessen kann: Irgendwo ist mal was nicht up to date und man hat in der Klick-Sequenz mal einen expliziten "force rebuild"-Schritt ausgelassen. Gegen solche Tücken nutzt der geneigte Release-Manager dann ab und an auch mal GNU make..
> Die Frage, die sich daher ergibt, ist, wie das die Entwickler handhaben > (sollten) und was in dem Bezug die tools anbieten. Was kann konkret eine > Software wie Vivado leisten, um Versionierung, Teamwork, Qualifizierung, > Test und QM-Konformität sowie Zulassung zu unterstützen? > > Wie weit ist das System? Vivando ist eine Entwicklungsumgebung. D.h. Man kann damit programmieren, simulieren und compilieren. Zusätzlich kann man einige Qualitätskontrollen vor-ab im Code oder Simulation damit machen. Stabilität des IDE an sich ist ein ganz anderes Thema, wenn die Software an sich zuverlässig arbeitet (gerade der compiler) ist das "nur" ärgerlich wenn man alle 30min seine Arbeit bis zum letzten Speichern verliert. Anders rum ist es deutlich schlimmer. Teamwork kann man nicht von oder durch eine Software erwarten. > > Aus den bisherigen Diskussionen mit unseren eigenen Entwicklern habe Ich > den Eindruck, dass das Vivado zwar in der Lage ist, ganze Recher- und > Bussysteme in einen FPGA zu bringen, aber was Stabilität angeht, noch > nicht so ausgereift zu sein scheint. > > Wie ist da die Meinung der Profis? Ein der "Profis" meint, dass du definitiv ein Teamwork Problem hast. Du fragst "deine Leute", die von deiner Firma eingestellt und bezahlt werden, traust ihnen aber weniger als einem anonymen Forum im Internet. Das lässt tief blicken. - Suchst du nur nach argumenten warum deine Mitarbeiter gegen Ihren Willen mit dieser software arbeiten sollen, oder gibt es eine andere Motivation? Stabilität ist relativ. Nehmen wir Inventor von Autodesk, eine an sich recht ausgereifte Software. Es gibt Zeichner, die erleben einen Absturz jeden Monat. Bei einem Projekt ist mir das Mistding 20-30mal am Tag abgeschmiert und hat micht etliche Stunden gekostet. Wenn deine Leute eine bessere alternative haben, mit der sie gut umgehen können solltest du es dabei lassen. Gerade wenn dort schon Erfahrungen mit "instabilitäten" bei euren(!) Projekten vorliegen. Was nützt dir ein Tool mit tollen Werbeversprechen über angebliche Produktivität, wenn genau deine Leute damit nicht arbeiten können (oder wollen).
Als Bezugnahme zu dem voran gegangenen Absatz: Da wurde jetzt aber viel zuviel hinein interpretiert. Einerseits traue ich unseren Entwicklern, sehr wohl Aussagen zu, was nicht heisst, dass man sich nicht noch weitere Meinungen einholt, andererseits sehe ich nicht, dass wir ein grundsätzliches team work Problem haben. Worin sollte das bitte liegen? Die Frage ist doch mehr, ob eine Software ein Team work, also das gleichzeitige Arbeiten an einem Projekt unterstützt und wie gut es das tut, oder man es alles händisch lösen muss. Zu den "Versprechen": Ja, Sowohl Xilinx als auch Mathworks werden nicht müde, das Team work, model based design und den flow an sich, ihrer Tools in den Vordergrund zu rücken und als Allheilmitel darszustellen. Mir geht es darum eventuelle Gegenpositionen zu eruieren: Strubi hat da einen guten Punkt genannt.
machs einfach: Nimm die Demo und gibt 2-3 Entwicklern ma nen Tag Zeit sich damit zu beschäftigen. (Falls noch nicht geschehen) Danach weiß man relativ schnell ob die Software passt oder nicht. ->Mein Punkt ist: Es gibt nicht die eine "richtige" Software mit der alles besser wird. Das ist eher wie Schuhe, anprobieren und ne Runde drin laufen.
Unsere Entwickler haben bereits bis zu 3 Jahren! Erfahrung. Ich glaube auch nicht, daß es möglich ist, Tools innerhalb von 3 Tagen zu analysieren. :-) Die Schwierigkeit ist aber, daß in jedem Projekt andere Schwerpunkt eistieren. Einmal ist es die Komplexität des Designs, einmal die schiere Arbeitsmenge und einmal der wissenschaftliche Anspruch. Gerade der lässt sich meistens noch am Einfachsten lösen, weil die Umsetzung oft einfach und von einer Person gemacht werden kann, während man Arbeitsmenge auf mehrere Personen splitten muss, die unterschiedliche Arbeitstechniken haben, unterschiedlich in Projekten vorgehen und jeder an einer anderen Ecke anfangen würde, wenn man es nicht koordiniert. Machen wir doch mal einen Fall konkret: Entwickler A arbeitet nur am Toplevel und strukturiert das Design, nimmt neue Komponenten nach road map hinzu und baut die Systematik der mile Stones um. D.h. das Design wächst über 5 mile Stones in einem Jahr stufenförmig bis zum Ende. Entwickler B,C und D kümmern sich nacheinander um die Innereien, arbeiten neue Module rein, arbeiten alte um. Entwickler E und F kümmern sich um den Test und die Verifikation, entwickeln Testbeches, bulit-in-Tests etc. Bei all diesen Aktivitäten ist es nötig, dass mehrere Versionen der Designs gehalten werden müssen, Teile an und abgeschaltet werden können, Teststrukturen eingeblendet und ausgeblendet werden müssen und Testbenches zu bestimmten cases und design parts zugeordnet werden müssen. Kann das die Software? - Wie macht man das Grafisch? Einer der Designer kommt von der Mentor-Ecke und erklärte, dass der HDL-Designer mehrere Instanzen desselben Blockes handhaben kann. Auch ist es möglich, mit eingebettem VHDL, das Umschalten der Entity zu steuern und die Variation des Designs, wie ich es beschrieben habe zu steuern. Soweit bekannt, kann Vivado nichts davon. Wie realisiert man das? Wir kommen ja um das Vivado nicht herum, wenn wir SOPC machen wollen.
waflija schrieb: > machs einfach: Nimm die Demo und gibt 2-3 Entwicklern ma nen Tag > Zeit > sich damit zu beschäftigen. (Falls noch nicht geschehen) Danach weiß man > relativ schnell ob die Software passt oder nicht. > So wird dein Statement auch nicht besser. Das ist nicht "einfach", denn wenn man sich für eine Plattform entscheidet, hat man bzgl. Software keine Wahl. Ueber die Xilinx-Tools wird seit Jahren geschimpft, und es kommt doch immer was irgendwie brauchbares raus. Robert K. schrieb: > Die Frage ist doch mehr, ob eine Software ein Team work, also das > gleichzeitige Arbeiten an einem Projekt unterstützt und wie gut es das > tut, oder man es alles händisch lösen muss. Mal ganz konkret dazu: Mit git, svn, etc. kann man dieses Problem technisch zumindest abhaken. Da braucht es nicht zwingend dedizierte Unterstützung aus der IDE, da gibt es eine menge pfiffiger TCL-Erweiterungen. Dass auch typischerweise eine Person ihr Modul entwickelt und testet, davon gehe ich mal aus. Der Rest ist eine Frage der Entwickler-Philosophie. Der grössere Brocken besteht meiner Meinung nach darin, automatisch nach Aenderungen die Testszenarien durchzuspulen (dass jeder auf einen Blick sieht: Oops, Kollege Nemo hat Komponente Z kaputtgemacht). Da könnte Vivado etwas mehr Plugin-Fähigkeiten anbieten. Vielleicht geht es ja inzwischen, ist bei mir etwas her. Aber oft wird das Problem zentral gelöst (checkin löst Regresstest aus und generiert eine Webseite). Gerade um Code auf kritische Konstrukte zu scannen, bietet GHDL neuerdings nette Features und ist Hersteller-invariant :-)
Strubi schrieb: >checkin löst Regresstest aus und generiert eine Webseite Welches tool unterstützt, lost das? > Gerade um Code auf kritische Konstrukte zu scannen, bietet GHDL > neuerdings nette Features und ist Hersteller-invariant :-) Das hört sich interessant an!
Robert K. schrieb: > Bei all diesen Aktivitäten ist es nötig, dass mehrere Versionen der > Designs gehalten werden müssen, Teile an und abgeschaltet werden können, > Teststrukturen eingeblendet und ausgeblendet werden müssen und > Testbenches zu bestimmten cases und design parts zugeordnet werden > müssen. > > Kann das die Software? - Wie macht man das Grafisch? > Ich glaube, grafisch ist das ein gordischer Knoten. > Einer der Designer kommt von der Mentor-Ecke und erklärte, dass der > HDL-Designer mehrere Instanzen desselben Blockes handhaben kann. Auch > ist es möglich, mit eingebettem VHDL, das Umschalten der Entity zu > steuern und die Variation des Designs, wie ich es beschrieben habe zu > steuern. Soweit bekannt, kann Vivado nichts davon. Wie realisiert man > das? Da habe ich mir lange den Kopf drüber zerbrochen. Herausgekommen ist schliesslich ein Hack, der aber recht zuverlässig über die Jahre funktioniert. Das Problem ist prinzipiell, dass so einige Tools die "if generate"-Konstrukte wie auch configurations ("for x: use entity work.gna") nicht korrekt beherrschen und man sich da übel ins Knie schiessen kann. Da kann man mit cpp tricksen, oder viel Code explizit generieren. Schön innerhalb einer IDE ist das aber alles eben nicht und läuft schlussendlich auf ein Makefile oder TCL-Haken raus. Der Rest ist hier dokumentiert: http://tech.section5.ch/news/?p=370
Puh, jetzt wirds aber rasant.. Robert K. schrieb: > Strubi schrieb: > >>checkin löst Regresstest aus und generiert eine Webseite > Welches tool unterstützt, lost das? > Ich hatte damals Tinderbox für Regresstests genommen. Aber noch unter CVS.. Für die einfachen Regtests habe ich nur ein Shell-Script ("svn hook"), was die Tests durchspult und ein Textfile (PASS/FAIL) ausgibt. >> Gerade um Code auf kritische Konstrukte zu scannen, bietet GHDL >> neuerdings nette Features und ist Hersteller-invariant :-) > > Das hört sich interessant an! Daran wird noch geprototypt, aber so eine konzeptuelle Vorschau gibts hier: http://section5.ch/dclib/xhdl/ Grüner Blob heisst: "Pass" :-)
Robert K. schrieb: >>checkin löst Regresstest aus und generiert eine Webseite > Welches tool unterstützt, lost das? https://de.wikipedia.org/wiki/Kontinuierliche_Integration#Software Such Dir was raus :-)
Robert K. schrieb: > Bei all diesen Aktivitäten ist es nötig, dass mehrere Versionen der > Designs gehalten werden müssen, Teile an und abgeschaltet werden können, > Teststrukturen eingeblendet und ausgeblendet werden müssen und > Testbenches zu bestimmten cases und design parts zugeordnet werden > müssen. > > Kann das die Software? - Wie macht man das Grafisch? > > Einer der Designer kommt von der Mentor-Ecke und erklärte, dass der > HDL-Designer mehrere Instanzen desselben Blockes handhaben kann. Auch > ist es möglich, mit eingebettem VHDL, das Umschalten der Entity zu > steuern und die Variation des Designs, wie ich es beschrieben habe zu > steuern. Soweit bekannt, kann Vivado nichts davon. Wie realisiert man > das? Von dem Vivado-Simulator zur Verifikation sollte man sich schnell trennen. Das möchte ich gar nicht erst erläutern. Dafür gibt es in Vivado tollerweise schon direkten Support für mehrere externe Simulatoren. In ISE konnte man das auch noch händisch übertragen ohne von IP-Versionierung erschlagen zu werden. Für hohe Qualifizierung sollten Coverage-Metriken verwendet werden (Ziel mind. 98%) und immer Regression-Tests nutzen (PASS/FAIL). Anders als in der Software kommt auch noch die STA hinzu. Variationen des Designs kann man mit Generics, Packages, verschiedenen Compilierungsskripten und auch mehreren Projekten abarbeiten. Das geht mit beliebigen Scriptsprachen. Robert K. schrieb: > Entwickler A arbeitet nur am Toplevel und strukturiert das Design, nimmt > neue Komponenten nach road map hinzu und baut die Systematik der mile > Stones um. D.h. das Design wächst über 5 mile Stones in einem Jahr > stufenförmig bis zum Ende. > > Entwickler B,C und D kümmern sich nacheinander um die Innereien, > arbeiten neue Module rein, arbeiten alte um. > > Entwickler E und F kümmern sich um den Test und die Verifikation, > entwickeln Testbeches, bulit-in-Tests etc. Tests nehmen knapp über 50% ein. Mit 4:2 sieht das etwas schief aus.
Die Entwickler arbeiten nicht dauerhaft zu 100% an so einem Projekt und der Code wird auch mehrfach verwendet. Ich verstehe aber, was Du sagen willst. Danke an alle für die Hilfe.
Ja, STA hat sich dafür etabliert.
Die Timinganalyse ist aber nicht so wirklich eine Methode der
Verifizierung. Einmal hinterliegen da nicht validierte Modelle (da nur
vom Hersteller gecheckt) und dann sind die Probleme im Bereich Timing
auch mehr im Bereich Taktdomain, Synchen und den Abläufen im
Zusammenhang mit dem IO-Input.
> Für hohe Qualifizierung sollten Coverage-Metriken
Wenn es ein komplexer Code ist, ist das in der Tat die einzige effektive
Möglichkeit den Schritt von Konzept zur Umsetzung zu prüfen. Wenn man
die erdenklichen Cases alle real abprüfen wollte, wird man kirre.
Zu Vivado ist noch zu sagen, dass das ein Schritt mehr hin ist, zu einer
integrierten Plattform, die es eher verkompliziert, Schritte zu
validieren und abzusichern.
Jürgen S. schrieb: > Die Timinganalyse ist aber nicht so wirklich eine Methode der > Verifizierung. Einmal hinterliegen da nicht validierte Modelle [..] ufff.. Nein? Ich bin der starken Überzeugung das es doch einen nicht unerheblichen Teil der Verifizierung mit einnimmt.
Da kann man geteilter Meinung sein. Bei mir müssen Designs durch die Timinganalsye kommen, das ist eine grundlegende Bedingung. Unter Verifikation verstehe ich aber eher, das die formalen Berechnungen korrekt sind. Duke
Ich denke mal das die Timinganalyse ein notwendiges Kriterium für die Verifikation ist, jedoch kein hinreichendes. Nur weil etwas die Timinganalyse ohne Probleme durchläuft, heißt das jetzt nicht das die Funktionalität gegeben ist. Kucki
Klakx schrieb: > ufff.. Nein? Ich bin der starken Überzeugung das es doch einen nicht > unerheblichen Teil der Verifizierung mit einnimmt. Hm, das kommt davon, wenn man Champions League schaut und gleichzeitig Sinnreiches posten will: Ich wollte eigentlich ausdrücken, dass die STA allein nicht so wirklich reicht, weil sich ein großer Bereich möglicher Disfunktionen an anderen Stellen verbirgt und damit auf das Thema Testen hinaus. Die Timing Analyse sichert eigentlich nur einen Teil der Umsetzung ab, nämlich den, ob das Konzept im gewählten FPGA unter den definierten Randbedingungen takttechnisch überhaupt arbeiten kann. Die Aussage ist schon unsicher, weil die Randbedingungen falsch gegeben sein könnten, oder falsch bekannt sein könnten. Ich denke da an schlecht dokumentierte Chips- Ob es datentechnisch und funktionell korrekt arbeitet, ist nochmal was anderes. Das müssen eigentlich die Testbenches liefern, soweit man die wiederum irgendwie abgesichert hat und zeigen kann, dass sie vollständig abdecken. Duke Scarring schrieb: > Unter Verifikation verstehe ich aber eher, das die formalen Berechnungen > korrekt sind. Hm, der Schritt wurde uns an der Uni als Konzeptvalidierung verkauft. Bzw. - wahrscheinlich meinst Du, ob sie korrekt umgesetzt wurden und ModelSim das bestätigt.(?) Um mal auf den TO konkret einzugehen: Robert K. schrieb: > Software in der Medizintechnik Es gibt meistens eine Art Design- und Prüfkonzept, das in jeder Firma etwas anders gehandhabt wird. Üblich ist eine formelle Teststrategie, die festlegt, welcher Aspekt an welcher Stelle und womit verifiziert wird. Das sind von Außen her funktionelle Tests der geforderten Funktionen und die ausdrücklichen Absicherungen gegen Fehlbedienungen. Das wird manuell oder halbautomatisiert gemacht. Damit kann man das Gesamtgeräte, die Komponenten, Modulkommunikation und indirekt sehr viel "FPGA-internes" mittesten. Die vielen Aspekte, die damit aber nicht erschlagen werden können, müssen eben durch manuell ausgeleitete Testszenarien in Form von Testbenches und besagten Verifikationsschritten durchgeführt werden. Die mathematischen Themen erschlagen viele gerne mit Matlab, soforn es den Aufwand rechtfertigt. Hinzu kommen die elektronischen und physikalischen Themen. Ein richtiges Tool, mit dem man Elektronikvalidierung planen und unterstützen könnte, kenne ich leider nicht. Die tools (und auch Vivado) tun da kaum was.
Das ist doch schon mal eine gute Sammlung von Argumenten. Meine Frage dann: Mit welchen Werkzeugen (Software) arbeitet ihr, um Entwicklung und Test zu koordinieren?
Robert K. schrieb: > Mit welchen Werkzeugen (Software) arbeitet ihr, um Entwicklung und Test > zu koordinieren? Koordination: Verification Plan - Word (Alle Tests erklärt + Pass/Fail) Verification Overview - Excel (Übersicht Pass/Fail der Tests) auf Basis der SVN Revision - SVN Zeitplan/Meeting - MSProject, Excel Deine Entwickler/Tester füttern dich eigentlich mit Pass/Fail Reports. Gegebenenfalls dokumentieren jene diese auch im Verification Plan, falls du das nicht vollziehst. Spezifikation und andere Dinge sollten bekannt sein. Deshalb lass ich diese hier mal ungenannt.
Robert K. schrieb: > Mit welchen Werkzeugen (Software) arbeitet ihr, um Entwicklung und Test > zu koordinieren? Antworten wurden ja ansich schon gegeben. Du müsstest ev. gezielter fragen :-) Schlussendlich ist es eine totale Vertrauensfrage, die ich nicht unbedingt in das hiesige Forum abgeben würde. Sicher sind Fremdmeinungen gut, aber am Schluss musst du ja mit deinen Jungs u. Mädels daran arbeiten. Ich denke es ist insofern auch weniger eine Frage des Was als des Wie. Allerdings gibt es schon eine Kernfrage, die in Unternehmen des öfteren auftaucht: OpenSource/Selbermachen (GPL-Akzeptanz sei dahingestellt...) oder einem ClosedSource-Tool vertrauen. Wir arbeiten hier typischerweise gerne mit Python Scripting/Opensource, da man damit relativ zügig verschiedene Module (VHDL-Simulator, Matlab/Octave, Datenacquisition) miteinander sprechen lassen kann. Per netpp-Bibliothek lassen sich da ganze Cluster für verteilte Simulation bauen, das geht sogar bis aufs FPGA runter (Virtuell und in echt). Siehe auch http://tech.section5.ch/news/?p=378, im Paper finden sich einige Hinweise zur Simulation. Die Schwierigkeit besteht wohl darin, erst mal Vertrauen in ein Tool zu gewinnen ("the working reference") und einen internen Teststandard zu schaffen, der auch einem drittparteilichen Prüfer genehm ist. Wenn derjenige dem Tool nicht vertraut, kommt man mit der besten Toolchain nicht weiter. (In meinem Fall bin ich seit Isim/Vivado gebranntes Kind, entsprechend niedrig das Vertrauen...). Jürgen S. schrieb: > Ein richtiges Tool, mit dem man Elektronikvalidierung planen und > unterstützen könnte, kenne ich leider nicht. Die tools (und auch Vivado) > tun da kaum was. Modelsim, (LT)Spice? Sogar mit TCL kann man Regressionstests bauen...
Kennt sonst jemand eine Software mit der das geht? Bei der Validierung geht es uns vor allem um das Abklappern der Anforderungen und die Sicherstellung auch derjenigen Funktionen, die sich nicht durch ausdrückliche Anforderungen ergeben, sei es aus Gründen der Technik, der Verfügbarkeit, der Umsetzung oder eventueller Einflüsse. Solche Themen werden meines Wissens immer aus einer abstrakten Ebene von Datenbanken heraus gehandhabt, die aber nur ein Minimum dessen beinhalten, was "weiter unten" noch so alles aufschlägt. Nehmen wir mal ein Beispiel: In der RMDB steht sowas wie: 1. Leitungsbrüche sollen erkannt werden und Fehler kompensiert werden 2. EMV-Einflüsse sollen unterdrückt werden 3. etc. Weiter unten hat dies aber Einflüsse auf die Gestaltung z.B. der Platine und der Hardware und damit auch auf den digitalen Teil (also den FPGA) Möglicherweise müssen 50 oder noch mehr Einzelpunkte beachtet werden, wie Rauschfilter, diskreter Filter und Leiterbahnverlegung, Lagenaufbau, Abschirmung und Testfunktion im FPGA, Software im FPGA, Signalverarbeitung Und später muss das alles getestet werden. D.h. eine Anfoderung "oben" erzeugt 10 weitere "unten". Wie wird sichergestellt, daß die alle komplett sind und auch getestet werden? Bzw nachgewiesen dass sie getestet wurden? Beim FPGA und dem Board habe Ich den Schaltplansimulation - einmal digital und einmal analog. Wie werden deren Ergebnisse in die Validierung formell einbezogen?
Robert Kuhn M. schrieb: > Kennt sonst jemand eine Software mit der das geht? > Ich sags mal kurz: es gibt keine Software, die einem die Hausaufgaben automatisch löst. Ansonsten gibt es für die Schaltungstests auf Boards eine Menge ICT-Lösungen (schau dich mal bei Genrad, Goepel, XJTAG, usw. um). Alles zu kriegen, ab 10'000 bis 150'000. Nur den Test und die clevere Fehlerinjektion und das Abhaken der Szenarien (PASS/FAIL) wie oben beschrieben müsst ihr trotzdem selber scripten/programmieren.
Robert Kuhn M. schrieb: > D.h. eine Anfoderung "oben" erzeugt 10 weitere "unten". Wie wird > sichergestellt, daß die alle komplett sind und auch getestet werden? Bzw > nachgewiesen dass sie getestet wurden? Review der angefertigten Dokumente (Testspezifikation und Testreport).
Also es ging ja um ein Programm oder sonstiges tool, um so etwas zu planen. Die Frage wäre, was damit den genau abgedeckt werden soll. Geht es um die Sicherstellung der Durchführung eines Validierungsvorgangs, dann lässt sich das durch die üblichen requirement-Tools leisten. Definieren, Vorgeben, Abhaken. Geht es aber um die Erzeugung der Anforderung, muss eben nachgedacht werden: Programme wie SPICE können nur das simulieren, was ihnen aufgetragen wird. Um das vollständig abzuarbeiten, braucht es eine requirement-Liste, die für jeden Aspekt eine Quellanforderung enthält, also ursprünglich einen elektrischen Betriebsfall und die damit verknüpften Einflüsse. Das sind neben der Gutsimulation auch die Reaktion auf Fehler, was meistens ja irgendwo definiert ist. Für beides braucht es aber auch noch ganz elementare Dinge, wie Spannungstoleranzen, Bauteilfestigkeit, Kosten etc. um jede Entscheidung auf irgendeine Anforderung zurückführen zu können. Wenngleich das praktisch geschieht, macht das formell so gut wie keiner. CAD/CAE-Programme wie die klassischen Layout-tools wiederum haben DRC und ERC die bekannte Regeln abtesten. Diesbezüglich müsste man bei der Planung sicherstellen, dass die Randbedingungen vom Designer gesetzt sind. Die inhaltliche Stimmigkeit, d.h. ob eine Vorgabe letztlich geeignet ist, die Anforderung der gesamten Schaltung zu erfüllen, ist damit aber nicht sichergestellt. Das kann man nur als Vorgabe niederlegen. Das wären dann solche Dinge wie EMV-Abstrahlung (Breiten und Verlauf der Leiterbahnen), Produzierbarkeit der Leiterplatte (Viagrössen, Bohrungen, Kosten), Montierbarkeit (Bauteilhöhen). Auch da werden alle möglichen Anforderungen während der Umsetzung erzeugt und durch den Designer erfüllt, aber so gut wie nie formell formuliert oder geprüft. Dasselbe gilt indirekt für das virtuelle Layouten im FPGA: Da das überwiegend von der Software geleistet wird, müssen eben bei der Test- und Validierungsplanung die für die Applikation gültigen Punkte in der Software gesetzt werden. Das heißt, sie müssen 1) überhaupt gesetzt werden und 2) sie müssen logisch richtig gesetzt werden. Das macht der Programmierer überwiegend aus dem Kopf, dass heißt, er selber stellt sicher, dass er am Programm alles eingestellt hat und wie. Punkt 1 wäre also prüfbar. Punkt 2 bleibt offen. An der Stelle muss man aber sagen, dass mit Bezug zu dem eigentlichen thread-Titel gerade Vivado durchaus mehr tut, als z.B. ISE oder Quartus: Es wird mehr oder weniger zielführend nach fehlenden constraints gesucht und diese auch angezeigt. Dass müsste also bei einer solchen Planung abgehakt werden. Praktisch sieht die Sache aber trotzdem so aus, dass man nicht alles von oben herunter planen kann, sondern aus den Anforderungen ergeben sich beim jeweiligen Umsetzen immer weitere, die an der jeweils neuen Ebene einfließen. Ausgehend von einer funktionellen Beschreibung in Form von Funktionsanweisungen, die man letztlich alle mit den Funktionstests erschlägt, bekommt man in der Regel ein Pflichtenheft für die Software und die Hardware. An der Stelle fließen z.B. die gesamten Physik- und PCB-Themen ein. Die wären also im Schaltungssimulator oder dem EDA-tool mit DRC zu checken. Beide PHs wiederum enthalten Komponenten, die in das FPGA-PH fließen und an der Stelle müssen eben FPGA-Themen rein. Will also heißen: Beim Entwickeln des Testplans kommen von oben nach unten immer neue Details hinzu, die während und nach der Entwicklung von unten nach oben wieder teilweise formell weggeprüft werden, bis am Ende nur noch die funktionellen Randbedingungen und die unten nicht testbaren Punkte existieren, die dann insgesamt in die Funktionsprüfung fließen. Das ist die übliche Testmatrix. Ein tool dafür kenne Ich nicht. Ich verwende Excel. Für jeden Punkt ist dabei definiert, woher er kommt und an welcher Stelle er abgefangen wird. Für ein FPGA steht da z.B. drin, dass eine Leitung je nach Fehlerfall bestimmte Zustände haben muss, weil es eine Anforderung gab, dass es eine Interrupt-Leitung geben muss. Die Korrektheit der Abläufe, die sich aus den use cases ergeben, werden - soweit sinnvoll - im Simulator gezeigt und das Timing als Anforderung an die Synthese übergeben und bleiben auf FPGA-Ebene ungeprüft. Das passiert dann oben mit z.B. der CPU, wenn sie die use cases nachstellt. Interessant ist in dem Fall dann eigentlich nur, Anforderungen an Störsicherheit komplett abzubilden, also zu zeigen, dass alles Erdenkliche entweder durch den Komponententest, den Funktionstest oder die Verifikation abgefangen wird. Ob man dabei nichts übersehen hat, sagt einem aber keine Software :-)
Jürgen S. schrieb: > Ein tool dafür kenne Ich nicht. Ich verwende Excel. Für jeden Punkt ist > dabei definiert, woher er kommt und an welcher Stelle er abgefangen > wird. Der Automotive-Mensch würde das ganze in DOORS reintippen und entsprechende Anforderungen miteinander verknüpfen. Die Anforderungen könnte man noch mit einer Architektur (SysML, UML) verknüpfen (IBM Rhapsody). Zum Schluss anhand der Anforderungen aus DOORS Testfälle generieren und diese wieder in DOORS eintragen und miteinander verknüpfen, damit der Overhead maximal ist. PS: Etwas Selbstironie ist enthalten.
>Zum Schluss anhand der Anforderungen aus DOORS Testfälle generieren
Wie generierst Du denn aus Doors die Testfälle?
Die Funktionen, die ein System können muss, sind ja drin. Macht einen
Eintrag für jede Funktion und jeden Use Case. Soweit mir bekannt, kann
Doors keine mehrdimensionalen Verknüpfungen, um use cases mit Funktionen
zu mischen, um dann allemöglichen Fälle darzustellen. Wir linken immer
einen test case auf einen use case und diesen auf eine Funktion. Die
test cases als solche denken sich die Systementwickler aus.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.