Ich baue sowohl mit den kleinsten, kosteneffektiven Chips, also z.B. den erwähnten 70xx, als auch mit dem größten Ultrascale mit HBM (der hat 32 integrierte DDR4-RAMs + Controller, die parallel 8192 Bit @ 400 MHz machen). Letztere booten aufgrund der Größe selbst mit Quad-SPI auf höchstem Temp sehr lange und ja, das Betriebssystem und das Einrichten der Peripherie macht da eine Menge aus, wenn da viel zu tun ist.
Allerdings ist es genau so, dass wir auf den kleinen Chips meistens ebenfalls kein OS drauf machen, weil das ein Zeitfresser ist. Die kleinen Chips stecken ja oft in den kostenkritischen designs und da will man nichts verschwenden. Ein universelles OS braucht es im Grunde bekanntlich nur, wenn man schnell und oft viel herumkonfigurieren möchte, weil sich die SW öfters ändert, mehrere ähnliche Geräte bestückt werden sollen oder weil andere Anbieter oder der Benutzer da etwas Unbekanntes dazuladen wollen. Wenn ich jedoch meine Prozesse und Anforderungen genau kenne, die Software also abgeschlossen ist, braucht es das nicht und man kann ein massiv-sequenzielles System aufziehen, das sehr viel echtzeitfähiger ist, weil die Abläufe festliegen.
Was jetzt Musiksynthesizer angeht, ist anders herum gedacht, ein Linux allerdings durchaus sinnvoll, um z.B. User-Funktionen wie GUI und vor allem Ethernet und USB abzudecken, weil die meisten benötigen Funktionen im OS schon drin sind und weitere wie Fileverwaltung auf SD-Karten damit einfach aufzubauen ist. Das ist z.B. etwas, was bei meinem noch fehlt. Für solche kombinierten Funktionen ist ein Zynq wie geschaffen, weil er neben den ARM-CPUs, welche die C-Software abwickeln, noch genug programmierbare FPGA-Komponenten hat, um die low-level-Sachen zum USB-Chip, der SD-Karte und den Datenverkehr mit ADC und DAC abzudecken. Der Chip ist - für das was er kann- relativ billig und Vieles ist eben von Haus aus schon mitgeliefert. Man muss es nur zusammenfügen.
Ich nehme an, dass der MUSE auch so gestrickt sein dürfte. USB ist wie TCP/IP ist funktioniell komplex und mit C-Routinen einfach zu realisieren. Das tut man sich im FPGA nur an, wenn das zwingend erforderlich ist oder man es optimal und solide braucht, z.B. wegen TMR in SIL-Bereichen. Für kleine C-Anwendungen im FPGA hätte es dann ja auch noch Soft-Cores wie den MicroBlaze, auf den man sogar ebenfalls Linux draufbringen kann, wenn nötig.
Was die konkrete Umsetzung im MUSE angeht, wäre es jetzt interessant, ob und welches OS er verwendet. Wie schon angedeutet, ist die vom Chip-Hersteller Xilinx (nun AMD) mitgelieferte Version des PetaLinux nicht so der Brüller und in vielen Punkten auch recht buggy, wie übrigens die gesamte AXI-toolchain des Herstellers, mit der solche Systeme gebaut werden. Wir haben da öfters Probleme und daher wird das in sicherheitskritischen Bereichen regelmäßig gemieden bzw. Komponenten händisch nachprogrammiert und ersetzt.
Das kann man sich im Consumerbereich bei so geringen Absatzzahlen natürlich nicht leisten. Daher muss man als Nutzer eine Kröte schlucken, wenn es preislich akzeptabel bleiben soll. Solange es nur der boot-Vorgang ist und die Kiste nachher stabil läuft und ihre Sachen macht, ist das ja auch ok. Man bekommt auf diese Weise viel Funktion für wenig Geld, weil da nur ein geringer Anteil an Entwicklungskosten entsteht im Vergleich zur eigentlichen Klangerzeugerelektronik.
Mein persönlicher Eindruck der gesamte Szene der Industrie hinsichtlich FPGA, SoC, Linux im Bezug auf Entwicklungszeit- und Kosten ist allerdings der, dass da immer mehr "Baukasten" betrieben wird und immer geringer befähigtere Leute in immer kürzeren Zeiten sich sehr umständliche und komplexe Systeme zusammenklicken, die infolge der vielen Ebenen und black boxes immer mehr versteckte Probleme machen, die am Ende zu mehr Zeitaufwand und unkalkulierbaren Risiken führen, bis wirklich alles sicher funktioniert:
Die Denke, dass man durch C-Software und VHDL alles an so einem SoC programmierbar hat und daher jederzeit Fehler noch nacher fixen kann, ist blanke Theorie! Einen großen Anteil der SW hat man bei einem Baukasten und vielen vorgefertigten Komponenten selber nicht im Griff, sondern ist auf den Hersteller angewiesen. Je umfangreicher die werden, desto größer ist die Wahrscheinlichkeit, das irgendwas mit etwas anderem nicht zusammenspielt oder irgendeine Komponenten eine Macke hat, die man nicht fixen kann, sondern einen work around anbringen muss. Da haben schon öfters Abteilungen ganze Projekte in die Sackgasse gefahren und mussten irgendwann neu ansetzen, um nicht in spätere Garantie- und Lieferprobleme hineinzugeraten. Über dies ist das Fixen und Fehlersuchen ein beträchtlicher Kostenfaktor: Für eine Firma, die sich so in einer wesentlichen Produktpalette ein langfristiges Problem einbaut, weil sie immer wieder mit bugs konfrontiert ist, die sie nicht in den Griff bekommt und die die Kunden verschrecken und den Namen ruinieren, kann das den Tod bedeuten.
)
