DO-254 Compliance

RTCA/DO-254 ist eine Konformitätsvorschrift für die Entwicklung von luftgestützter elektronischer Hardware mit FPGAs, PLDs und ASICs. Das Design und die Verifizierung von FPGAs gemäß den DO-254-Richtlinien ist ein anspruchsvolles Unterfangen und erfordert spezielle Funktionen und Fähigkeiten von Design-, Simulations- und Hardware-Verifizierungstools. Die Federal Aviation Administration (FAA) und andere internationale Zertifizierungsbehörden erkennen die Verwendung gängiger Tools für FPGA-Design und -Verifikation wie RTL-Simulator, Synthese, Place & Route und statische Timing-Analyse an. Für DAL A- und B-FPGAs erkennt die FAA auch andere Tools an, die das Design, die Verifizierung, die Rückverfolgbarkeit und das Projektmanagement verbessern, darunter Anforderungsmanagement, Rückverfolgbarkeit, Testmanagement, Design Rule Checker, Clock Domain Crossings (CDC)-Analyse, Code Coverage und FPGA Physical Test Systems.

Die spezialisierten Tools von Aldec für die Entwicklung und Verifizierung von FPGAs steigern die Produktivität und helfen Antragstellern, die DO-254-Konformität zu erreichen: Spec-TRACER, ALINT-PRO, Active-HDL und DO-254/CTS. Die Tools von Aldec wurden von mehreren großen Avionikunternehmen implementiert und eingesetzt, von den Zertifizierungsbehörden akzeptiert und verkürzen nachweislich die FPGA-Design- und Verifikationszyklen von Monaten auf Wochen.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

HDL Coding Standards

HDL-Codierungsstandards (sicherheitskritische Entwürfe)

Um zu verhindern, dass potenziell unsichere Eigenschaften des HDL-Codes zu unsicheren Entwurfsproblemen führen, ist die Verwendung von HDL-Codierungsstandards in verschiedenen sicherheitskritischen Branchen wie DO-254 erforderlich. Die HDL-Codierungsstandards müssen definiert, überprüft und dokumentiert werden. ALINT-PRO™ ist ein vollautomatischer Design Rule Checker, der mit industrieerprobten VHDL/Verilog-Standards ausgestattet ist und eine automatische Codeüberprüfung ermöglicht. Die enthaltenen VHDL/Verilog-Standards decken wesentliche Bereiche der HDL-Kodierung ab, wie z. B. Kodierungsstil, Lesbarkeit, Simulation, Takt-/Reset-Verwaltung, Design-Wiederverwendung, Kodierung für sichere Synthese und Implementierung, Clock Domain Crossings (CDC) und Design for Test (DFT).

Es ist nicht möglich, alle Entwurfsanforderungen nur mit HDL-Code zu spezifizieren. Das SDC-Format wird für die Beschreibung verschiedener Anforderungen verwendet, und ALINT-PRO unterstützt eine wesentliche Teilmenge der SDC-Befehle für genauere Linting-Ergebnisse. Darüber hinaus stellen der Mechanismus für Einschränkungen auf Blockebene und die eingebauten Herstellerbibliotheken sicher, dass auch Entwürfe mit Black-Boxes für eine vollständige Analyse vollständig eingeschränkt sind.

ALINT-PRO™ bietet auch zuverlässige Dokumentationsfunktionen, die für die Berichterstattung, Audits und Überprüfungen von Vorteil sind. ALINT-PRO™ verfügt über einen Violation Viewer für erkannte Verstöße und einen Waivers-Mechanismus, der es ermöglicht, „irrelevante“ Verstöße mit den entsprechenden Rechtfertigungskommentaren zu verknüpfen. Durch die enge Integration mit den Schnittstellen für die Analyse und das Reporting von Verstößen gegen den Kodierungsstandard ermöglichen diese Funktionen ein Reporting auf Knopfdruck und erleichtern die wünschenswerte Erstellung hochwertiger Design-Artefakte, die für die Einhaltung der in den verschiedenen sicherheitskritischen Design-Assurance-Standards festgelegten Anforderungen unerlässlich sind.

HDL Coding Standards

