5. Summary

5.1 The Practical Work

Basis of this work was the creation of an efficient hardware platform for evaluation and test purposes of the current Barracuda MCU project. Main requirements are on the one hand maximum flexibility in implementing different module configurations to the same evaluation platform and on the other hand a design integration which is as close as possible to the MCU's target architecture. A close design integration is mandatory, because otherwise a realistic prediction of the functionality and the timing of the resulting technology mapped design would be impossible.

In order to provide a powerful and reconfigurable evaluation platform for the MCU, a hardware realization using standard, in-circuit reprogrammable FPGAs (Field Programmable Gate Array) has been chosen. The complexity of available devices allows the integration of a huge amount of logic functions in terms of registers or combinational circuitry. But the existing trade-off between evaluation flexibility and statical code integration is obvious. In addition it is impossible to integrate any analog design parts into the used FPGA devices up to now. So all analogue components of the design have been substituted or removed.

In this design approach the relevant MCU modules, consisting of CORE and 10 Interface modules, were split into separate FPGAs because the number of logic cell required exceeded the size of one FPGA. Since the Barracuda modules were not completed at begin of this work, existing modules from the earlier JUPITER project (predecessor of Barracuda) have been used for evaluation and size estimation of the FPGAs. Most of the JUPITER modules had first to be prepared for FPGA emulation. All analog portions of this modules had to be substituted by synthesizable Verilog RTL description e.g. special driver cells, hard macros. Some modules internal ROM has been emulated by the integrated on-chip RAM/ROM in the chosen ALTERA FPGA FLEX 10K series.

The complete evaluation platform consist of all synthesizable Barracuda modules. The complete internal MCU bus as well as the internal IP bus have been routed to connectors. This makes interconnections between the different FPGA, former internal nets scannable on the board. Because of this structured hardware approach, the resulting evaluation platform provides enhanced debug features. In addition, design changes within single modules of the MCU are limited to a closer area. Hence the timing of the other modules will not be substantially affected. It is known that this is a quite critical effect on designs mapped to ALTERA FPGAs.
The complexity of the existing modules requires a lot of resources within each FPGA. FPGA emulation of the CORE requires the largest member of the ALTERA EPF10KE family (EPF10KE200) with a device usage of about 70%. The mapped design was synthesized without any optimization constraints set. Therefore these results represent an upper limit for the required FPGA ressources. The maximum clock speed for the CORE module was in the acceptable range of about 8 MHz, as the real Barracuda chip will run at 20 MHz.

Pin assignments have been used for grouping busses and placing each pin to its optimal place on the board to minimize routing expense. Furthermore, pin assignments were necessary to reserve unused pins for future use. Otherwise, if not assigned, all unnecessary input pins are ignored by FPGA compiler. Most FPGA's have some unused pins. Unfortunately a new pin name can not be declared, only signals that occur in the design file can be assigned. Reserved pin assignment had to be done at board level using signal assignments as described in chapter 5.

The Barracuda modules were completed at the end of this thesis. Even though a generic approach had been used, extensive changes were necessary to complete the project. After receiving the final Barracuda, three weeks bevore the end of the thesis, some integral parts of the project had to be reworked. This includes:

All final modules passed FPGA synthesis successfully without changes in source-code.
It turned out that both the number of required logic cells and the number of pins for the final design, owing to some additional interrupt pins and basic improvements of functionality, exeed the assumptions made analyzing the old JUPITER modules. For this reason, we had to replace FPGA#3 and FPGA#4 (EPF10KE130, 130.000 logic cells) by bigger ones (EPF10KE200, 200.000 logic cells). The changed FPGA had basically the same pin-out (240 pins) but there were less user I/O pins available. The number of required pins of the CORE module in FPGA#1 exeeded the number of pins available. First, we intended to reserve dedicated user I/O pins of the FPGA (CLKUS, RDYnB, INTDONE, LOCK), which can be used for advanced features. This could not be realized for FPGA#1. Since the smallest element on the board determines the circuitry, all other FPGA have been replaced by ones without advanced features. This required the change of practically all pin assignments of each FPGA, recompilation and the generation of new schematics. While updating the board-layout, we have reoptimized each FPGA pin layout.
At this stange, the generic approach using the developed PCB design tool to generate complete schematics and board layout proved to be powerful and has saved a lot of time. Apdating schematics after replacing all used FPGA could under circumstances require the complete reentry of the circuitry and would require weeks. This time could be saved, since all commands and information required to configure PCBscript to generate the schematics of the Barracuda board had already been entried into synthesis script. It was a matter of minutes to change some lines in the script that replaces all, symbols, packages, all nets and the adapted board layout.

