FPGA Multicore Emulation

Unsere Aufgabe bestand darin, eine Platine rund um den leistungsstarken Virtex6 550T FPGA mit fast 550.000 konfigurierbaren Gates und einem 1760-Ball-BGA-Gehäuse zu entwickeln. Das Board musste das FPGA mit Peripheriegeräten ausstatten, um seine Nützlichkeit für die Evaluierung des „weichen“ Mikroprozessors zu erweitern, einschließlich eines LCD-Bildschirms, CAN-Transceivern, FlexRay-Schnittstellen, Ethernet und ADCs. Das Board benötigte außerdem einen „System Manager“, der ein leistungsfähiger Infineon TC1797 TriCore Baustein sein sollte - ein Vorgänger des „Soft“-FPGA-Mikrocontrollers - um die Anzeige des FPGA-Images zu verwalten. Das System würde dann für die Entwicklung der Debugger und Flash-Programmierer selbst verwendet.

Auf der Softwareseite muss der „System Manager“ auf mehrere FPGA-Images zugreifen können, die lokal auf einer SD-Karte gespeichert sind, und ein Image direkt über die JTAG-Verbindung des FPGA hochladen können. Außerdem muss er dem Benutzer die Möglichkeit bieten, das FPGA-Image (vor dem Hochladen) auszuwählen und Konfigurationsoptionen wie die zu emulierende Prozessorgeschwindigkeit festzulegen.

Zudem sollte der „System Manager“ einen Infineon CIC61508-Safety-Monitor-Baustein emulieren – einen intelligenten Watchdog, der in Verbindung mit vorhandenen TriCores Teil des Infineon PRO-SIL SafeTcore-Systems ist.

Auswahl der richtigen FPGA-I/O-Bänke und Verarbeitung von Resetsignalen

Ein Großteil des Designs war standardisiert - Schnittstellen für Kommunikationsperipheriegeräte, mehrere Netzteile mit unterschiedlichen Spannungen und Ausgängen usw. Die interessanteren Teile konzentrierten sich auf die Auswahl der richtigen FPGA-I/O-Bänke, um die korrekte Übertragung von Hochgeschwindigkeitssignalen und Taktsignalen zu ermöglichen, sowie auf die Verarbeitung mehrerer Resetsignale aus verschiedenen Quellen. Dies ist häufig ein Problem bei Multiprozessorsystemen und gerade von Systemen, bei denen ein Baustein (das FPGA) zwei Betriebsmodi hat, z. B. Programmierung und Emulation.

Herausforderungen bei der Verwaltung von Signalspannungspegeln und Neuheit des Systems

Darüber hinaus bestand die Herausforderung darin, mehrere Signalspannungspegel mit hoher Geschwindigkeit und manchmal bidirektional zu verwalten, um ein 1,0-V-FPGA mit 2,5-V-, 3,3-V- und 5-V-Systemen zu verbinden. Daher war die Auswahl der Buswandler von entscheidender Bedeutung für das Design.

Es wurde ein neuartiges System benötigt, um das FPGA für ungewöhnlichere Aufgaben, wie z.B. das Einfügen von Störungen in das Gate-Array, das Starten/Stoppen der Simulation usw., steuern zu können. Dies bedeutete, dass der „System Manager“ neben der Bereitstellung auch die JTAG-Signale des FPGA emulieren musste. Dies ermöglicht alle Arten von neuen Möglichkeiten, die auf normaler Zielhardware nicht möglich sind, wie z.B. die Simulation von driftenden oder zitternden Uhren, „Flash“ Wertänderungen, etc. Grundsätzlich ist es möglich, die Zeit zu beschleunigen, zu verlangsamen oder anzuhalten!

Eine Besonderheit des Systems besteht darin, dass vor der Programmierung das FPGA in einer bestimmten Weise behandelt werden muss und die Takte und Signale von den I/O-Pins isoliert werden müssen. Sobald der Baustein jedoch programmiert ist, wird er praktisch zu einem Multicore-Mikroprozessor, was bedeutet, dass das Board selbst in der Lage ist, beide Arten von "Personal" zu verarbeiten.