Darüber hinaus können Clock Domain Crossing-Probleme wie unsynchronisierte CDC-Transfers, Konvergenz/Divergenz, kombinatorische Logik auf CDC-Pfaden und falsche Synchronizer-Strukturen, die während des Linting-Prozesses erkannt wurden, mit Hilfe spezieller Fenster wie CDC Viewer, CDC Schematic und RTL Schematic leicht untersucht werden.

Nutzen & Vorteile:

  • Reduziert die Kosten für die Überprüfung im Vergleich zu manueller Arbeit
  • Basiert auf einer umfassenden Wissensbasis von Best Practices der Branche und Design-Expertise
  • Der Code ist konsistenter und effizienter als beim manuellen Review-Ansatz
  • Reviews können häufiger durchgeführt werden, was gut zur DO-254-Philosophie passt
  • Integrierte Debug-Umgebung für effiziente Designanalyse und -dokumentation

Tool Assessment und Qualifikations Prozess

Der Zweck der Toolbewertung und -qualifizierung in DO-254 besteht darin, sicherzustellen, dass das Werkzeug in der Lage ist, die jeweilige Entwurfs- oder Verifizierungsaktivität mit einem akzeptablen Vertrauensniveau durchzuführen, für die das Werkzeug verwendet werden soll. Vor der Verwendung von Werkzeugen in DO-254 für Entwurfs- und Verifikationsaktivitäten sollte eine Werkzeugbewertung durchgeführt und, falls erforderlich, eine grundlegende Werkzeugqualifizierung dokumentiert und aufgezeichnet werden.

Aldec hat die erforderliche Sorgfalt walten lassen, um seine Werkzeuge gemäß dem in RTCA/DO-254 Abschnitt 11.4 Tool Assessment and Qualification Process definierten strengen Prozess zu testen. Wann immer es möglich ist, empfiehlt Aldec eine manuelle Überprüfung der Prüfergebnisse, um eine unabhängige Bewertung zu gewährleisten. Wenn eine manuelle Überprüfung nicht möglich ist, bietet Aldec spezielle Tool Qualification Data Packages für bestimmte Aldec DO-254 Tools an.

DO-254 Independent Assessment

DO-254/CTS™ Datenpaket zur Werkzeugqualifizierung

Enthält ein umfassendes Datenpaket für die Werkzeugqualifizierung, das der Antragsteller leicht an seine Lebenszyklusdaten anpassen kann. Dieses Datenpaket wird für FPGAs der Design Assurance Level (DAL) A und B empfohlen, bei denen das Vertrauen in die automatischen Fähigkeiten des Werkzeugs entscheidend für den Test des Ziel-FPGAs ist. Das Datenpaket umfasst folgende Punkte:

Werkzeugqualifizierungsplan

Der Werkzeugqualifizierungsplan soll zeigen, dass DO-254/CTS sich wie erwartet verhält und keine Designfehler mit einem akzeptablen Zuverlässigkeitsgrad erkennt. Die DO-254/CTS-Komponenten wie die kundenspezifische CVT-Software, die kundenspezifische Tochterplatine und die COTS-Mutterplatine werden unter Verwendung des von Aldec bereitgestellten Diagnosedesigns rigoros getestet. Das Diagnosedesign ahmt den zu prüfenden Kundenentwurf (DUT) in Bezug auf die E/A-Schnittstelle und die Taktung nach.

Betriebliche Anforderungen an das Werkzeug

Spezifische betriebliche und funktionale Anforderungen an das Werkzeug wurden erfasst und in 5 Kategorien eingeteilt: Information, Diagnostik, Konfiguration, Fehlererkennung und Vergleich.

Testplan für das Werkzeug

Es wurden Testfälle zur Überprüfung der spezifischen Werkzeuganforderungen erfasst. Jeder Testfall enthält eine Testbeschreibung, ein Testverfahren, einen VHDL-Entwurf, Testskripte, Eingabedateien und erwartete Ergebnisse. Jeder Test kann vom Kunden in seinem Labor unter Verwendung der mitgelieferten Testskripte wiederholt werden.

Tool Qualification Accomplishment Summary

Dokumentation der Testergebnisse zur Feststellung, ob die Testfälle bestanden oder nicht bestanden wurden, einschließlich der Rückverfolgbarkeitsmatrix zwischen Tool-Anforderungen, Testfällen und Testergebnissen. Dazu gehören auch Berichte über die Review-Aktivitäten für Tool-Anforderungen, Tool-Testfälle und Testergebnisse. Die Überprüfungen werden von Aldec-Mitarbeitern anhand einer Checkliste durchgeführt.

