Mehr Effizienz im Design: Hard- und Software als Tandem
Fortsetzung des Artikels von Teil 3
Plattform für Entwicklung, Feldtest und Kleinserie
Die NEON-Instruktionen werden entsprechend ihrer Reihenfolge ausgegeben und abgelegt. Bei einer Datenverarbeitungs-Anweisung handelt es sich stets um einen NEON-Integer-Befehl oder um einen NEON-Gleitkomma-Befehl. Die NEON Engine im Cortex A8 gibt niemals zwei Datenverarbeitungs-Instruktionen gleichzeitig aus, um den Mehraufwand an Chipfläche durch die dann notwendige Vorhaltung zweier Datenverarbeitungs-Blöcke zu vermeiden. Außerdem verhindert man hierdurch, dass durch das Multiplexing der Lese- und Schreibregister-Ports Signalpfade mit kritischem Timing und zusätzlicher Komplexität entstehen.
Der Integer-Datenpfad der NEON Engine enthält drei Pipelines, nämlich die „Integer Multiply/Accumulate Pipeline“ (MAC), die „Integer Shift Pipeline“ und die „Integer ALU Pipeline“. Eine „Load-Store/Permute Pipeline“ ist für sämtliche Load/Store-Operationen der NEON Engine, für Datentransfers von und zur NEON Integer Einheit sowie für Datenpermutations-Operationen (z.B. Interleave und De-Interleave) zuständig. Der „NEON-Floating-Point“-Datenpfad (NFP) ist mit zwei Pipelines ausgestattet, nämlich einer Multiplizier-Pipeline und einer Addier-Pipeline. Die separate VFPLite-Einheit ist eine ohne Pipeline ausgeführte Implementierung der ARM-VFPv3-Gleitkomma-Spezifikation und ausgelegt für IEEE-754-konforme Gleitkomma-Unterstützung mit mittlerer Rechenleistung. Die VFPLite-Einheit sorgt für Abwärtskompatibilität zu existierendem ARM-Gleitkomma-Code und dient zur Bereitstellung von Arithmetik-Funktionen mit einfacher und doppelter Genauigkeit gemäß IEEE 754. Bild 4 gibt einen Überblick über die verschiedenen NEON-Pipelines.
Jobangebote+ passend zum Thema
Der Schritt zur endgültigen Hardware für die Serie ist die letzte große Hürde. Folgende Szenarien sind denkbar:
- Das Entwicklungsboard selbst kann weiter als Applikationsplattfom genutzt werden: Dies wird nur selten möglich sein, da bei einem Einsatz im Feld andere Randbedingungen herrschen als im Labor.
- Eine abgespeckte Version des Entwicklungsboards wird verwendet: Dies ist ein Ansatz, der für den ersten Test im Feld oder für Kleinserien denkbar ist. Dabei werden ein Großteil des Designs des Entwicklungsboards wiederverwendet und Peripherie-Elemente ausgelassen, die von der Applikation nicht benutzt werden. Mit einem Gehäuse versehen, kann diese Hardware dann im Feld verwendet werden.
- Die endgültige Hardware wird selbst entwickelt: Dies ist wohl die anspruchsvollste Variante, da nun die Frage vom Anfang wieder auftaucht, wie denn die Software und die nun zu entwickelnde Hardware zueinander passen. Kann für die Entwicklung der Hardware das Designsystem genutzt werden, das auch bei der Software-Entwicklung eingesetzt wurde, so ist dies ein enormer Vorteil. Liegen darüber hinaus noch die Designdaten der Entwicklungsplattform vor, können diese in Form von Referenzdesigns in die eigene Hardware übertragen werden. Dies ist ein von der Innovation-Station unterstütztes Konzept: Alle Daten zum NanoBoard liegen vor und können leicht wiederverwendet werden, so dass die Boarddesign-Fähigkeiten von Altium-Designer für die Erstellung der Embedded-Hardware eingesetzt werden können. F. Krämer/go
- Mehr Effizienz im Design: Hard- und Software als Tandem
- Die Cortex-A8-Mikroarchitektur im Detail
- Mehr Effizienz im Design: Hard- und Software als Tandem
- Plattform für Entwicklung, Feldtest und Kleinserie
- Zellenbasierte Implementierung mit Semicustom-Techniken
