UG0837
Benutzerhandbuch
IGLOO2 und SmartFusion2 FPGA
Simulation von Systemdiensten
Juni 2018

Änderungsverlauf

Der Revisionsverlauf beschreibt die Änderungen, die im Dokument vorgenommen wurden. Die Änderungen werden nach Revision aufgelistet, beginnend mit der aktuellsten Veröffentlichung.
1.1 Überarbeitung 1.0
Revision 1.0 wurde im Juni 2018 veröffentlicht. Es war die erste Veröffentlichung dieses Dokuments.

Simulation von IGLOO2- und SmartFusion2-FPGA-Systemdiensten

Der Systemdienstblock der SmartFusion®2 FPGA-Familie enthält eine Sammlung von Diensten, die für verschiedene Aufgaben verantwortlich sind. Dazu gehören Simulationsnachrichtendienste, Datenzeigerdienste und Datendeskriptordienste. Auf die Systemdienste kann über den Cortex-M3 in SmartFusion2 und vom FPGA-Fabric über den Fabric Interface Controller (FIC) sowohl für SmartFusion2 als auch für IGLOO®2 zugegriffen werden. Diese Zugriffsmethoden werden über COMM_BLK an die Systemsteuerung gesendet. Der COMM_BLK verfügt über eine Advanced Peripheral Bus (APB)-Schnittstelle und dient als Nachrichtenweiterleitung zum Austausch von Daten mit der Systemsteuerung. Systemdienstanforderungen werden an den Systemcontroller gesendet, und Systemdienstantworten werden an den CoreSysService durch das COMM BLK gesendet. Der Adressort für COMM_BLK ist innerhalb des Mikrocontroller-Subsystems (MSS)/Hochleistungsspeicher-Subsystems (HPMS) verfügbar. Einzelheiten finden Sie unter UG0450: SmartFusion2 SoC und IGLOO2 FPGA System Controller.
Benutzerhandbuch
Die folgende Abbildung zeigt den Datenfluss der Systemdienste.
Abbildung 1 • Flussdiagramm der SystemdienstdatenSowohl für die IGLOO2- als auch für die SmartFusion2-Systemdienstsimulation müssen Sie Systemdienstanforderungen senden und die Systemdienstantworten überprüfen, um sicherzustellen, dass die Simulation korrekt ist. Dieser Schritt ist notwendig, um auf den Systemcontroller zuzugreifen, der die Systemdienste bereitstellt. Die Art und Weise, auf den Systemcontroller zu schreiben und von ihm zu lesen, ist für IGLOO2- und SmartFusion2-Geräte unterschiedlich. Für SmartFusion2 ist der Coretex-M3 verfügbar und Sie können mit Bus Functional Model (BFM)-Befehlen vom Systemcontroller schreiben und lesen. Für IGLOO2 ist der Cortex-M3 nicht verfügbar und der Systemcontroller ist nicht über BFM-Befehle zugänglich.
2.1 Arten verfügbarer Systemdienste
Es sind drei verschiedene Typen von Systemdiensten verfügbar, und jeder Diensttyp hat unterschiedliche Untertypen.
Simulationsnachrichtendienste
Datenzeigerdienste
Datendeskriptordienste
Das Kapitel Anhang – Typen von Systemdiensten (siehe Seite 19) dieses Handbuchs beschreibt die verschiedenen Typen von Systemdiensten. Weitere Informationen zu Systemdiensten finden Sie im UG0450: SmartFusion2 SoC and IGLOO2 FPGA System Controller User Guide .
2.2 Simulation des IGLOO2-Systemdienstes
Systemdienste umfassen das Schreiben auf und das Lesen von der Systemsteuerung. Um zu Simulationszwecken auf den Systemcontroller zu schreiben und daraus zu lesen, müssen Sie die folgenden Schritte ausführen.

1. Instanziieren Sie den Soft-IP-Core CoreSysServices, der im SmartDesign-Katalog verfügbar ist.
2. Schreiben Sie den HDL-Code für eine endliche Zustandsmaschine (FSM).

Der HDL FSM bildet eine Schnittstelle mit dem CoreSysServices Core, der als Fabric-Master des AHBLite-Busses dient. Der CoreSysServices-Kern initiiert eine Systemdienstanforderung an den COMM BLK und empfängt Systemdienstantworten vom COMM BLK über den FIC_0/1, Fabric-Schnittstellencontroller, wie in der folgenden Abbildung gezeigt.
Abbildung 2 • IGLOO2 System Services-Simulationstopologie2.3 Simulation des SmartFusion2-Systemdienstes
Um Systemdienste in SmartFusion2-Geräten zu simulieren, müssen Sie auf den Systemcontroller schreiben und von ihm lesen. Es stehen zwei Optionen zur Verfügung, um zu Simulationszwecken auf den Systemcontroller zuzugreifen.
Option 1 – Schreiben Sie den HDL-Code für einen FSM als Schnittstelle zum CoreSysService Soft-IP-Kern, der als AHBLite-Fabric-Master dient und eine Systemdienstanforderung an das COMM BLK initiiert und Systemdienstantworten vom COMM BLK über das FIC_0/1-Fabric empfängt Schnittstelle wie in der folgenden Abbildung gezeigt.
Abbildung 3 • Simulationstopologie der SmartFusion2-Systemdienste

Option 2 – Da der Cortex-M3 für SmartFusion2-Geräte verfügbar ist, können Sie BFM-Befehle verwenden, um direkt in den Speicherbereich des Systemcontrollers zu schreiben und daraus zu lesen.
Die Verwendung von BFM-Befehlen (Option 2) erspart die Notwendigkeit, die HDL-Codes für die FSM zu schreiben. In diesem Benutzerhandbuch wird Option 2 verwendet, um die Simulation von Systemdiensten in SmartFusion2 anzuzeigen. Mit dieser Option wird auf den Speicherplatz des Systemcontrollers zugegriffen, um die Speicherabbildung des COMM BLK und des Fabric Interface Interrupt Controller (FIIC)-Blocks herauszufinden, wenn Sie Ihre BFM-Befehle schreiben.
2.4 Simulation Bspamples
Das Benutzerhandbuch behandelt die folgenden Simulationen.

• IGLOO2 Simulation des Seriennummerndienstes (siehe Seite 5)
• Simulation des SmartFusion2-Seriennummerndienstes (siehe Seite 8)
• IGLOO2 Zeroization Service Simulation (siehe Seite 13)
• SmartFusion2 Zeroization Service Simulation (siehe Seite 16)

