Forum: FPGA, VHDL & Co. Maturität von Vivado


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
2 lesenswert
nicht lesenswert
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?

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Zorg (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Strubi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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..

von waflija (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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).

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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.

von waflija (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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" :-)

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Was soll "STA" sein?

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Static Time Analysis?

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klakx (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Kucki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Klakx (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
Ja, so sieht es wohl überall aus. Scheint nichts Integriertes zu geben.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
0 lesenswert
nicht lesenswert
Das wird da ohnehin gemacht - der Auditor muss ja zufrieden sein.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Wasserkopf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.