ALINT-PRO™ Design Rule Checker Tool-Qualifizierungspaket

Das anpassbare Tool Qualification Package enthält die umfassende Testsuite und Dokumentation, die erforderlich sind, um nachzuweisen, dass sich die in ALINT-PRO™ verfügbaren Design Rule Checker wie für ein Anwenderprojekt vorgesehen verhalten. Dieses Paket wird für Projekte mit Design Assurance Level (DAL) A und B empfohlen, bei denen ALINT-PRO™ zur Durchsetzung des HDL-Codierungsstandards verwendet wird. Das Qualifizierungspaket enthält:

Qualification Test Suite einschließlich HDL-Quelldateien, Skripte und Patterns, die erforderlich sind, um zu überprüfen, ob das ALINT-PRO™-Tool Verletzungen der Design Rule korrekt erkennt. Die Testsuite deckt alle ALINT-PRO™-Regeln ab, die der Benutzer für sein Projekt ausgewählt hat. Jeder Regelprüfer wird isoliert von anderen Prüfern anhand von positiven und negativen Fällen verifiziert.
Der Benutzer kann die Testsuite in der gewünschten Umgebung ausführen, um den Abschlussbericht zu erhalten, der das korrekte Verhalten des Tools bestätigt.
Qualifizierungsdokument, das die Werkzeugbeschreibung, die Betriebsanforderungen des Werkzeugs, den Qualifizierungstestplan zusammen mit den Testbeschreibungen, die Ergebnisse der Qualifizierungstests und die Rückverfolgbarkeit zwischen den Standardanforderungen des Benutzers und den ALINT-PRO™ Linting-Regeln enthält.

Active-HDL™ und Riviera-PRO™ Code Coverage Tool Qualification Data Package

Derzeit besagt die in RTCA/DO-254 Abschnitt 11.4.1 #4 beschriebene Anleitung, dass bei Verwendung des Code Coverage Tools zur Erfüllung der Elementaranalyse keine Tool-Qualifizierung erforderlich ist. Einige Zertifizierungsbehörden haben jedoch verlangt, dass Code Coverage für bestimmte DO-254-Programme qualifiziert werden muss. Aldec hat daher die nötige Sorgfalt walten lassen, um Active-HDL™ und Riviera-PRO™ Code Coverage im Rahmen des strengen Werkzeugqualifizierungsprozesses zu testen, der in RTCA/DO-254 Abschnitt 11.4 definiert ist. Die für den Test der Code Coverage generierten Anforderungen basieren auf den ausführbaren Konstrukten des VHDL Language Reference Manual (LRM) aus den Kapiteln 4, 10 und 11 des IEEE Std 1076™-2008 VHDL LRM. Aldec stellt ein Datenpaket zur Verfügung, das VHDL-Testfälle und eine umfangreiche Dokumentation mit der Werkzeugbeschreibung, den Betriebsanforderungen für das Werkzeug, dem Qualifikationstestplan mit den Testbeschreibungen und den Ergebnissen des Qualifikationstests enthält. Das Qualifizierungspaket beweist, dass das in Active-HDL™ und Riviera-PRO™ verfügbare Code Coverage Tool genaue Verzweigungs- und Anweisungsabdeckungsmetriken anzeigt.

Unabhängige Tool-Bewertung von HDL-Simulatoren

HDL-Simulatoren wie Active-HDL, Riviera-PRO und andere HDL-Simulatoren von Drittanbietern können von DO-254/CTS unabhängig bewertet werden. Da die Testbench aus der RTL-Simulation von DO-254/CTS als Testvektoren während des physikalischen FPGA-Tests wiederverwendet werden kann, lassen sich die Ergebnisse des physikalischen Tests und der RTL-Simulation leicht zuordnen und abgleichen.

In-Target-Tests auf FPGA-Ebene