Ähnliche Simulationsverfahren können auf andere Systemdienste angewendet werden. Eine vollständige Liste der verschiedenen verfügbaren Systemdienste finden Sie unter Anhang – Systemdiensttypen (siehe Seite 19).

2.5 Simulation des IGLOO2-Seriennummerndienstes
Führen Sie die folgenden Schritte aus, um sich auf die Simulation des IGLOO2-Seriennummerndienstes vorzubereiten.

1. Rufen Sie System Builder auf, um Ihren HPMS-Block zu erstellen.
2. Aktivieren Sie das Kontrollkästchen HPMS System Services auf der Seite Device Features. Dadurch wird der Systemhersteller angewiesen, die HPMS_FIC_0 SYS_SERVICES_MASTER-Busschnittstelle (BIF) verfügbar zu machen.
3. Lassen Sie alle anderen Kontrollkästchen deaktiviert.
4. Akzeptieren Sie die Standardeinstellung auf allen anderen Seiten und klicken Sie auf Fertig stellen, um den System-Builder-Block abzuschließen. Schreiben Sie im HDL-Editor des Libero®-SoC den HDL-Code für die FSM (File > Neu > HDL) . Nehmen Sie die folgenden drei Zustände in Ihre FSM auf.
   INIT-Zustand (Anfangszustand)
   SERV_PHASE (Status der Dienstanforderung)
   RSP_PHASE (Dienstantwortstatus).
   Die folgende Abbildung zeigt die drei Zustände von FSM.
   Abbildung 4 • FSM mit drei Zuständen
5. Verwenden Sie in Ihrem HDL-Code für den FSM den korrekten Befehlscode („01“ Hex für Seriennummerndienst), um den Dienstanforderungsstatus aus dem INIT-Status einzugeben.
6. Speichern Sie Ihre HDL file. Der FSM erscheint als Komponente in der Designhierarchie.
7. Öffnen Sie SmartDesign. Ziehen Sie Ihren System-Builder-Block der obersten Ebene und Ihren FSM-Block per Drag-and-Drop in die SmartDesign-Leinwand. Ziehen Sie aus dem Katalog den Soft-IP-Core CoreSysService in die SmartDesign-Leinwand und legen Sie ihn dort ab.
8. Klicken Sie mit der rechten Maustaste auf den Soft-IP-Core CoreSysService, um den Konfigurator zu öffnen. Aktivieren Sie das Kontrollkästchen Serial Number Service (unter Device and Design Information Services
   Gruppe), um den Seriennummerndienst zu aktivieren.
9. Lassen Sie alle anderen Kontrollkästchen deaktiviert. Klicken Sie auf OK, um den Konfigurator zu verlassen.
   Abbildung 5 • CoreSysServices-Soft-IP-Core-Konfigurator
   
10. Verbinden Sie die HPMS_FIC_0 SYS_SERVICES_MASTER BIF des System Builder-Blocks mit der AHBL_MASTER BIF des CoreSysService-Blocks.
11. Verbinden Sie den Ausgang Ihres HDL-FSM-Blocks mit dem Eingang des CoreSysService-Soft-IP-Kerns. Stellen Sie alle anderen Verbindungen in der SmartDesign-Leinwand her, wie in der folgenden Abbildung gezeigt.
    Abbildung 6 • SmartDesign Canvas mit HDL-Block, CoreSysServices Soft IP und HPMS-Blöcken
12. Klicken Sie in der SmartDesign-Leinwand mit der rechten Maustaste auf >Komponente generieren, um das Top-Level-Design zu generieren.
13. In der Designhierarchie view, klicken Sie mit der rechten Maustaste auf das Design der obersten Ebene und wählen Sie Testbench erstellen > HDL aus.
14. Verwenden Sie einen Texteditor, um einen Text zu erstellen file mit dem Namen „status.txt“ .
15. Fügen Sie den Befehl für den Systemdienst und die 128-Bit-Seriennummer hinzu. Weitere Informationen finden Sie in Tabelle 1 (Befehls-/Antwortwerte der Systemdienste) im CoreSysServices v3.1 Handbuch für die Befehlscodes (Hex), die für verschiedene Systemdienste verwendet werden sollen. Für den Seriennummerndienst lautet der Befehlscode „01“ Hex.

Das Format der status.txt file für den Seriennummernservice ist wie folgt.
< 2 Hex-Ziffer CMD><32 Hex-Ziffer Seriennummer>
Example: 01A1A2A3A4B1B2B3B4C1C2C3C4D1D2D3D4
Speichern Sie die status.txt file im Ordner Simulation Ihres Projekts. Das Design ist nun bereit für die Simulation.
Sobald der Dienst mit der Ausführung begonnen hat, wird im Transkriptfenster von ModelSim eine Meldung mit dem Zielort und der Seriennummer angezeigt, wie in der folgenden Abbildung dargestellt.
Abbildung 7 • ModelSim-SimulationsprotokollfensterDer Systemcontroller führt einen AHB-Schreibvorgang an die Adresse mit der Seriennummer durch. Nach Abschluss des Dienstes wird das RXFIFO des COMM_BLK mit der Dienstantwort geladen.
Hinweis: Eine vollständige Liste der für verschiedene Systemdienste zu verwendenden Befehlscodes finden Sie in Tabelle 1 (Befehls-/Antwortwerte der Systemdienste) im Handbuch CoreSysServices v3.1 oder UG0450: SmartFusion2 SoC and IGLOO2 FPGA System Controller User Guide.
2.6 Simulation des SmartFusion2-Seriennummerndienstes
In diesem Benutzerhandbuch werden BFM-Befehle (Option 2) verwendet, um auf den Systemcontroller für Systemdienste zuzugreifen. BFM-Befehle werden verwendet, da der Cortex-M3-Prozessor auf dem Gerät für die BFM-Simulation verfügbar ist. BFM-Befehle ermöglichen es Ihnen, direkt in den COMM BLK zu schreiben und daraus zu lesen, sobald Sie die Speicherzuordnung des COMM_BLK kennen.
Führen Sie die folgenden Schritte aus, um Ihr Design für die Simulation des SmartFusion2-Seriennummerndienstes vorzubereiten.