Following goals have been achieved: all synthesizable Barracuda modules have been synthesized with the Flex10k library and successfully mapped to separated FPGAs. In a first diagnostic run the designs meet the timing requirements. The maximum clock speed for the Barracuda design lies in the range of about 1 to 8 MHz.
Second, the complete Schematics of the prototype board have been entried using the developed PCB design tool. There are small changes necessary to adapt the circuitry to its final configuration.
Third, the pin layout of each FPGA has been optimized to the board layout as shown in Appendix D.
With these results the aimed target has been reached in its integral parts and the FPGA based design flow has been worked out completely.

To sum up, we can say that Motorola now will be able to fabricate the evaluation board. With the development of the SRAM emulator module, the Barracuda is prepared to work successfully on the prototype board.

5.2 Suggestions for Further Work

The next steps must improve the timing for the Barracuda design by means of special constraints for synthesis and FPGA place-and-route. The PCB has to be layouted, manufacured, mounted and finally tested.

6 Zusammenfassung und Ausblick

Die Basis dieser Arbeit war die Schaffung einer effizienten Evaluierungs Plattform zum Test und Diagnose des laufenden Barracuda MCU Projekts. Die wesentlichen Anforderungen waren zum einen maximale Flexibilität bei der Implementierung von verschieden Modulkonfigurationen auf der gleichen Hardware Plattform und eine Design Integration, die möglichst genau der MCU Architektur entspricht. Eine realistische Design Integration ist obligatorisch, da andernfalls eine realistische Vorhersage der Funktionalität und des Timings des auf die entgültige Technologie gemappten Designs, nicht möglich wäre.

Um eine leistungsfähige rekonfigurierbare Evaluierungs Plattform für die MCU zur Verfügung zu stellen, wurden in-circuit Reprogrammierbare FPGAs (Field Programmable Gate Array) gewählt. Was Register oder Kombinatorik betrifft, erlaubt die Komplexität der zur Verfügung stehenden FPGAs die Integration einer großen Menge von Logik Funktionen. Jedoch gibt es offensichtlich immer einen Kompromiß zwischen Flexibilität und der Integration von statischem Code. Weiterhin ist es bis jetzt nicht möglich, analoge Design Elemente in die bestehenden FPGA zu integrieren. Daher mußten alle analogen Komponenten des Designs ersetzt oder herausgenommen werden.

Bei diesem Ansatz wurden die relevanten MCU Module, die aus dem CORE und 10 Interface Modulen bestehen auf separate FPGAs aufgeteilt, da die Zahl der benötigten Logikzellen die Größe eines FPGAs übersteigt. Da die Barracuda Module zu Beginn dieser Arbeit noch nicht fertig waren, wurden bestehende Module von einem früheren Projekt, dem JUPITER Projekt (Vorgänger vom Barracuda), zur Evaluierung und Abschätzung der Größe der FPGAs verwendet. Die meisten JUPITER Module mußten erst für die FPGA Emulation vorbereitet werden. Alle analogen Teile, wie spezielle Treiber, Hard Makros, mußten durch synthetisierbare Verilog RTL Modelle ersetzt werden. Das interne ROM einiger Module wurde emuliert durch das interne RAM/ROM der gewählten ALTERA Flex10k FPGAs.

Die gesamte Evaluierungs Plattform besteht aus allen synthetisierbaren Barracuda Modulen. Der vollständige interne MCU Bus, sowie der interne IP Bus sind auf Steckerleisten geführt. Dies erlaubt die Diagnose der Verbindungen zwischen den FPGAs, die eigentlich MCU interne Verbindungen sind. Durch diesen Ansatz bietet die resultierende Hardware weitaus bessere Möglichkeiten zur Fehlersuche. Zusätzlich bleiben Designänderungen innerhalb einzelner Module auf eine kleinere Fläche beschränkt. Daher wird das Timing anderer Module nicht wesentlich beeinflußt. Es ist bekannt, daß dies ein ziemlich kritischer Effekt für Designs ist, die auf ALTERA FPGAs implementiert werden. Die Komplexität der existierenden Module erfordert viele Ressourcen innerhalb jedes FPGAs. Die FPGA Emulierung des COREs erfordert das größte Mitglied der ALTERA EPF10KE Familie (EPF10KE200) mit einer Ausnutzung des Chips von über 70%. Das auf den FPGA portierte Design wurde ohne Optimierungs Konstraints synthetisiert. Daher repäsentieren diese Ergebnisse ein oberes Limit für die benötigten FPGA Ressourcen. Die maximal mögliche Clock Frequenz des CORE Moduls lag in einem akzeptablen Bereich von rund 8 MHz, wobei der echte Barracuda Chip mit 20 MHz arbeiten wird.

Nachdem drei Wochen vor dem Ende der Diplomarbeit die entgültigen Barracuda Module kamen, mußten einige wesentliche Teile des Projektes noch einmal gemacht werden. Dies sind:

