http://xmos.com/products/boards-and-tools/xs1-g-development-kit Was ist davon zu halten? Wie bestellen, der Dollar steht günstig...
Angehängte Dateien:
-
xdk-sm-white.png
28 KB
Die Xmos-Chips sind so ein Zwischending zwischen Mikrocontroller und FPGA mit dem Hintergrund, dass vieles, was aktuell in Hardware "gegossen" wird, auf einem ausreichend schnellen Prozessor auch in Software realisiert werden kann. Schließlich gibt es wesentlich mehr C-Programmierer auf der Welt als VHDL- oder Verilog-Experten ;-). Einige der Beispiele sind ja in den Xmos-Whitepapers erwähnt - z.B. ein UART. Die Entwicklung sieht man ja auch an anderen Stellen im Mikrocontroller-Bereich, ein prominentes Beispiel ist die Software-USB-Device-Implementierung für den AVR. Aber auch in Software implementierte SPI- oder CAN-Interfaces, die auf der Hardware-Seite nur einen einfachen I/O-Port zum "bit bangen" brauchen, fallen in die Kategorie. Einer der Gründer von Xmos ist übrigens David May, der den Transputer entwickelt hat. Einige Parallelen sind unverkennbar, wie z.B. die eigensinnige Herangehensweise an Instruktions-Codierungen ;-) oder die Links zwischen den einzelnen CPU-Cores. Zum Bestellen würde ich im Zweifel einfach die Jungs von Xmos mal anmailen, die sind nett :-). Das Eval-Kit ist halt leider erstmal recht teuer, die Chips an sich sollen aber in einen Preisbereich von $1-$10 fallen. -- Michael
Peter X. wrote: > http://xmos.com/products/boards-and-tools/xs1-g-development-kit > > Was ist davon zu halten? > Wie bestellen, der Dollar steht günstig... Danke für den Link. Wem die Architektur oder einige Details im Befehlssatz irgendwie bekannt vorkommen, täuscht sich nicht: Das Design ist von David May oder anders gesagt, der Transputer ist zurück. p.s. da war schon jemand schneller
@Michael Engel (Firma TU Dortmund) (cuby) Vielen Dank für deinen netten und äußerst kompettenten Beitrag. Hast du schon Erfahrung mit diesen XMOS-Chip's ?
@Peter X. Ich hab bisher auch nur die Datenblätter gelesen, aber bin mit Xmos in Kontakt. Da die Produktion noch nicht allzu lange läuft, haben die erstmal alle Hände voll zu tun (soo riesig ist die Firma ja noch nicht). Sobald ich aber mehr berichten kann, schreibe ich sicher auch mal einen Artikel. -- Michael
Diese Xmos Controller sind mit 1600Mips sicher interressant. Die Idee dahinter, in Software zu machen, was FPGA's in Hardware machen ist sicherlich auch interressant, weil es viel mehr C-Programmierer als VHDL/Verilog Programmierer gibt. Der dazu konkurierende Ansatz ist jedoch C2VHDL. Habe mal irgendwo einen Artikel dazu gelesen. Man hat dabei entweder eine festverdrahtete oder als IP-Core dazugekaufte CPU auf dem FPGA. Viel Rechenzeit schluckende Algorithmen werden dann zusätlich "In Hardware gegossen" auf dem FPGA-Chip realisiert. Dazu gibt es anscheinend ein Tool, das den C-Programmcode dort wo es gewünscht ist (#pragma blablub) in VHDL umsetzt. Ich hoffe, das ich das halbwegs verständlich formuliert habe und bitte um eine rege Diskussion darüber.
> Ich hoffe, das ich das halbwegs verständlich formuliert habe und bitte > um eine rege Diskussion darüber. Halte ich fuer ziemlichen Unsinn. :-) Ich bin gerade dabei Verilog zu lernen. Oder genauer gesagt wenn man C kann, dann lernt man sowas vermutlich in einer Woche. Eine zweite braucht man dann noch um mit der merkwuerdigen Oberflaeche von Xilinx klarzukommen. Das heisst aber jetzt nicht das die Programme die man so schreibt hinterher auch laufen. Es passiert einem sehr schnell das man was zusammenprogrammiert das in der Simulation gut aussieht in der Praxis aber aus den unterschiedlichsten Gruenden nicht laeuft. (GLitches, Latches, Skew usw.) Wenn ich das aber schon nicht hinbekomme, obwohl ich auch Menge Erfahrung mit Digitalschaltungen habe, wie soll dann ein automatisch arbeitendes Programm sowas schaffen? Ich kann mir nur vorstellen das bereits vorher vorhandene Bloecke in den eigenen Code eingefuegt werden. Andererseits wenn man sich ernsthaft damit auseinandersetzt dann kann man nach 6Monaten vermutlich gut Verilog oder VHDL und man muss sich fragen was der Aufwand soll, der in der Praxis vermutlich immer noch weniger Effizient ist als wenn man es selber macht. Olaf
>Ich bin gerade dabei Verilog zu lernen. Oder genauer gesagt wenn man >C kann, dann lernt man sowas vermutlich in einer Woche. Ich kann Verilog/VHDL natürlich mit C-Vorkenntnissen nach einer Woche so hinschreiben, dass der Syntax-Check durchgeht. Dann kann ich Verilog/VHDL programmieren. Ja, aber noch lange keine programmierbare Logik. >das die Programme die man so schreibt hinterher auch laufen Dann was dann noch fehlt, ist die Denkweise. Denn ich schreibe keine Programme. Sondern ich beschreibe, wie sich meine Hardware im FPGA verhalten soll. Und diese Hardware ist sehr, sehr eingeschränkt, wenn ich die syntaktischen Möglichkeiten von Verilog/VHDL anschaue. Da gibt es dann letztendlich kaum mehr als LUTs und FlipFlops. Und für die muss meine Beschreibung passen. Sonst klappt das nie. Und diese Denkweise muss dann auch mit SystemC oder C2VHDL oder sonstwas gelernt werden. Nur kommt dann evtl. die Erkenntnis langsam und die Umstellung ist nicht so brutal :-)
Kann jemand nach bald neun Jahren, mit Hands-on Erfahrung, was zu den XCores sagen? Wie haben die sich in der professionellen Hardwareentwicklung etabliert?
Im Audiobereich schon. AVB, USB Audio, Schnittstellenwandler etc. Durch die verschieden Cores lassen sich Zeitkritische Dinge gut aufteilen. Das Design hat vor allen bei Zeitkritischen Dingen bewährt. Er so als Zwischenlösung zum FPGA. Ich wusste nicht welche andere MCU in der Lage wäre 50MHZ auf die Ports stabil auszugeben.
Marco H. schrieb: > Im Audiobereich schon. AVB, USB Audio, Schnittstellenwandler etc. > > Durch die verschieden Cores lassen sich Zeitkritische Dinge gut > aufteilen. Das Design hat vor allen bei Zeitkritischen Dingen bewährt. > Er so als Zwischenlösung zum FPGA. Ich wusste nicht welche andere MCU > in der Lage wäre 50MHZ auf die Ports stabil auszugeben. Die Dinger sind echt spannend. Gibt es auch brauchbare Aussagen zum Energieverbrauch?
Hmm also Stromsparende Mechanismen hat der xmos wohl nicht. Das liegt glaube ich am Design. Für manche Anwendungen sind die Bausteine sehr interessant. Aber man muss eben auch Umdenken. Die Hardware muss man sich selber aus C Code zusammen basteln. Es gibt keine Schnittstellen wie etwa Uart,SPI etc. Somit kann man auch die Ressourcen besser nutzen wenn man z.Bsp 32 Uarts oder I2s etc. benötigt. Trotzdem sind Bausteine sehr performant da sie anders arbeiten wie übliche µP und die Zeiten sind exakt planbar. Jede Task hat seine feste Zykluszeit, Interrupts gibt auch keine. Der Baustein arbeitet mit Events und Channels über die man sich über die Cores austauschen kann. Zyklen bis 10n lassen sich exakt planen das ist schon mal etwas wo andere streiken müssen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.