1. Ziehen Sie das MSS per Drag & Drop aus dem Katalog in die Design-Leinwand Ihres Projekts.
2. Deaktivieren Sie alle MSS-Peripheriegeräte außer MSS_CCC, Reset Controller, Interrupt Management und FIC_0, FIC_1 und FIC_2.
3. Konfigurieren Sie das Interrupt-Management so, dass MSS für Fabric-Interrupts verwendet wird.
4. Bereiten Sie die serialnum.bfm vor file in einem Texteditor oder im HDL-Editor des Libero. Speichern Sie die Seriennummer.bfm file im Ordner Simulation des Projekts. Die serialnum.bfm sollte die folgenden Details enthalten.
   • Speicherzuordnung zum COMM BLK (CMBLK)
   • Speicherzuordnung zum Interrupt-Management-Peripheriegerät (FIIC)
   • Befehl für Dienstanforderung des Seriennummernsystems („01“ Hex)
   • Adresse für den Standort der Seriennummer
   Ein ExampDatei der serialnum.bfm file ist wie folgt.
   Memmap-FIIC 0x40006000; #Speicherzuordnung zum Interrupt-Management
   Memmap CMBLK 0x40016000; #Speicherzuordnung zu COMM BLK
   Memmap DESCRIPTOR_ADDR 0x20000000; #Adressstandort für Seriennummer
   #Befehlscode in Hexadezimal
   konstant CMD 0x1 # Befehlscode für Serial NumberService
   #FIIC-Konfigurationsregister
   Konstante FICC_INTERRUPT_ENABLE0 0x0
   #COMM_BLK Konfigurationsregister
   Konstante STEUERUNG 0x00
   Konstante STATUS 0x04
   Konstante INT_ENABLE 0x08
   Konstante DATA8 0x10
   Konstante DATA32 0x14
   Konstante FRAME_START8 0x18
   konstant FRAME_START32 0x1C
   Prozedur Seriennummer;
   int x;
   schreiben w FIIC FICC_INTERRUPT_ENABLE0 0x20000000 #Konfigurieren
   #FICC_INTERRUPT_ENABLE0 # Registrieren, um COMBLK_INTR zu aktivieren #
   #Interrupt vom COMM_BLK-Block zum Fabric
   #Anfragephase
   schreibe w CMBLK CONTROL 0x10 # COMM BLK Control konfigurieren #registrieren auf
   Übertragungen auf der COMM BLK-Schnittstelle aktivieren
   schreibe w CMBLK INT_ENABLE 0x1 # Konfiguriere COMM BLK Interrupt Enable
   #Registrieren Sie sich, um den Interrupt für TXTOKAY zu aktivieren (entsprechendes Bit in der
   #Statusregister)
   waitint 19 # auf COMM BLK Interrupt warten, hier wartet #BFM
   #bis COMBLK_INTR bestätigt wird
   readstore w CMBLK STATUS x # COMM BLK-Statusregister für #TXTOKAY lesen
   # Unterbrechen
   setze xx & 0x1
   wenn x
   schreibe w CMBLK FRAME_START8 CMD # Konfiguriere COMM BLK FRAME_START8
   #Registrieren Sie sich, um den Seriennummerndienst anzufordern
   Ende
   Ende
   waitint 19 # auf COMM BLK Interrupt warten, hier
   #BFM wartet, bis COMBLK_INTR geltend gemacht wird
   readstore w CMBLK STATUS x # COMM BLK Status Register lesen für
   #TXTOKAY Unterbrechung
   setze xx & 0x1
   setze xx & 0x1
   wenn x
   schreibe w CMBLK CONTROL 0x14 #Configure COMM BLK Control
   #Registrieren Sie sich, um Übertragungen auf der COMM BLK-Schnittstelle zu ermöglichen
   schreibe w CMBLK DATA32 DESCRIPTOR_ADDR
   schreibe w CMBLK INT_ENABLE 0x80
   schreibe w CMBLK CONTROL 0x10
   Ende
   warte 20
   #Reaktionsphase
   Wartezeit 19
   readstore w CMBLK-STATUS x
   setze xx & 0x80
   wenn x
   readcheck w CMBLK FRAME_START8 CMD
   schreibe w CMBLK INT_ENABLE 0x2
   Ende
   Wartezeit 19
   readstore w CMBLK-STATUS x
   setze xx & 0x2
   wenn x
   Leseprüfung mit CMBLK DATA8 0x0
   schreibe w CMBLK CONTROL 0x18
   Ende
   Wartezeit 19
   Leseprüfung mit FIIC 0x8 0x20000000
   readstore w CMBLK-STATUS x
   setze xx & 0x2
   wenn x
   readcheck w CMBLK DATA32 DESCRIPTOR_ADDR
   Ende
   readcheck w DESCRIPTOR_ADDR 0x0 0xE1E2E3E4; #Readcheck, um S/N zu überprüfen
   readcheck w DESCRIPTOR_ADDR 0x4 0xC1C2C3C4; #Readcheck, um S/N zu prüfen
   readcheck w DESCRIPTOR_ADDR 0x8 0xB1B2B3B4; #Readcheck, um S/N zu überprüfen
   readcheck w DESCRIPTOR_ADDR 0xC 0xA1A2A3A4; #Readcheck, um S/N zu prüfen
   zurückkehren
5. Erstellen Sie den Status. txt file im HDL-Editor von Libero oder einem beliebigen Texteditor. Fügen Sie den Systemdienstbefehl für die Seriennummer („01“ in Hex) und die Seriennummer in den Status ein. txt file. Informationen zur Verwendung des richtigen Befehlscodes finden Sie im Handbuch zu CoreSysServices v3.1.
6. Die Syntax dieser file für den Seriennummerndienst ist <2 Hex-Ziffern CMD>< 32 Hex-Ziffern Seriennummer> . Example: 01A1A2A3A4B1B2B3B4C1C2C3C4E1E2E3E4.
7. Speichern Sie die Status-.txt file im Ordner Simulation des Projekts.
8. Bearbeiten Sie die Benutzer-.bfm (im Ordner „Simulation“) so, dass sie die Seriennummer enthält. bfm file und rufen Sie die Seriennummernprozedur auf, wie im folgenden Codeausschnitt gezeigt.
   „Seriennummer.bfm“ einschließen #Seriennummer.bfm einschließen
   Prozedur user_main;
   print „INFO:Simulation Starts“;
   print „INFO:Service Command Code in Decimal:%0d“, CMD ;
   Seriennummer aufrufen; #Rufen Sie die Serialnum-Prozedur auf
   print „INFO:Simulation Ends“;
   zurückkehren