Alle entgültigen Module liefen ohne Änderungen im Source-Code erfolgreich durch die Synthese.
Es zeigte sich, daß sowohl die Zahl der benötigten Logik Zellen und die Zahl der Pins für das entgültige Design, wegen einiger zusätzlicher Interrupt Pins und grundlegenden Erweiterungen der Funktionalität, die bei der Analyse der alten JUPITER Module gemachten Annahmen übersteigt. Aus diesem Grund mußte der Autor FPGA#3 und FPGA#4 (EPF10KE130, 130.000 Logik Zellen) durch größere (EPF10KE200, 200.000 Logik Zellen) ersetzen. Die geänderten FPGA hatten im Grunde das gleiche Pin-Out (240 Pins), jedoch waren weniger User I/O Pins verfügbar. Die Zahl der benötigten Pins des CORE Moduls in FPGA#1 überstieg die Zahl der verfügbaren Pins. Der Autor beabsichtigte zuerst die Reservierung von speziell dafür vorgesehenen User I/O Pins der FPGA (CLKUS, RDYnB, INTDONE, LOCK), die für höhere Funktionen benutzt werden können. Dies konnte Für FPGA#1 jedoch nicht umgesetzt werden. Da das kleinste Element auf dem Board die Schaltung bestimmt, mußten alle anderen FPGAs ebenfalls ersetzt werden durch solche ohne zusätzliche Funktionen. Dies erforderte die Änderung praktisch aller Pin-Zuweisungen jedes FPGAs, die Neukompilierung und die Entwicklung neuer Schaltpläne. Gleichzeitig mit der Aktualisierung des Board Layouts is das Pin Layout jedes FPGA optimiert worden.
An dieser Stelle erwies sich der generische Ansatz, der das eigens entwickelte PCB Design Tool nutzt, um die kompletten Schaltpläne zu generieren, als sehr leistungsfähig und hat viel Zeit gespart. Das Aktualisieren der Schaltpläne nach den Ersetzen aller benutzten FPGAs kann unter Umständen das komplette Neuzeichnen der Schaltpläne erfordern und würde Wochen in Anspruch nehmen. Diese Zeit konnte eingespart werden, da alle benötigten Kommandos und Informationen um PCBscript so zu konfigurieren, daß die Schaltpläne des Barracuda Boards erzeugt werden, bereits in das Synthese Script eingetragen waren. Es war eine Sache von Minuten, einige Zeilen in dem Script zu ändern, welche die entsprechende Schaltungssymbole und Gehäuse, alle Netze ändern und das Board Layout anpaßt.

Die folgenden Ziele wurden erreicht: alle synthetisierbaren Barracuda Module wurden synthetisiert mit der Flex10k Zell Bibliothek und erfolgreich auf verschiedenen FPGAs implementiert. Nach einer ersten Diagnose erfüllen die Designs die Anforderungen an das Timing. Die maximale Clock Frequenz des Barracuda Designs liegt im Bereich von 1 bis 8 MHz.
Zweitens wurden die kompletten Schaltpläne des Prototype Boards gezeichnet unter Verwendung des entwickelten PCB Design Tools. Es sind noch kleine Änderungen nötig, um die Schaltung an die entgültige Konfiguration anzupassen.
Drittens wurde das Pin Layout von jedem FPGA auf das Board Layout optimiert, daß in Anhang D gezeigt ist.
Mit diesen Ergebnissen ist das gesetzte Ziel in wesentlichen Punkte erreicht und es wurden alle Punkte des auf FPGA Entwicklung basierende Projekt Plans bearbeitet.

Zusammenfassend kann man sagen, daß Motorola nun in der Lage ist, das Evaluation Board zu bauen. Mit der Entwicklung des SRAM Emulator Moduls ist der Barracuda vorbereitet, um erfolgreich auf dem Prototype Board zu arbeiten.

Im nächsten Schritt muß das Timing des Barracuda Designs durch Setzen von Konstraints für die Synthese und das FPGA place-and-route verbessert werden. Für das Board muß das Layout vervollständigt und verfeinert werden. Es hat sich gezeigt, daß das Layout stark busorientiert ist und lange Leitungslängen für die internen MCU-Bus Signale auf dem Board bei der gewählten Plazierung der FPGAs unvermeidlich sind. Bei der vorgesehenen Betriebsfrequenz von bis zu 8 MHz kann das zu Problemen führen. Eine Alternative wäre, die FPGAs sowohl auf der Top-, als auch auf bder Buttom-Layer zu plazieren. Dies erfordert die komplette Neukonfigurierung des FPGA Pin-Layouts. Dies sollte jedoch mit PCBScript problemlos innerhalb von wenigen Tagen möglich sein. Schließlich muß das Board hergestellt, bestückt und getestet werden.