In Übereinstimmung mit RTCA/DO-254 und FAA AC 20-152 müssen die Anforderungen auf FPGA/PLD-Ebene verifiziert werden, um die Vollständigkeit der Tests zu gewährleisten. DO-254/CTS™ ist eine vollständig angepasste Hardware, die eine Verifizierung auf FPGA-Ebene für das Zielgerät ermöglicht. Der Ziel-FPGA-Baustein ist in einem kundenspezifischen Board isoliert, das durch die mit voller Geschwindigkeit laufende Simulationstestbench stimuliert wird. Dies ermöglicht einen umfassenden und automatisierten Funktionstest für alle FPGA-Level-Anforderungen in einer einzigen Umgebung.

Target Device Testing und At-Speed-Tests

Dieses Tool besteht aus einer benutzerdefinierten Hardware, die die spezifische Familie/Gehäuse- oder Teilenummer des FPGA/PLD-Bausteins von Anbietern wie Altera, Microsemi (Actel) und Xilinx enthält. Es ermöglicht das Streaming von Testvektoren durch die FPGA-Eingänge mit der erforderlichen Betriebsgeschwindigkeit unter Verwendung von realen Taktfrequenzen von über 250 MHz. Wenn die erforderliche Simulationszeit 500 ms beträgt, werden die Hardwaretests innerhalb von 500 ms abgeschlossen. Zusätzliche Funktionen zur Variation der Frequenz und der Spannung auf +-10% können ebenfalls für die Robustheit genutzt werden.

Automatische Generierung von Testvektoren für Hardwaretests

Die Entwicklung von Testvektoren für Hardwaretests für ein durchschnittliches Level-A/B-Design erfordert normalerweise 6-12 Monate manuelle Entwicklungszeit. Dieses Tool ist mit einem Dienstprogramm ausgestattet, das die Testbench innerhalb von Minuten in Testvektoren für die Hardwaretests umwandelt. Auf diese Weise wird sichergestellt, dass dieselben Anforderungen, die in der RTL-Simulation verifiziert wurden, auch bei der In-Hardware-Verifikation verifiziert werden. Daher bleiben die Anforderungen auf FPGA-Ebene erhalten und werden von der RTL-Simulation bis zum Hardware-Test gemäß Abschnitt 6.2 der RTCA/DO-254-Spezifikation verifiziert. Es sind keine Änderungen an der Testbench erforderlich.

Eine einzige Umgebung zur Verifizierung aller Anforderungen auf FPGA-Ebene

Traditionell müssen mehrere Testumgebungen erstellt werden, um mehrere FPGA-Anforderungen zu verifizieren, was in der Regel manuelle Verbindungen/Bypässe von Drähten und Kabeln erfordert, die anfällig für Fehler und Bugs sind. Eines der Hauptziele dieses Tools ist es, solche Fälle zu vermeiden. Dieses Tool besteht aus kundenspezifischer Hardware (PCIe-Schnittstelle) und Software, die eine einzige Umgebung zum Testen aller Anforderungen auf FPGA-Ebene bietet.

Automatisierte In-Hardware-Tests

Bei diesem Tool handelt es sich um eine automatisierte In-Hardware-Testumgebung auf Knopfdruck, mit der alle Anforderungen auf FPGA-Ebene getestet werden können. Es ist mit einem Dienstprogramm zum automatischen Vergleich der RTL-Simulationsergebnisse mit den Hardware-Testergebnissen ausgestattet. Das Dienstprogramm zeigt entweder eine PASS- oder FAIL-Meldung an, in der die Ergebnisse mit einem Standard-Waveform-Viewer weiter untersucht werden können.

Visualisierung der Hardware-Testergebnisse mit Waveform Viewer

Die Möglichkeiten zur Erfassung/Aufzeichnung und Visualisierung von Hardware-Testergebnissen mit Logikanalysatoren und digitalen Oszilloskopen sind begrenzt. Dieses Tool ermöglicht die Erfassung und Visualisierung von Ergebnissen mit dem Standard-Waveform-Viewer des Simulators und bietet Speicherplatz für Waveform-Dateien von bis zu 16 TB sowie die Erfassung der Ergebnisse unmittelbar nach der Simulation. Ein Vergleich zwischen RTL-Simulation und Hardware-Testergebnissen ist ebenfalls möglich.

Integration mit HDL-Simulatoren, Synthese- und P&R-Tools von Drittanbietern

Dieses Tool kann mit allen HDL-Simulatoren, Synthese- und P&R-Tools von Drittanbietern verwendet werden.