9. In der Designhierarchie view, generieren Sie die Testbench (Rechtsklick, Top-Level-Design > Testbench erstellen > HDL ) und Sie können die Simulation des Seriennummerndienstes ausführen.

Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die den Zielort und die Seriennummer angibt. Der Systemcontroller führt einen AHB-Schreibvorgang an die Adresse mit der Seriennummer durch. Nach Abschluss des Dienstes wird das RXFIFO des COMM_BLK mit der Dienstantwort geladen. Das Transcript-Fenster von ModelSim zeigt die erhaltene Adresse und Seriennummer an, wie in der folgenden Abbildung dargestellt.
Abbildung 8 • Simulation des SmartFusion2-Seriennummerndienstes im ModelSim-Abschriftfenster

2.7 IGLOO2 Zeroization Service-Simulation
Führen Sie die folgenden Schritte aus, um die IGLOO2-Zeroization-Service-Simulation vorzubereiten.

1. Rufen Sie System Builder auf, um den HPMS-Block zu erstellen. Aktivieren Sie das Kontrollkästchen HPMS-Systemdienste in den Gerätefunktionen SYS_SERVICES_MASTER BIF. Lassen Sie alle anderen Kontrollkästchen deaktiviert. Akzeptieren Sie die Standardeinstellung auf allen anderen Seiten und klicken Sie auf Seite. Dies weist den System-Builder an, HPMS_FIC_0 Finish bereitzustellen, um die Konfiguration des System-Builder-Blocks abzuschließen.
2. Schreiben Sie im HDL-Editor des Libero SoC den HDL-Code für den FSM. Schließen Sie in Ihrem HDL-Code für den FSM die folgenden drei Zustände ein.
   INIT-Zustand (Anfangszustand)
   SERV_PHASE (Status der Dienstanforderung)
   RSP_PHASE (Dienstantwortstatus)
   Die folgende Abbildung zeigt die drei Zustände von FSM.
   Abbildung 9 • FSM mit drei Zuständen

    

3. Verwenden Sie in Ihrem HDL-Code den Befehlscode „F0″ (Hex), um den Dienstanforderungsstatus aus dem INIT-Status einzugeben.
4. Speichern Sie Ihre HDL file.
5. Öffnen Sie SmartDesign, ziehen Sie Ihren System-Builder-Block der obersten Ebene und Ihren HDL-FSM-Block per Drag-and-Drop in die SmartDesign-Leinwand. Ziehen Sie aus dem Katalog den Soft-IP-Core CoreSysService in die SmartDesign-Leinwand und legen Sie ihn dort ab.
6. Klicken Sie mit der rechten Maustaste auf den Soft-IP-Core CoreSysServices, um den Konfigurator zu öffnen, und aktivieren Sie das Kontrollkästchen Zeroization Service unter der Gruppe Data Security Services. Lassen Sie alle anderen Kontrollkästchen deaktiviert. Klicken Sie zum Beenden auf OK.
   Abbildung 10 • CoreSysServices-Konfigurator
   
7. Verbinden Sie die HPMS_FIC_0 SYS_SERVICES_MASTER BIF des System Builder-Blocks mit der AHBL_MASTER BIF des CoreSysService-Blocks.
8. Verbinden Sie den Ausgang Ihres HDL-FSM-Blocks mit dem Eingang des CoreSysService-Soft-IP-Kerns. Stellen Sie alle anderen Verbindungen in der SmartDesign-Leinwand her.
   Abbildung 11 • SmartDesign Canvas mit HDL-Block, CoreSysServices-Soft-IP und HPMS-Blöcken
   9. Generieren Sie im SmartDesign-Canvas das Design der obersten Ebene (Rechtsklick > Komponente generieren).
   10. In der Designhierarchie view, klicken Sie mit der rechten Maustaste auf das Design der obersten Ebene und wählen Sie Testbench erstellen > HDL aus. Sie können jetzt die Simulation ausführen.
   Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die angibt, dass die Nullsetzung zum Zeitpunkt x abgeschlossen wurde, wie in der folgenden Abbildung dargestellt.
   Abbildung 12 • IGLOO2 Zeroization System Service Simulation Transcript Fenster
   

Der Systemcontroller führt einen AHB-Schreibvorgang an die Adresse mit der Seriennummer durch. Nach Abschluss des Dienstes wird das RXFIFO des COMM_BLK mit der Dienstantwort geladen. Es sollte beachtet werden, dass das Simulationsmodell die Nullsetzung simuliert, indem es die Simulation stoppt, anstatt das Design selbst zu nullen.
Hinweis: Eine vollständige Liste der für verschiedene Systemdienste zu verwendenden Befehlscodes finden Sie in Tabelle 1 (Befehls-/Antwortwerte der Systemdienste) im CoreSysServices v3.1 Handbuch:. oder UG0450: Benutzerhandbuch für SmartFusion2 SoC und IGLOO2 FPGA System Controller

2.8 SmartFusion2 Zeroization Service-Simulation
In diesem Handbuch werden BFM-Befehle (Option 2) verwendet, um auf den Systemcontroller für Systemdienste zuzugreifen.
BFM-Befehle werden verwendet, da der Cortex-M3-Prozessor auf dem Gerät für die BFM-Simulation verfügbar ist. BFM-Befehle ermöglichen es Ihnen, direkt in den COMM BLK zu schreiben und daraus zu lesen, sobald Sie die Speicherzuordnung des COMM_BLK kennen. Führen Sie die folgenden Schritte aus, um Ihr Design für die SmartFusion2-Zeroization-Service-Simulation vorzubereiten.

1. Ziehen Sie das MSS per Drag & Drop aus dem Katalog in die Design-Leinwand Ihres Projekts.
2. Deaktivieren Sie alle MSS-Peripheriegeräte außer MSS_CCC, Reset Controller, Interrupt Management und FIC_0, FIC_1 und FIC_2.
3. Konfigurieren Sie das Interrupt-Management so, dass MSS für Fabric-Interrupts verwendet wird.
4. Bereiten Sie die zeroizaton.bfm vor file in einem Texteditor oder im HDL-Editor von Libero. Ihre Nullstellung. bfm sollte beinhalten:

• Speicherzuordnung zum COMM BLK (CMBLK)
• Speicherzuordnung zum Interrupt-Management-Peripheriegerät (FIIC)
• Befehl für Zeroization-Service-Request („F0“ Hex für Zeroization)

Ein ExampDatei der serialnum.bfm file ist in der folgenden Abbildung dargestellt.
Abbildung 13 • Zeroization.bfm für die Simulation von SmartFusion2-Zeroization-Systemdiensten