Hardware ist nichts ohne Software - umso mehr, wenn es sich um virtuelle Hardware handelt. Die System Manager Software konnte separat auf einem Standard Infineon TC1797 TriBoard Development Kit entwickelt werden, was es uns ermöglichte, das SD Card Filesystem, die CIC61508 Safety Monitor Emulation und die Virtex FPGA JTAG Verbindung mit einem kompatiblen Low-End FPGA System zu implementieren und zu testen.

Herausforderung und Lösung bei der Implementierung

Die am schwierigsten zu implementierende Software war die Programmierung und die JTAG-Schnittstelle zum FPGA, da dies normalerweise in einem Debug/Programmier-Tool (CPLD) durchgeführt wird. Dank der Rechenleistung und der Echtzeitfähigkeit des TC1797 konnten relativ hohe Taktraten bei gleichzeitig guter Flexibilität erreicht werden.

Die Software für das Multicore-Gerät konnte natürlich nicht geschrieben werden, bevor das Meridian-Board fertig war, denn genau das ist der Grund für seine Existenz: die Software zu entwickeln und die Hardware zu testen, bevor das reale Silizium auf den Markt kommt. Außerdem war zu diesem Zeitpunkt nur die Entwicklung von Basistreibern geplant, da das Board zunächst nur von Infineon zur Demonstration des Silizium-IP verwendet werden sollte, um später höherwertige Treiber entwickeln zu können.

Wie bei allen Projekten dieser Komplexität war die Definition der Spezifikation von entscheidender Bedeutung, da es aufgrund der sehr hohen Flexibilität, die die Plattform bietet, möglich gewesen wäre, Zusätze sowohl zur Hardware als auch zur Software hinzuzufügen. Ein Aspekt des Hardware-Designs, dem nicht genug Aufmerksamkeit geschenkt werden kann, ist die Stromversorgung. So verursachte der stark schwankende Strombedarf der vielen Onboard-SRAMs zunächst Probleme für unser Strombudget, was zu einer geringfügigen Änderung für spätere Boards führte.

Die Minimierung der PCB-Schichten ist häufig eine gute Praxis, aber in diesem Fall war es wegen der hochwertigen Platine ratsam, mehrere Masseschichten zu verwenden. Ebenso war es wichtig, die Leiterbahnlängen und Impedanzen anzupassen, insbesondere bei den Speicherverbindungen. So konnten die Signale sauber und bei Bedarf getrennt gehalten werden.

Multicore-Code treibt CAN-Netzwerke, Motoren, LEDs und TFT-Bildschirme an, noch bevor serienmäßiges Silizium verfügbar ist

Die Meridian-Plattform hat es Infineon ermöglicht, Softwaretreiber und Anwendungsbenchmarks zu schreiben, um die Architekturbausteine eines Mikroprozessors zu evaluieren, was normalerweise aufgrund der für die Simulation der externen Umgebung erforderlichen Modellierung nicht möglich ist. Die Simulation der internen IP gibt es schon seit vielen Jahren, sie erfordert jedoch eine enorme Rechenleistung, da ganze Cluster dedizierter Maschinen viele Stunden lang laufen müssen, um ein Ergebnis zu erhalten.

Mit Hilfe des Meridian-Boards war es möglich, das Multicore-IP Partnern zur Verfügung zu stellen, die normalerweise keinen Zugang zu den erforderlichen Rechenfarmen hätten, um ihren spezifischen Anwendungsfall zu simulieren. Durch die frühzeitige Verfügbarkeit des IP in einer elektrisch repräsentativen Umgebung konnten reale externe Sensoren, Aktoren und Kommunikationskanäle integriert werden, wodurch die Simulationszeit von Stunden auf Echtzeit reduziert wurde, da die FPGA-basierte Simulation mit bis zu 30 MHz läuft. Dies ist ausreichend, um externe Busschnittstellen, Kommunikations- und Signalerzeugungsperipherie in einer realen Umgebung genau zu evaluieren.