Detaillierter HDL-Entwurf und Verifizierung

Die HDL-Entwicklung und -Verifizierung gemäß den DO-254-Richtlinien ist ein anspruchsvolles Unterfangen und erfordert spezielle Funktionen und Fähigkeiten von HDL-Design- und Simulationswerkzeugen. Active-HDL™ oder Riviera-PRO™ bietet Funktionen für die grafische Entwurfserstellung, Verifikation, Verwaltung und Dokumentation, die eine flexible und nahtlose Entwurfs- und Verifikationsplattform ermöglichen.

Grafische HDL-Eingabe: Blockdiagramm-Editor und Zustandsmaschinen-Editor

Der Blockdiagramm-Editor ist ein Werkzeug für die grafische Eingabe von VHDL-, Verilog- und EDIF-Designs. Wenn das HDL-Design zu einem großen Teil strukturell ist, kann es einfacher sein, seine Beschreibung grafisch als Blockdiagramm einzugeben, als Hunderte von Quellcodezeilen zu tippen.

Der Zustandsdiagramm-Editor ist ein Werkzeug für die grafische Bearbeitung von Zustandsdiagrammen synchroner und asynchroner Maschinen. Das Zeichnen eines Zustandsdiagramms ist ein alternativer Ansatz für die Modellierung eines sequenziellen Geräts. Anstatt den HDL-Code manuell zu schreiben, kann der Entwickler die Beschreibung eines Logikblocks als grafisches Zustandsdiagramm eingeben.

HDL-Code-Grafik-Konverter

Der Code to Graphics Converter ist ein Werkzeug für die automatische Übersetzung von VHDL- oder Verilog-Quellcode in Block- und Zustandsdiagramme. Er analysiert VHDL-, Verilog- oder EDIF-Quelldateien und generiert eine oder mehrere Blockdiagrammdateien, abhängig von der Anzahl der in der analysierten Datei gefundenen Design-Entities, Module oder Zellen. Die resultierenden Blockdiagrammdateien können automatisch an einen Entwurf angehängt werden.

VHDL 2019-Simulation

Der neueste IEEE Std 1076-2019-Standard bringt lang erwartete Verbesserungen und neue testbenchbezogene Funktionen wie die Modusansichten für zusammengesetzte Typen und Subtypen, die Ableitung von Signal- und Variablensubtyp-Beschränkungen aus dem Anfangswert, bedingte Zuweisungen von Anfangswerten, bedingte Unterprogrammrückgabeanweisungen, bedingte Analysedirektiven, Garbage Collection usw. Da VHDL immer noch als sicherer als Verilog oder SystemC gilt, sind diese neuen testbench-bezogenen Funktionen zusammen mit den VHDL-Verifikationsbibliotheken OSVVM und UVVM eine bedeutende Verbesserung für den weit verbreiteten Standard VHDL 2008. Zur besseren Kompatibilität ist VHDL 2008 der Standardmodus für die Simulation. Der Benutzer kann sowohl auf die neueste Version von VHDL 2019 als auch auf die früheren Versionen von 2002 oder 1993 umschalten.

Verilog/SystemVerilog- und System-C-Simulation

Obwohl die meisten DO-254-Projekte VHDL als primäre Entwurfssprache verwenden, werden SystemVerilog und SystemC für Verifikationsaktivitäten immer beliebter. Active-HDL und Riviera-PRO sind gemischtsprachige Simulatoren mit Verilog/SystemVerilog- und SystemC-Unterstützung einschließlich der neuesten Verifikationsbibliotheken wie UVM und OVM.

HDL-Debugging und Post-Simulations-Debugging