5. Speichern Sie die zeroization.bfm file im Ordner Simulation des Projekts. user.bfm
6. Bearbeiten Sie die (im Simulationsordner zeroization.bfm) so, dass sie die mithilfe des folgenden Codeausschnitts enthält.
„zeroization.bfm“ einschließen #include zeroization.bfm file Prozedur user_main;
print „INFO:Simulation Starts“;
print „INFO:Service Command Code in Decimal:%0d“, CMD ;
Anrufnullsetzung; #Zeroisierungsprozedur zurückrufen
7. Generieren Sie in der Designhierarchie die Testbench (Rechtsklick auf oberste Ebene > Testbench erstellen > HDL ) und Sie können die SmartFusion2-Zeroisierungssimulation ausführen.
Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die angibt, dass das Gerät zum Zeitpunkt x auf Null gesetzt wurde. Es sollte beachtet werden, dass das Simulationsmodell die Nullsetzung simuliert, indem es die Simulation stoppt, anstatt das Design selbst zu nullen. Das Transkriptfenster von ModelSim in der folgenden Abbildung zeigt, dass das Gerät auf Null gesetzt wurde.

Abbildung 14 • Dienstsimulationsprotokoll des SmartFusion2 Zeroization-Systems

Anhang: Arten von Systemdiensten

Dieses Kapitel beschreibt verschiedene Arten von Systemdiensten.
3.1 Simulationsnachrichtendienste
In den folgenden Abschnitten werden verschiedene Arten von Simulationsnachrichtendiensten beschrieben.
3.1.1 Flash*Freeze
Die Simulation wechselt in den Flash*Freeze-Zustand, wenn die richtige Dienstanforderung entweder vom FIC (bei IGLOO2-Geräten) oder vom Cortex-M3 (bei SmartFusion2-Geräten) an COMM_BLK gesendet wird. Sobald der Dienst vom Systemcontroller erkannt wurde, wird die Simulation gestoppt und eine Meldung angezeigt, dass das System Flash*Freeze aufgerufen hat (zusammen mit der ausgewählten Option). Bei Wiederaufnahme der Simulation wird das RXFIFO des COMM_BLK mit der Dienstantwort gefüllt, die aus Dienstbefehl und Status besteht. Es sollte beachtet werden, dass es keine Simulationsunterstützung für den Flash*Freeze-Exit gibt.
3.1.2 Nullstellung
Die Nullstellung ist derzeit der einzige Dienst mit hoher Priorität innerhalb der Systemdienste, die vom COMM_BLK verarbeitet werden. Die Simulation tritt in den Nullisierungszustand ein, sobald die korrekte Dienstanforderung durch das COMM_BLK erkannt wird. Die Ausführung anderer Dienste wird von der Systemsteuerung angehalten und verworfen, und stattdessen wird der Nullisierungsdienst ausgeführt. Sobald die Zeroization-Serviceanforderung erkannt wird, stoppt die Simulation und es wird eine Meldung angezeigt, die angibt, dass das System in die Zeroization eingetreten ist. Manuelle Neustarts der Simulation nach Nullsetzung sind ungültig.
3.2 Datenzeigerdienste
In den folgenden Abschnitten werden verschiedene Arten von Datenzeigerdiensten beschrieben.
3.2.1 Seriennummer
Der Seriennummerndienst schreibt eine 128-Bit-Seriennummer an eine Adressstelle, die als Teil der Dienstanforderung bereitgestellt wird. Dieser 128-Bit-Parameter kann mit einem System Service Simulation Support eingestellt werden file (siehe Seite 22) . Wenn der 128-Bit-Seriennummerparameter nicht innerhalb der definiert ist file, wird eine Standardseriennummer von 0 verwendet. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die den Zielort und die Seriennummer angibt. Der Systemcontroller führt einen AHB-Schreibvorgang an die Adresse mit der Seriennummer durch. Nach Abschluss des Dienstes wird das RXFIFO des COMM_BLK mit der Dienstantwort geladen.
3.2.2 Benutzercode
Der Benutzercodedienst schreibt einen 32-Bit-Benutzercodeparameter an eine Adressstelle, die als Teil der Dienstanforderung bereitgestellt wird. Dieser 32-Bit-Parameter kann über den System Service Simulation Support eingestellt werden file (siehe Seite 22). Wenn der 32-Bit-Parameter nicht innerhalb der definiert ist file, wird ein Standardwert von 0 verwendet. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Nachricht angezeigt, die den Zielort und den Benutzercode angibt. Der Systemcontroller führt einen AHB-Schreibvorgang an der Adresse mit dem 32-Bit-Parameter durch. Nach Beendigung des Dienstes wird das RXFIFO des COMM_BLK mit der Dienstantwort geladen, die den Dienstbefehl und die Zieladresse enthält.
3.3 Datendeskriptordienste
In den folgenden Abschnitten werden verschiedene Arten von Datendeskriptordiensten beschrieben.

3.3.1 AES
Die Simulationsunterstützung für diesen Dienst befasst sich nur mit dem Verschieben der Originaldaten von der Quelle zum Ziel, ohne tatsächlich eine Verschlüsselung/Entschlüsselung der Daten durchzuführen. Die zu verschlüsselnden/entschlüsselnden Daten und die Datenstruktur sollten geschrieben werden, bevor die Dienstanforderung gesendet wird. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die auf die Ausführung des AES-Dienstes hinweist. Der AES-Dienst liest sowohl die Datenstruktur als auch die zu verschlüsselnden/entschlüsselnden Daten. Die Originaldaten werden kopiert und an die in der Datenstruktur bereitgestellte Adresse geschrieben. Sobald der Dienst abgeschlossen ist, werden der Befehl, der Status und die Datenstrukturadresse in das RXFIFO geschoben.
Notiz: Dieser Dienst gilt nur für 128-Bit- und 256-Bit-Daten, und sowohl 128-Bit- als auch 256-Bit-Daten haben unterschiedliche Datenstrukturlängen.