Aldec-Simulatoren bieten eine Reihe von Funktionen zur effektiven Fehlersuche und Verifikation des Designverhaltens. Zu den interaktiven Active-HDL-Debugging-Funktionen gehören Source Code Tracing, Einfügen von Breakpoints, grafisches Blockdiagramm-Debugging und grafisches State Machine-Debugging. Active-HDL bietet außerdem mehrere Fenster zur Anzeige von Simulationsergebnissen, darunter List (Delta) Viewer, Watch Window, Processes Window, Waveform Viewer, Dataflow Window und Call Stack Window. Riviera-PRO ist die fortschrittliche Verifikationsplattform, die Debugging-Funktionen auf verschiedenen Abstraktionsebenen bietet. Das Tool bietet UVM Toolbox, UVM Graph, Class Viewer, Transaction Streams, Plot und Image Viewer für das Debugging auf höherer Abstraktionsebene und interaktive Debugging-Tools wie Code Tracing, Waveform, Dataflow, FSM Window, Coverage, Assertions, Memory Visualization Capabilities für die niedrigere Abstraktionsebene.
Post Simulation Debug ist eine sehr nützliche Funktion, die das Debuggen eines Projekts im „Offline“-Modus (ohne Verbindung zum Simulator) ermöglicht. Der Ingenieur kann nur eine reguläre Simulation durchführen, um die Post-Simulationsdaten zu sammeln und dann den Entwurf so oft wie nötig im Post-Simulationsmodus zu analysieren. Darüber hinaus kann der Ingenieur die Simulationsergebnisse mit anderen teilen und Post-Simulationsdateien verwenden, die von anderen Personen auf einem anderen Computer erstellt wurden.

Waveform Viewer/Editor und Verfolgung unbekannter Werte

Waveform Viewer ist ein Werkzeug zur Anzeige von Simulationsergebnissen in Form von grafischen Wellenformen. Während der Simulation gibt der Simulationskernel Wellenformen für ausgewählte Signale und Variablen im Waveform Viewer/Editor-Fenster aus. Waveform Viewer/Editor enthält eine Reihe nützlicher Funktionen wie Cursors, virtuelle Objekte, Transaktionen, Assertions, analoge Darstellung, Vergleich und Signal Navigator. Wellenformen können bei späteren Simulationsläufen als Testvektoren auf Signale und Netze angewandt werden. Kommentare und Markierungen können in die Kurvenformen eingefügt werden und dann zu Dokumentationszwecken ausgedruckt oder in ein PDF- oder HTML-Dokument exportiert werden.

Unbekannte und nicht initialisierte Werte („x“, „w“, – usw.) können eine Quelle für unerwartetes Verhalten an den Ausgabeports einer getesteten Einheit/eines getesteten Moduls sein. XTrace ist ein Befehlszeilen-Dienstprogramm, das es ermöglicht, unbekannte Werte zu erkennen und zu melden, wenn sie zum ersten Mal auftauchen und bevor sie in einem Entwurf weitergegeben werden. Es ermöglicht das Anhalten der Simulation, wenn einem der überwachten Signale ein unbekannter Wert zugewiesen wird. Entsprechende Meldungen über unerwartete Werte, Signale und den Zeitpunkt, zu dem diese Werte entdeckt wurden, werden ebenfalls im Konsolenfenster angezeigt.

Assertion-basierte Verifikation

Assertions können sowohl zur Erkennung von Fehlern in einem Entwurf als auch zur Verifizierung und Beschreibung komplexer Ereignisabläufe verwendet werden. Assertions können zur Verifikation von Anforderungen verwendet werden. Assertions können in wiederverwendbaren Einheiten mit parametrisierten Verifikationsregeln gekapselt werden, was die Möglichkeit bietet, unabhängige Checker zu erstellen, die auf benutzerdefinierte oder universelle Protokolle spezialisiert sind, die häufig in Designs verwendet werden. PSL und System Verilog Assertions werden unterstützt.

Code Coverage und Toggle Coverage

Code Coverage ist ein Debugging-Tool, das den Verifikationsprozess unterstützt. Code Coverage wird auch zur Unterstützung der Elementaranalyse verwendet, einem erweiterten Verifikationsansatz, der in RTCA/DO-254 Appendix B 3.3.1 beschrieben ist. Aldec-Simulatoren ermöglichen die Verifikation von Quellcode mit den folgenden Coverage-Tools:

Statement Coverage zeigt Ausführungszweige für jede HDL-Anweisung an. Diese Informationen geben Aufschluss darüber, welche Teile des Entwurfs verifiziert wurden und welche ungetestet sind. Sie hilft auch, toten Code zu lokalisieren.

Branch Coverage sammelt Ausführungsverzweigungen für die Konstrukte „if“ und „case“ sowie für ausgewählte VHDL-Anweisungen und bedingte Signalzuweisungen.

Expression Coverage faktorisiert logische Ausdrücke und überwacht sie während der Simulation.

Condition Coverage ist eine Erweiterung von Expression Coverage und überwacht und faktorisiert logische Ausdrücke, die in bedingten Anweisungen verwendet werden. Diese Art von Coverage überwacht Ausdrücke, die als Bedingung in Konstrukten wie „if then“, „while“ usw. auftreten.

FSM Coverage ermöglicht es dem Benutzer, nicht besuchte Zustände und nicht ausgewertete Übergänge zu identifizieren.

Path Coverage sammelt Informationen über die Programmausführung und analysiert, ob alle Kombinationen von Programmsequenzen (Programmpfade) durch eine Testbench verifiziert werden. Ein Programmpfad ist eine Folge von Anweisungsausführungen, die in einer bestimmten Reihenfolge ausgeführt werden. Das Tool sammelt auch Informationen darüber, in welcher Reihenfolge die aufeinanderfolgenden Anweisungen ausgeführt werden, welche Verzweigungen untersucht werden und wie logische Bedingungen während der Simulation ausgewertet werden.

Toggle Coverage ist ein Programm, das eine Entwurfsaktivität anhand von Änderungen der logischen Signalwerte misst. Toggle Coverage erstellt einen Bericht, der Auskunft darüber gibt, ob überwachte Signale initialisiert wurden, ob überwachte Signale steigende und/oder fallende Flanken aufwiesen und wie viele steigende und fallende Flanken während der Simulationssitzung auftraten. Der Bericht hilft dabei, die Qualität des Stimulus zu überprüfen und nicht aktive Strukturen des Designs zu lokalisieren. Signale, die während der Simulation nicht initialisiert wurden oder die von der Testbench nicht ordnungsgemäß ausgeführt werden, können leicht identifiziert werden.

Source-Revisionskontrolle und Dokumentationsfunktionen für den Entwurf

Die Quellcode-Revisionskontrolle ermöglicht es, direkt aus der HDL-Simulatorumgebung auf nachfolgende Versionen und Revisionen von Design-Quelldateien zuzugreifen. In einer solchen Umgebung ist es möglich, die Änderungen an einem Design zu verfolgen und Unterschiede zwischen den nachfolgenden Versionen der Dateien zu sehen. Das Source-Revision-Control-System erleichtert auch die Arbeit im Team, da es einer Gruppe von Entwicklern die Arbeit am selben Projekt ermöglicht. Sobald die Dateien in einem Repository archiviert sind, stehen sie den anderen Teammitgliedern zur Verfügung. Außerdem werden alle Änderungen, die an einer Datei vorgenommen wurden, mit einem vollständigen Verlauf gespeichert, so dass Sie jede Version jeder Datei jederzeit wiederherstellen können. Die Mitglieder Ihrer Gruppe können die neueste Version eines beliebigen Projekts einsehen, Änderungen vornehmen und eine neue Version in der Datenbank des Source Revision Control Systems speichern.

Die Entwurfsdokumentation für die DO-254-Zertifizierung ist eine Notwendigkeit. Active-HDL verfügt über leistungsstarke Dokumentationsfunktionen, die es dem Ingenieur ermöglichen, eine textliche oder grafische Darstellung des Arbeitsbereichs oder des Entwurfs im HTML- oder PDF-Format zu erstellen. Alle Entwurfselemente wie Entwurfsdateien, Wellenformen, Blockdiagramme und angehängte Dokumente können in HTML- oder PDF-Dokumente exportiert werden, die durch verschiedene Optionen im Assistenten gesteuert werden können. Die resultierenden Dokumente behalten immer die Hierarchie des Entwurfs bei, was eine einfache Navigation in komplexen Entwürfen ermöglicht. Durch den Export in Vektorgrafiken wird die hohe Auflösung der Schaltplandateien im generierten Dokument beibehalten.

Integration mit Synthese- und P&R-Tools von Drittanbietern

Der Design Flow Manager von Active-HDL bietet nahtlose Schnittstellen zu Synthese- und P&R-Tools von Drittanbietern und ermöglicht so eine einzigartige Plattform, die während des gesamten FPGA-Design-Flows verwendet werden kann.

DO-254 Vorlagen und Prüflisten

DO-254 konforme Vorlagen und Checklisten Datenpaket