3.3.2 SHA-256
Die Simulationsunterstützung für diesen Dienst befasst sich nur mit dem Verschieben der Daten, ohne die Daten tatsächlich zu hashen. Die SHA 256-Funktion wurde entwickelt, um einen 256-Bit-Hash-Schlüssel basierend auf den Eingabedaten zu generieren. Die zu hashenden Daten und die Datenstruktur sollten an ihre jeweiligen Adressen geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Die innerhalb der SHA-256-Datenstruktur definierte Länge in Bits und Pointer muss korrekt mit der Länge und Adresse der zu hashenden Daten übereinstimmen. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die die Ausführung des SHA 256-Dienstes anzeigt. Anstatt die eigentliche Funktion auszuführen, wird ein Standard-Hash-Schlüssel aus der Datenstruktur in den Zielzeiger geschrieben. Der Standard-Hash-Schlüssel ist hex „ABCD1234“. Um einen benutzerdefinierten Schlüssel einzustellen, gehen Sie zum Abschnitt Parametereinstellung (siehe Seite 23). Nach Abschluss des Dienstes wird das RXFIFO mit der Dienstantwort geladen, die aus dem Dienstbefehl, dem Status und dem SHA-256-Datenstrukturzeiger besteht.
3.3.3 HMAC
Die Simulationsunterstützung für diesen Dienst befasst sich nur mit dem Verschieben von Daten, ohne tatsächlich Hashing an den Daten durchzuführen. Die zu hashenden Daten und die Datenstruktur sollten an ihre jeweiligen Adressen geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Der HMAC-Dienst benötigt einen 32-Byte-Schlüssel zusätzlich zu der Länge in Byte, Quellzeiger und Zielzeiger. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung angezeigt, die die Ausführung des HMAC-Dienstes anzeigt. Der Schlüssel wird gelesen und der 256-Bit-Schlüssel wird von der Datenstruktur zum Zielzeiger kopiert. Nach Abschluss des Dienstes wird das RXFIFO mit der Dienstantwort geladen, die aus dem Dienstbefehl, dem Status und dem HMAC-Datenstrukturzeiger besteht.

3.3.4 DRBG generieren
Die Generierung von Zufallsbits wird von diesem Dienst durchgeführt. Es sollte beachtet werden, dass das Simulationsmodell nicht exakt der gleichen Methodik zur Generierung von Zufallszahlen folgt, die von Silizium verwendet wird. Die Datenstruktur muss korrekt an ihren beabsichtigten Ort geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Die Datenstruktur, Zielzeiger, Länge und andere relevante Daten werden von der Systemsteuerung gelesen. Der DRBG-Erzeugungsdienst generiert einen pseudozufälligen Datensatz der angeforderten Länge (0-128). Die Systemsteuerung schreibt die Zufallsdaten in den Zielzeiger. In der Simulation wird eine Meldung angezeigt, die die Ausführung des DRBG-Erzeugungsdienstes anzeigt. Sobald der Dienst abgeschlossen ist, werden der Befehl, der Status und die Datenstrukturadresse in das RXFIFO geschoben. Wenn die angeforderte Datenlänge nicht im Bereich von 0–128 liegt, wird ein Fehlercode von „4“ (Max Generate) in das RXFIFO geschoben. Wenn die Länge der zusätzlichen Daten nicht innerhalb des Bereichs von 0–128 „Anfrage zu groß“ liegt, wird ein Fehlercode „5“ (maximale Länge zusätzlicher Daten überschritten) in das RXFIFO geschoben. Wenn sowohl die angeforderte Datenlänge für die Generierung als auch die zusätzliche Datenlänge nicht innerhalb ihres definierten Bereichs (0–128) liegen, wird ein Fehlercode von „1“ (katastrophaler Fehler) in das RXFIFO geschoben.

3.3.5 DRBG-Reset
Die eigentliche Reset-Funktion wird durch Entfernen von DRBG-Instanziierungen und Zurücksetzen von DRBG durchgeführt. Sobald die Serviceanforderung erkannt wurde, zeigt die Simulation eine DRBG-Reset-Service-Abgeschlossen-Meldung an. Die Antwort, die den Dienst und den Status enthält, wird in das RXFIFO geschoben.
3.3.6 DRBG-Selbsttest
Die Simulationsunterstützung für den DRBG-Selbsttest führt die Selbsttestfunktion nicht wirklich aus. Sobald die Dienstanforderung erkannt wurde, zeigt die Simulation eine DRBG-Selbsttest-Dienstausführungsnachricht an. Die Antwort, die den Dienst und den Status enthält, wird in das RXFIFO geschoben.
3.3.7 DRBG Instanziieren
Die Simulationsunterstützung für den DRBG-Instanziierungsdienst führt den Instanziierungsdienst nicht tatsächlich durch. Die Datenstruktur muss korrekt an ihren beabsichtigten Ort geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Sobald die Dienstanforderung erkannt wurde, werden die im MSS-Adressraum definierte Struktur und Personalisierungszeichenfolge gelesen. Die Simulation zeigt eine Meldung an, die angibt, dass der DRBG-Instanziierungsdienst mit der Ausführung begonnen hat. Sobald der Dienst abgeschlossen ist, wird die Antwort, die den Dienstbefehl, den Status und den Zeiger auf die Datenstruktur enthält, in das RXFIFO geschoben. Wenn die Datenlänge (PERSONALIZATIONLENGTH) nicht im Bereich von 0–128 liegt, wird ein Fehlercode von „1“ (katastrophaler Fehler) in das RXFIFO für den Status geschoben.
3.3.8 DRBG Nicht instanziieren
Die Simulationsunterstützung für den nicht instanziierten DRBG-Dienst führt nicht tatsächlich den nicht instanziierten Dienst zum Entfernen eines zuvor instanziierten DRBG aus, wie es das Silizium tut. Die Dienstanforderung muss sowohl den Befehl als auch das DRBG-Handle enthalten. Sobald die Dienstanforderung erkannt wurde, wird das DRBG-Handle gespeichert. Die Simulation zeigt eine Meldung an, die angibt, dass der nicht instanziierte DRBG-Dienst initialisiert wurde. Sobald der Dienst abgeschlossen ist, wird die Antwort, die den Dienstbefehl, den Status und das DRBG-Handle enthält, in das RXFIFO geschoben.
3.3.9 DRBG-Reseeding
Aufgrund der simulativen Natur des Systemdienstblocks wird der DRBG-Reseeding-Dienst in der Simulation nicht automatisch ausgeführt, nachdem alle 65535 DRBG-Dienste generiert wurden. Die Datenstruktur muss korrekt an ihren beabsichtigten Ort geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Sobald die Dienstanforderung erkannt wurde, werden die Struktur und zusätzliche Eingangsparameter im MSS-Adressraum gelesen. Eine Meldung, die angibt, dass der DRBG-Reseeding-Dienst mit der Ausführung begonnen hat, wird angezeigt. Die Datenstruktur muss korrekt an ihren beabsichtigten Ort geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Sobald der Dienst abgeschlossen ist, wird die Antwort, die den Dienstbefehl, den Status und den Zeiger auf die Datenstruktur enthält, in das RXFIFO geschoben.
3.3.10 Schlüsselbaum
Die eigentliche Funktion wird in der Simulation für den KeyTree-Dienst nicht ausgeführt. Die Datenstruktur des KeyTree-Dienstes besteht aus einem 32-Byte-Schlüssel, 7-Bit-Optype-Daten (MSB ignoriert) und einem 16-Byte-Pfad. Die Daten innerhalb der Datenstruktur sollten an ihre jeweiligen Adressen geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Nachricht angezeigt, die die Ausführung des KeyTree-Dienstes anzeigt. Der Inhalt der Datenstruktur wird gelesen, der 32-Byte-Schlüssel wird gespeichert und der ursprüngliche Schlüssel, der sich in der Datenstruktur befindet, wird überschrieben. Nach diesem AHB-Schreiben sollte sich der Wert des Schlüssels innerhalb der Datenstruktur nicht ändern, aber AHB-Transaktionen für das Schreiben werden stattfinden. Nach Abschluss des Dienstes wird das RXFIFO mit der Dienstantwort geladen, die aus dem Dienstbefehl, dem Status und dem KeyTree-Datenstrukturzeiger besteht.
3.3.11 Challenge-Response
Die eigentliche Funktion, wie die Authentifizierung des Geräts, wird für den Challenge-Response-Dienst nicht simuliert. Die Datenstruktur für diesen Dienst erfordert einen Zeiger auf den Puffer, um ein 32-Byte-Ergebnis, einen 7-Bit-Optype und einen 128-Bit-Pfad zu empfangen. Die Daten innerhalb der Datenstruktur sollten an ihre jeweiligen Adressen geschrieben werden, bevor die Dienstanforderung an das COMM_BLK gesendet wird. Sobald der Dienst mit der Ausführung begonnen hat, wird eine Nachricht angezeigt, die die Ausführung des Challenge-Response-Dienstes anzeigt. Eine generische 256-Bit-Antwort wird in den in der Datenstruktur bereitgestellten Zeiger geschrieben. Der Standardschlüssel ist als Hex „ABCD1234“ festgelegt. Um einen benutzerdefinierten Schlüssel zu erhalten, überprüfen Sie die Parametereinstellung (siehe Seite 23). Nach Beendigung des Dienstes wird das RXFIFO mit der Dienstantwort geladen, die aus dem Dienstbefehl, dem Status und dem Abfrageantwort-Datenstrukturzeiger besteht.
3.4 Andere Dienste
In den folgenden Abschnitten werden verschiedene andere Systemdienste beschrieben.
3.4.1 Übersichtsprüfung
Die eigentliche Funktion, Digests ausgewählter Komponenten neu zu berechnen und zu vergleichen, wird für den Digest-Check-Service in der Simulation nicht ausgeführt. Diese Dienstanforderung besteht aus Dienstbefehlen und Dienstoptionen (5-Bit-LSB). Sobald der Dienst mit der Ausführung begonnen hat, wird eine Meldung mit Einzelheiten zur Ausführung des Digest-Check-Dienstes zusammen mit den ausgewählten Optionen aus der Anfrage angezeigt. Nach Abschluss des Dienstes wird das RXFIFO mit der Dienstantwort geladen, die aus dem Dienstbefehl und den Pass/Fail-Flags der Digest-Prüfung besteht.
3.4.2 Nicht erkannte Befehlsantwort
Wenn eine nicht erkannte Dienstanforderung an das COMM_BLK gesendet wird, antwortet das COMM_BLK automatisch mit einer nicht erkannten Befehlsnachricht, die in das RXFIFO geschoben wird. Die Nachricht besteht aus dem in COMM_BLK gesendeten Befehl und dem unerkannten Befehlsstatus (252D). Es wird auch eine Anzeigemeldung angezeigt, die angibt, dass eine nicht erkannte Serviceanforderung erfasst wurde. Der COMM_BLK kehrt in einen Ruhezustand zurück und wartet darauf, die nächste Dienstanforderung anzunehmen.
3.4.3 Nicht unterstützte Dienste
Nicht unterstützte Dienste, die auf COMM_BLK eingestellt sind, lösen eine Nachricht in der Simulation aus, die anzeigt, dass die Dienstanforderung nicht unterstützt wird. Der COMM_BLK kehrt in einen Ruhezustand zurück und wartet darauf, die nächste Dienstanforderung anzunehmen. PINTERRUPT wird nicht gesetzt, was anzeigt, dass ein Dienst abgeschlossen wurde. Die aktuelle Liste der nicht unterstützten Dienste umfasst: IAP, ISP, Gerätezertifikat und den DESIGNVER-Dienst.
3.5 Systemdienste-Simulationsunterstützung File
Zur Unterstützung der Systemdienstsimulation ein Text file mit dem Namen „status.txt“ können Anweisungen über das gewünschte Verhalten des Simulationsmodells an das Simulationsmodell übergeben werden. Das file sollte sich im selben Ordner befinden, aus dem die Simulation gestartet wird. Der file kann unter anderem verwendet werden, um bestimmte Fehlerreaktionen für die unterstützten Systemdienste zu erzwingen oder sogar einige Parameter einzustellen, die für die Simulation benötigt werden (zample, Seriennummer). Die maximale Anzahl der unterstützten Zeilen in der „status.txt“ file ist 256. Anweisungen, die nach Zeilennummer 256 erscheinen, werden in der Simulation nicht verwendet.
3.5.1 Erzwingen von Fehlerreaktionen
Der Benutzer kann während des Tests eine bestimmte Fehlerreaktion für einen bestimmten Dienst erzwingen, indem er die Informationen mithilfe der „status.txt“ an das Simulationsmodell weitergibt. file, die in dem Ordner abgelegt werden sollte, von dem aus die Simulation ausgeführt wird. Um Fehlerantworten für einen bestimmten Dienst zu erzwingen, sollten der Befehl und die erforderliche Antwort in derselben Zeile im folgenden Format eingegeben werden:ample, zu Command> ; das Simulationsmodell anweisen, eine MSS-Speicherzugriffsfehlerantwort an den Seriennummerndienst zu erzeugen, lautet der Befehl wie folgt.
Service: Seriennummer: 01
Angeforderte Fehlermeldung: MSS Memory Access Error: 7F
Sie sollten die Zeile 017F in „status.txt“ eingetragen haben file.
3.5.2 Parametereinstellung
Die „status.txt“ file kann auch verwendet werden, um einige Parameter einzustellen, die in der Simulation benötigt werden. Als Example, um den 32-Bit-Parameter für den Benutzercode zu setzen, muss das Format der Zeile in dieser Reihenfolge sein: <32 Bit BENUTZERCODE>; wobei beide Werte hexadezimal eingegeben werden. Um den 128-Bit-Parameter für die Seriennummer zu setzen, muss das Format der Zeile in dieser Reihenfolge sein: <128 Bit Seriennummer [127:0]> ; wobei beide Werte hexadezimal eingegeben werden. Um den 256-Bit-Parameter für den SHA 256-Schlüssel einzustellen; Das Format der Zeile muss in dieser Reihenfolge sein: <256-Bit-Schlüssel [255:0]>; wobei beide Werte hexadezimal eingegeben werden. Um den 256-Bit-Parameter für den Challenge-Response-Schlüssel zu setzen, muss das Format der Zeile in dieser Reihenfolge sein: <256-Bit-Schlüssel [255:0]>;
wobei beide Werte hexadezimal eingegeben werden.
3.5.3 Gerätepriorität
Systemdienste und COMM_BLK verwenden ein System mit hoher Priorität. Derzeit ist der einzige Dienst mit hoher Priorität die Nullstellung. Um einen Dienst mit hoher Priorität auszuführen, während ein anderer Dienst ausgeführt wird, wird der aktuelle Dienst angehalten und der Dienst mit höherer Priorität wird an seiner Stelle ausgeführt. Der COMM_BLK wird den aktuellen Dienst verwerfen, um den Dienst mit höherer Priorität auszuführen. Wenn mehrere Dienste ohne hohe Priorität gesendet werden, bevor ein aktueller Dienst abgeschlossen ist, werden diese Dienste in das TXFIFO eingereiht. Sobald der aktuelle Dienst abgeschlossen ist, wird der nächste Dienst im TXFIFO ausgeführt.