Die Entwicklung von PLDs (FPGAs, ASICs und CPLDs) für die DO-254-Konformität setzt voraus, dass der Antragsteller umfangreiche professionelle Dokumente und Artefakte bei der zuständigen Zertifizierungsstelle einreicht. Es liegt in der Verantwortung des Antragstellers, die Dokumente zu verfassen und zu erstellen und sie mit größter Sorgfalt anhand einer hochwertigen Checkliste zu prüfen.

Für Unternehmen, die neu in der DO-254 sind, ist es schwierig, ein neues DO-254-Programm zu starten, ohne eine Grundlage für die erforderlichen Dokumente und Prüflisten zu haben, und für Unternehmen, die bereits Erfahrung mit der DO-254 haben, ist es wichtig, ihre bestehenden Grundlagen zu verbessern, da sie aus früheren Programmen gelernt haben. Das Datenpaket von Aldec, das von einem FAA Consultant DER über viele Jahre hinweg im Rahmen der Auditierung mehrerer DO-254-Programme mit FPGAs der Design Assurance Level (DAL) A, B, C und D entwickelt wurde, bietet sowohl neuen als auch erfahrenen DO-254-Praktikern einen erheblichen Mehrwert.

Dieses Datenpaket enthält DO-254-Vorlagen und Review-Checklisten, die in Spec-TRACER enthalten sind und von Antragstellern leicht als Ausgangsbasis für die Erstellung von Unternehmensstandarddokumenten und -artefakten übernommen werden können. Spec-TRACER bietet eine einzige Umgebung, in der mehrere Beteiligte erfassen, Versionen/Baselines verwalten, Reviews durchführen und Berichte erstellen können.

Templates

Dieses Datenpaket enthält 16 Vorlagen für die Erstellung von Dokumenten in den Kategorien Hardware-Management-Pläne, Hardware-Standards und Hardware-Lebenszyklusdaten. Jede Vorlage enthält spezifische Abschnitte, die in einem DO-254-Projekt für PLDs erforderlich sind. Außerdem gibt es 5 Vorlagen (PHAC, HRD, HVVP und TCD), die spezifische Beispiele für die Formulierung bestimmter Abschnitte der Dokumente enthalten.

DO-254 Templates

 

Checkliste Kriterien

Dieses Paket enthält die Kriterien für die Durchführung von Überprüfungen der Einhaltung von Hardware-Managementplänen in Übereinstimmung mit DO-254. Es handelt sich dabei um die Kriterien, die zur Erstellung der Checklisten für die Verifizierungsaktivitäten verwendet werden, auf die typischerweise im Hardware-Verifizierungsplan, Hardware-Validierungsplan und/oder in den Hardware-Verifizierungs- und Validierungsstandards verwiesen wird. Der vollständige Satz von Überprüfungskriterien umfasst:

DO-254 Review Checklist

 Die Checklisten enthalten eine Reihe von Kriterien, die bei der Überprüfung von DO-254 PLD-Hardware-Lebenszyklusdaten und -dokumenten anzuwenden sind. Diese Kriterien sind Teil der Hardware-Verifizierungsstandards. Jedes Kriterium sollte auf das jeweilige Dokument oder die jeweiligen Daten angewendet werden. Zum Beispiel werden die „DO-254 PLD Plan for Hardware Aspects of Certification Review Criteria“ zur Überprüfung eines Plans für Hardware-Aspekte der Zertifizierung verwendet.

Bei Dokumenten oder Daten mit mehreren sich wiederholenden Elementen sollten die Kriterien der Checkliste auf jedes Element des Dokuments angewendet werden. Dies sollte mit den Anforderungen, dem Design, den Testfällen, den Testbenches, den Testverfahren und den Testergebnissen geschehen. In diesen Fällen können die Kriterien spaltenübergreifend in eine Tabelle eingetragen und die Kennung des Überprüfungselements in den Zeilen aufgeführt werden.

Die Kriterien sind allgemein und so vollständig wie möglich. Jedes Projekt kann zusätzliche Prüfkriterien haben, die leicht hinzugefügt werden können. Zusätzliche Kriterien können aus Unternehmensstandards, Erfahrungen aus anderen Projekten, Ideen, die im Laufe eines Projekts entstehen, FAA Issue Papers, EASA CRIs oder Kriterien anderer Zertifizierungsbehörden stammen.