Microsemi gibt keine Gewährleistung, Zusicherung oder Garantie in Bezug auf die hierin enthaltenen Informationen oder die Eignung seiner Produkte und Dienstleistungen für einen bestimmten Zweck, noch übernimmt Microsemi irgendeine Haftung, die sich aus der Anwendung oder Verwendung eines Produkts oder einer Schaltung ergibt. Die hierunter verkauften Produkte und alle anderen von Microsemi verkauften Produkte wurden begrenzten Tests unterzogen und sollten nicht in Verbindung mit unternehmenskritischen Geräten oder Anwendungen verwendet werden. Alle Leistungsspezifikationen gelten als zuverlässig, werden jedoch nicht verifiziert, und der Käufer muss alle Leistungs- und sonstigen Tests der Produkte allein und zusammen mit oder installiert in Endprodukten durchführen und abschließen. Der Käufer darf sich nicht auf von Microsemi bereitgestellte Daten und Leistungsspezifikationen oder Parameter verlassen. Es liegt in der Verantwortung des Käufers, die Eignung aller Produkte unabhängig zu bestimmen und diese zu testen und zu verifizieren. Die hierunter von Microsemi bereitgestellten Informationen werden „wie besehen, wo sie sind“ und mit allen Fehlern bereitgestellt, und das gesamte mit diesen Informationen verbundene Risiko liegt vollständig beim Käufer. Microsemi gewährt keiner Partei ausdrücklich oder stillschweigend Patentrechte, Lizenzen oder andere IP-Rechte, weder in Bezug auf diese Informationen selbst noch auf alles, was in diesen Informationen beschrieben wird. Die in diesem Dokument bereitgestellten Informationen sind Eigentum von Microsemi, und Microsemi behält sich das Recht vor, jederzeit ohne Vorankündigung Änderungen an den Informationen in diesem Dokument oder an Produkten und Dienstleistungen vorzunehmen.
Microsemi, eine hundertprozentige Tochtergesellschaft von Microchip Technology Inc. (Nasdaq: MCHP), bietet ein umfassendes Portfolio an Halbleiter- und Systemlösungen für Luft- und Raumfahrt, Verteidigung, Kommunikation, Rechenzentren und Industriemärkte. Zu den Produkten gehören hochleistungsfähige und strahlungsfeste analoge integrierte Mischsignalschaltungen, FPGAs, SoCs und ASICs; Power-Management-Produkte; Timing- und Synchronisationsgeräte und präzise Zeitlösungen, die den weltweiten Zeitstandard setzen; Sprachverarbeitungsgeräte; HF-Lösungen; diskrete Komponenten; Speicher- und Kommunikationslösungen für Unternehmen; Sicherheitstechnologien und skalierbarer Anti-Tamper Produkte; Ethernet-Lösungen; Power-over-Ethernet-ICs und -Midspans; sowie kundenspezifische Designmöglichkeiten und Dienstleistungen. Microsemi hat seinen Hauptsitz in Aliso Viejo, Kalifornien, und beschäftigt weltweit etwa 4,800 Mitarbeiter. Erfahren Sie mehr unter www.microsemi.com.

Microsemi-Hauptsitz
Ein Unternehmen, Aliso Viejo,
CA 92656 USA
Innerhalb der USA: +1 800-713-4113
Außerhalb der USA: +1 949-380-6100
Umsatz: +1 949-380-6136
Fax: +1 949-215-4996
E-Mail: Vertrieb.support@microsemi.com
www.microsemi.com
© 2018 Microsemi. Alle Rechte vorbehalten. Microsemi und das Microsemi-Logo
sind Warenzeichen der Microsemi Corporation. Alle anderen Warenzeichen und Service
Marken sind Eigentum ihrer jeweiligen Inhaber.

Dokumente / Ressourcen

Microsemi UG0837 Simulation von IGLOO2- und SmartFusion2-FPGA-Systemdiensten [pdf] Benutzerhandbuch UG0837, UG0837 Simulation von IGLOO2- und SmartFusion2-FPGA-Systemdiensten, Simulation von IGLOO2- und SmartFusion2-FPGA-Systemdiensten, Simulation von SmartFusion2-FPGA-Systemdiensten, Simulation von FPGA-Systemdiensten, Simulation von Diensten

Verweise

• Bedienungsanleitung