Ich habe mir MyHDL, eine Hardwarebeschreibungs- und Testumgebung in Python angesehen. Als Python Fan gefällt mir insbesondere die verglichen mit VHDL deutlich elegantere Erstellung von Testbenches. Ich habe bislang schon erfolgreich eigene VHDL erzeugende Python Skripte benutzt, die VHDL Komponenten parametergesteuert instanzieren und verdrahten. Das ist allerdings weniger "Magie" als das was MyHDL macht. Ich habe ernsthafte Zweife daran, ob das von MyHDL erzeugte VHDL sich wirklich verlässlich in das synthetisiert, was man zuvor getestet hat. Hat jemand Erfahrung mit MyHDL?
Michael S1. schrieb: > ob das von MyHDL erzeugte VHDL sich > wirklich verlässlich in das synthetisiert, was man zuvor getestet hat. Das ist bei VHDL nicht anders: nicht alles, wass sich simulieren lässt, lässt sich auch synthetisieren. (Eher sogar: nur das Wenigste von dem, was tadellos simuliert werden kann, kann auch synthetisiert werden) Ich vermute in MyHDL wie in SystemC einen (hauptsächlich von Hochschulen vorangetriebenen) Versuch, ohne die teuren Simulatorlizenzen auszukommen...
Lothar Miller schrieb: > Ich vermute in MyHDL wie in SystemC einen (hauptsächlich von Hochschulen > vorangetriebenen) Versuch, ohne die teuren Simulatorlizenzen > auszukommen... Nun ja, der Entwickler von MyHDL, Jan Decaluwe, hat glaube ich schon einige Jahr(zehnt)e Erfahrung im Entwurfsbereich - als Hochschulprojekt würde ich das nicht ansehen, eher als persönliches Forschungsprojekt. Die Idee, Entwicklern ohne großartige Hardwareerfahrung den Entwurf von FPGA-basierten Systemen zu erleichtern, finde ich grundsätzlich nicht schlecht (die aktuelle Umsetzung allerdings schon, auch bei kommerziellen SystemC-Tools). Die Anwender von MyHDL finden sich allerdings in der Tat meist im Hochschulbereich, da ist immer noch ein wenig mehr Freiheit und Zeit (und wenn es die Zeit von Studenten ist ;-)) und dafür weniger Geld vorhanden, um neue Software auszuprobieren. Die Nützlichkeit von OpenSource-Tools beim Entwurf sollte man aber nicht unterschätzen. So hat SiCortex für den Entwurf von deren MIPS-basierten "Mini-Supercomputern" eine Reihe an OpenSource-Werkzeugen eingesetzt, z.B. SystemPerl, Verilator und eine simh-basierte Simulationsumgebung. Die Firma ist dann leider an der Finanzkrise zu Grunde gegangen - aber nicht an der Qualität der eingesetzten Werkzeuge... (Siehe http://www.veripool.org/papers/SiCortexFuncVer_DAC07_pres.pdf) -- Michael
MyHDL is ready for industrial applications, and has been used for high-volume applications already. Try it :-)
Lothar Miller schrieb: > ohne die teuren Simulatorlizenzen auszukommen... ... wobei erwähnt werden sollte, dass die Lizenzkosten für z.B. GHDL realtiv niedrig sind, wie man so hört. Michael Engel schrieb: > Entwicklern ohne großartige Hardwareerfahrung den Entwurf von > FPGA-basierten Systemen zu erleichtern, finde ich grundsätzlich nicht > schlecht ... sie krankt aber wie alle Ideen dieser Art (Robei, Labview, C2VHDL) daran, dass man das Wissen letztlich doch benötigt, um ein effektives FPGA hinzubekommen und der benefit solcher "Vereinfachungsversuche" darauf beschränkt bleibt, einige wenige - im Rahmen dieser Baukastenlösungen vorgesehene - Implementierungen zu nutzen. Alles, was über den simplen Entwicklungsstrang hinaus geht, erfordert dann doch wieder Wissen über mögliche Hardwarestrukturen, deren Zeitverhalten, Pipelining-Konzepte und Konkurrenzwirken von Modulen und deren Synchronisatio. Tools, die das automatisch auswerfen könnten, bedürften letzlich der Definition der Randbedingungen, die als Kriterium für die Entscheidung dienen müssten, welche Implemntierung man denn nun nutzen muss. Um das aber zu entscheiden, braucht man das Wissen über die hardwarerelevante Implementierung und die bekommt man erst nach Jahren. Dann aber braucht es nur einen kurzen Blick auf die requirements, um in Sekunden intuitiv zu entscheiden, was und wie man bauen muss. Wollte das tool das können, müsste man es mit allenmöglichen Randbedingungen vollstopfen. Daher wird kein Robei, kein Matlab, kein SystemC und auch kein myHDL jemals die eigentliche Aufgabe des FPGA-Designs lösen, nämlich die optimale Art der Hardwareimplementierung zu finden. Diese Tools können lediglich an singulären Punkten des Designprozesses einige Vereinfachungen vornehmen und einem Tipparbeit abnehmen bzw. gfs. Tippfehler vermeiden. Ich würde das mal als Bequemlichkeitssteigerung werten. Sie lösen aber dadurch den Designer immer mehr von der Hardware und verhindern daher eher, dass er im Laufe der Zeit das Wissen erlangt, um die eigentlich wichtige Aufgabe, wie oben beschrieben, zu lösen. Man kann das sehr schön beobachten, wenn man sich die Fragen ansieht, mit denen die beginnenden FPGA-Designer in Foren kämpfen. Bei genauerem Hinsehen ist deren Problem definitiv nicht das, dass sie nicht in der Lage gewesen wären, ihre Strukturen in VHDL syntaktisch korrekt zu formulieren, sondern sie haben den falschen Ansatz oder keinen Plan, wie die Schaltung überhaupt aussehen müsste, die ihre Aufgaben lösen könnte. Um das zu erlernen, muss man eben -beim Addierer anfangen, -einen Zähler bauen -eine kleine Alu entwerfen -eine Statemachine entwickeln -eine geschachtelte abstrakte FSM entwerfen -eine komplette Speichersteuerung schreiben -eine Rechenpipeline schreiben -eine geschachtelte Rechenpipeline schreiben und so die Methoden langsam beherrschen lernen. Einfach ein tool anzuwerfen, sich ein SOC-system oder ein sonstiges komplexes System zusammenzuklicken, um es schnell zu synthetisieren und dann "was zu haben", bringt da gar nichts für den Lernerfolg und ist meines Erachtens der falsche Einstieg. Ein Pilot lernt auch nicht das Fliegen, indem er in den Jumbo einsteigt und den Autopiloten drückt.
Moin, MyHDL ist mitnichten ein akademischer Spass, es gibt einige ernstzunehmende schwergewichtige Projekte (wie auch ASIC-Designs). Im nächsten Projekt werde ich es sehrwahrscheinlich einsetzen. Der Weg via Python ist m.E. genau der richtige Ansatz für eine "Verhochsprachung" von HDL. Die ganzen System*-Ansätze haben mich bisher alle nicht vom Hocker gerissen. Allerdings müsste bei der Verkettung mit Simulatoren wie GHDL noch etwas Arbeit rein. Das ist momentan noch der Haupt-Knackpunkt, weswegen ich nicht sofort gleich in die Vollen mit MyHDL gegangen bin.
Würdest Du sagen, dass ein Anfänger (allein) mit MyHDL starten kann / sollte?
Juergen Schuhmacher schrieb: > Michael Engel schrieb: >> Entwicklern ohne großartige Hardwareerfahrung den Entwurf von >> FPGA-basierten Systemen zu erleichtern, finde ich grundsätzlich nicht >> schlecht > ... sie krankt aber wie alle Ideen dieser Art (Robei, Labview, C2VHDL) > daran, dass man das Wissen letztlich doch benötigt, um ein effektives > FPGA hinzubekommen und der benefit solcher "Vereinfachungsversuche" > darauf beschränkt bleibt, einige wenige - im Rahmen dieser > Baukastenlösungen vorgesehene - Implementierungen zu nutzen. Ja - aber ich denke, dass es auch dafür einen Markt gibt. Genauso wie für Entwickler, die weit oberhalb der Software-Ebene Anwendungen entwickeln (oder auch nur Java-Libraries "zusammenklicken") und eine für sie zufriedenstellende Lösung finden. Für Performancegewinn sind sie auf die (begrenzten) Fähigkeiten der Compiler angewiesen. Für parallele Anwendungen wird es noch schlimmer - da ist das Problem schon recht ähnlich zu den FPGAs gelagert: kein Informatik-Studi lernt wirklich parallel zu denken und programmieren. Ob es bei den Kollegen der E-Technik besser aussieht, wage ich zu bezweifeln. Klar, da müssen wir uns an die eigene Nase fassen... Aber ich denke, dass es bei Software für Single/Multicores wie Configware für FPGAs auf das Selbe rausläuft: wenn genügend (bezahlbare) Rechenleistung verfügbar ist, kann man es sich leisten, einen Großteil davon durch ineffiziente Werkzeuge und Entwürfe zu verschwenden. Moore's und May's/Wirth's Law lassen grüßen :-). > Alles, was über den simplen Entwicklungsstrang hinaus geht, erfordert > dann doch wieder Wissen über mögliche Hardwarestrukturen, deren > Zeitverhalten, Pipelining-Konzepte und Konkurrenzwirken von Modulen und > deren Synchronisatio. Tools, die das automatisch auswerfen könnten, > bedürften letzlich der Definition der Randbedingungen, die als Kriterium > für die Entscheidung dienen müssten, welche Implemntierung man denn nun > nutzen muss. Dennoch wird die Hardware immer komplexer und die Entwickler sind durch sinkende Entwicklungsdaueranforderungen quasi dazu gezwungen, Werkzeuge auf immer abstrakteren Ebenen zu verwenden, um gegebene Aufgaben gelöst zu bekommen. Sonst würden wir heute noch mit Mylarfolie und spitzem Stift entwerfen (gerüchteweise macht das Bill Mensch für seine 6502-Varianten ja noch so). > Um das aber zu entscheiden, braucht man das Wissen über die > hardwarerelevante Implementierung und die bekommt man erst nach Jahren. > Dann aber braucht es nur einen kurzen Blick auf die requirements, um in > Sekunden intuitiv zu entscheiden, was und wie man bauen muss. Wollte das > tool das können, müsste man es mit allenmöglichen Randbedingungen > vollstopfen. Naja, der "eine kurze Blick" ist so eine Sache. Die Entwurfsräume sind heutzutage so groß und unüberschaubar, dass das IMHO nicht mehr trivial ist. Insbesondere, wenn nichtfunktionale Anforderungen wie Energie oder thermisches Verhalten zu Geschwindigkeits- und Funktionalitätsanforderungen dazukommen. > Daher wird kein Robei, kein Matlab, kein SystemC und auch kein myHDL > jemals die eigentliche Aufgabe des FPGA-Designs lösen, nämlich die > optimale Art der Hardwareimplementierung zu finden. Diese Tools können > lediglich an singulären Punkten des Designprozesses einige > Vereinfachungen vornehmen und einem Tipparbeit abnehmen bzw. gfs. > Tippfehler vermeiden. Ich würde das mal als Bequemlichkeitssteigerung > werten. Oder wir müssen uns "einfach" von der Anforderung einer optimalen Art der HW-Implementierung trennen und den Faktor von 10-100 in Leistungsverlust akzeptieren, der auch in der Software längst Einzug genommen hat. In Hinblick auf Energie usw. wird das natürlich haarig. > Sie lösen aber dadurch den Designer immer mehr von der Hardware und > verhindern daher eher, dass er im Laufe der Zeit das Wissen erlangt, um > die eigentlich wichtige Aufgabe, wie oben beschrieben, zu lösen. Man > kann das sehr schön beobachten, wenn man sich die Fragen ansieht, mit > denen die beginnenden FPGA-Designer in Foren kämpfen. Bei genauerem > Hinsehen ist deren Problem definitiv nicht das, dass sie nicht in der > Lage gewesen wären, ihre Strukturen in VHDL syntaktisch korrekt zu > formulieren, sondern sie haben den falschen Ansatz oder keinen Plan, wie > die Schaltung überhaupt aussehen müsste, die ihre Aufgaben lösen könnte. Das weiss der Entwickler bei einer ausreichend "hohen" Verhaltensbeschreibung aber auch nicht mehr. Es werden doch oft genug mal einfach so Schleifen, Multiplikationen oder (Horror) Divisionen in VHDL hingeschrieben und man hofft, dass der Compiler bzw. das Synthesetool schon merkt, dass nur Ganzzahlen durch Zweierpotenzen dividiert werden und damit Shifts ausreichen. > Um das zu erlernen, muss man eben > > -beim Addierer anfangen, > -einen Zähler bauen > -eine kleine Alu entwerfen > -eine Statemachine entwickeln > -eine geschachtelte abstrakte FSM entwerfen > -eine komplette Speichersteuerung schreiben > -eine Rechenpipeline schreiben > -eine geschachtelte Rechenpipeline schreiben > > und so die Methoden langsam beherrschen lernen. Ja - aber man muss sie im Entwurf dann nicht permanent auf niedrigster Ebene anwenden. Muss man z.B. eine Statemachine denn jedesmal von Hand wieder "zusammenklöppeln"? Meiner Meinung nach nicht. Aber man sollte vielleicht wissen, ob man Zustände binär oder one-hot codiert (wobei das einem heute auch schon Synthesetools abnehmen können). Ich denke, dass da Werkzeuge dem Entwickler schon eine Menge Arbeit abnehmen können. Die Grundkenntnis, was da in Hardware hintersteckt, sollte natürlich vorhanden sein. Wenn FPGAs aber irgendwann massentauglich werden sollten, kann man davon nicht mehr ausgehen, dass das wirklich so ist. Auch wenn wir unseren Studis die Digitaltechnik im 1. Semester nahezubringen versuchen... > Einfach ein tool anzuwerfen, sich ein SOC-system oder ein sonstiges > komplexes System zusammenzuklicken, um es schnell zu synthetisieren und > dann "was zu haben", bringt da gar nichts für den Lernerfolg und ist > meines Erachtens der falsche Einstieg. Das "von der Pike auf lernen" finde ich ja auch sinnvoll. Allerdings ist das dann ein extrem steiniger Weg - vor allem, wenn für die Entwicklung einer Lösung noch eine gehörige Menge Anwendungswissen erforderlich ist. > Ein Pilot lernt auch nicht das Fliegen, indem er in den Jumbo einsteigt > und den Autopiloten drückt. In seinem Berufsleben wird der Pilot aber dann später den Autopiloten zu einem großen Teil seiner Arbeitszeit verwenden und ihm vertrauen. Das erlernte Wissen und die entsprechenden Fähigkeiten werden eben dann wichtig, wenn etwas schiefgeht. Aber das ist wohl überall so... -- Michael
Michael Engel schrieb: > > Oder wir müssen uns "einfach" von der Anforderung einer optimalen Art > der HW-Implementierung trennen und den Faktor von 10-100 in > Leistungsverlust akzeptieren, der auch in der Software längst Einzug > genommen hat. In Hinblick auf Energie usw. wird das natürlich haarig. > Gibt es schon, nennt sich FPGA.
hmm, also 'irgendwelche' Tools werden ja hoffentlich was syntaktisch korrektes zu Stande bringen... Aber in der Semantik, wie soll denn ein Tool etwas 'neues' hinzaubern? Das Tool kann doch nur das machen, was der Autor auch schon kannte... Also ich denke mal, der 'Neuigkeitsgrad' geht mit sowas gegen Null...
Michael S1. schrieb: > Ich habe mir MyHDL, eine Hardwarebeschreibungs- und Testumgebung in > Python angesehen. Als Python Fan gefällt mir insbesondere die verglichen > mit VHDL deutlich elegantere Erstellung von Testbenches. Wer benutzt schon VHDL für Testbenches? :-) Vielleicht irgendwelche Amateure, aber ansonsten ist doch SystemVerilog State of the Art!
Angehängte Dateien:
Michael Engel schrieb: > die weit oberhalb der Software-Ebene Anwendungen entwickeln Das ist aber dann reine Funktionslogistik, die man eh besser in einer CPU unterbringt. Ich sage das, weil sich derzeit alle auf die Softcores stürzen. Was FPGAs angeht, ist das ja ein untergeordneter Punkt, den man besser abtrennt, wie Du richtig sagst. Diese Softthemen sehe ich mithin nur als ein Teilthema an. Michael Engel schrieb: > Oder wir müssen uns "einfach" von der Anforderung einer optimalen Art > der HW-Implementierung trennen und den Faktor von 10-100 in > Leistungsverlust akzeptieren, Beim Prototyping ja, bei einem Produkt, das in den Markt gehen soll, eher weniger. Zwar wären bei kleinen Stückzahlen die Einsparung von Entwicklungskosten sehr wichtig, aber oft ist es so, dass die FPGAs eh schon rausfliegen, wegen Strom und Platz. Da kann man sich 10% Verschwendung erlauben, aber keinen sicher keinen Faktor 10 oder gar Faktor 100. Was ich so ad hoc überschaue, kann man mit einem Faktor 2 bei einem schlecht genutzten FPGA gut leben, weil das zwischen 20,- und 200,- Euro pro Stück ausmacht, wenn sich bei Stückzahlen von 100-1000 dann Kostenaufschläge von <20k ergeben. Dann muss aber auch schon ein Gegenwert bei der Ersparnis sichtbar sein. Im Bereich Test ist da einiges zu holen! Die Frage ist, wo die Einführung eines Tools und einer Methode, die ja erstmal Zeit kostet, dann auf Dauer so richtig spart. Das ist nicht überall der Fall und Vereinfachungen im Bereich FPGA-Design hat man ja bereits durch die Nutzung von Cores und fertigen Modulen, die man mal gebaut hat oder die ein Kunde vorhält. Im Übrigen lässt sich auch mit manuellen Methoden ein block building bei FPGAs erzielen. Ich verwende oft Excel. Ich habe das seit 20 Jahren im Gebrauch, als ich noch viel Controller- und Windowssoftware gemacht habe, um mir die Rechungen und auch den Teilcode ausgegeben zu lassen, statt es immer wieder neu zu tippen. Auf diese Weise lassen sich die Bitbreiten bestimmen und skalieren, die Fehlerabfang-Befehle generieren und auch die Nummerierung und Benamung automatisch regeln, sodass man da wenger Fehler macht. Ausserdem hat man gleich eine Doku! Ich setze das bereits bei der Planung der Rechenmodule ein und kann so schnell durchspielen, wo man welche Wortbreiten und Auflösungen hat. In Excel ist das ja letlzich auch nur ein stumpfer Copy-Paste-Vorgang, man sieht aber sofort die Bitbreiten und bekommt natives VHDL, anders als z.B. beim HDL-Designer oder gar Matlab-Simulink, wo man sowas teilweise noch per Hand einstellen muss. Ich habe das im Rahmen einer Mathworks-Vorführung mal gezeigt und den Herren verdeutlicht, dass dieses "primtive Vorgehen" einfacher und schneller und zugleich durchsichtiger ist, weil die in Simulink benutzten Blöcke manche Aspekte verbergen. Das tollste ist ja, dass man dort z.B. bei DIV-Blöcken und anderen Modulen wie Vergleichern teilweise noch Vektorbreiten angeben und so MATLAB beim Rechnen helfen muss, obwohl es das selber können sollte, weil es die Infos ja hat. Da habe ich in erstaunte Gesichter geblickt! :-) Ich halte da Excel durchaus für stärker, als MATLAB Simulink und auch als z.B. Labview und Visio, weil ich an Funktionsblöcke, gleich die Propagation Delays dranschreiben und mir fortgestzt ausrechnen lassen kann. Bei pipelines habe ich immer die automatische Benamung mit Delay und finde den Kram dann im Modelsim auch wieder. Wer mal den output vom System Generator in ModelSim simuliert hat, weiss, wovon ich rede :-)
Angehängte Dateien:
berndl schrieb: > hmm, also 'irgendwelche' Tools werden ja hoffentlich was syntaktisch > korrektes zu Stande bringen... Wenn das mal immer so wäre :-) > Das Tool kann doch nur das machen, was der Autor auch schon kannte... Genau und die meisten Tools werden ja von Softwareentwicklern geschrieben :D Und wenn es ein Hardwareentwickler macht, kommt meistens ein schlimme GUI bei raus :-) > Also ich denke mal, der 'Neuigkeitsgrad' geht mit sowas gegen Null... Ich sehe bei allen tools ausnahmslos nur Einschränkungen gegenüber nativem VHDL. Der Nutzen ist immer nur der einer Teillösung im Gesamtverbund. Beim Excel habe ich natürlich auch den Nachteil, dass es nicht teamfähig- oder versionierbar ist, wie die meisten Grafiktools, ich habe aber mit VBA eine Programmiersprache mit drin, mit der ich verschiedene Dinge automatisieren kann und die grafischen Funktionen von Excel helfen beim Veranschaulichen von Filter und deren Ausgaben:
Flutschkopf schrieb: > Wer benutzt schon VHDL für Testbenches? :-) Vielleicht irgendwelche > Amateure, aber ansonsten ist doch SystemVerilog State of the Art! Leute, die testfreundliche Hardware schreiben und darauf achten, dass die Testbenches synthestierbar sind, damit man sie in ein Evalboard einbauen und praktisch nutzen kann. Z.b. kann man die Modelle für Sensoren und AD-Wandler inklusive deren induziertem Fehlverhalten integrieren und das Gesamtsystem testen, auch wenn die Sensoren noch gar nicht geliefert sind und deren Fehlverhalten nicht triggerbar ist. Da gibt es viele Punkte, die noch ungenutzt sind.
Da habe ich ja was entfacht .... ;) Wenn ich MyHDL und die Beispiele richtig verstehe, dann erzeugt das prizipell erst mal keinen Overhead. Klar muss man jede Sprache samt den Hintergründen, von denen viele für alle HDL gelten, richtig verstehen, um gute Ergebnisse zu bekommen. Schlecht programmiertes VHDL erzeugt ja auch keine optimalen Ergebnisse. Ich denke vom Autopiloten ist das weit entfernt. Es geht eher um einen gut ausgestatteten (Python-) Werkzeugkoffer der bei der Arbeit helfen könnte. Fatal wäre es halt, wenn MyHDL nicht ausgereift genug ist um richtig in VHDL zu übersetzen. Und ehrlich gesagt verstehe ich das Umsetzungsprinzip noch nicht richtig, so dass es für mich schwer ist sich ein Bild von den Risiken zu machen. Es ist ein gutes Zeichen, dass Jan Decaluwe so überzeugt von MyHDL ist, aber Anwendererfahrungen wären noch spannender.
Juergen Schuhmacher schrieb: > Würdest Du sagen, dass ein Anfänger (allein) mit MyHDL starten kann / > sollte? In MyHDL kann man auf jeden Fall mal schnell was zum Ticken bringen. Fürs Verständnis von Logik-Aufbau auf jeden Fall prima. Wer aber gleich auf der HW etwas zum laufen bringen will, kommt wohl um etwas "low-Level"-Wissen (sei es bzgl. VHDL oder Verilog) nicht herum. Ich denke mal, die Thematik ist ähnlich, was das beliebte Informatikerthema Java vs. Assembler angeht. Zu weiteren Aspekten: 1) Wiederverwertbarkeit: Bei Python-Code schon mal sehr gut, und es lassen sich mal eben schnell Testbenches erzeugen und mit allem möglichen koppeln. 2) Debugging: Da kommt halt wie immer die Low-Level-Sprache mit ins Spiel. Tools aus offener Source, die dank Python noch gut zu lesen ist, erlauben auch dementsprechend schnelles Einkreisen von Fehlern und ihrer Art (systemisch/idiotisch :-) ). 3) Vereinfachung des Entwicklungsprozesses: Tolles Thema zum Streiten. Fange ich gar nicht erst an :-) Muss jeder selber wissen, wo es sich amortisiert. Ich wäre aber auf jeden Fall dafür, den MyHDL-Ansatz an Hochschulen mit zu vermitteln, anstatt vieler sinnloser VHDL-Übungen, bei denen man eigentlich nichts über angewandte Digitalelektronik lernt und Gefahr läuft, sich in üblen Hacks zu verstricken.
Strubi schrieb: > Muss jeder selber wissen, wo es sich amortisiert. Ich wäre aber auf > jeden Fall dafür, den MyHDL-Ansatz an Hochschulen mit zu vermitteln, > anstatt vieler sinnloser VHDL-Übungen, bei denen man eigentlich nichts > über angewandte Digitalelektronik lernt und Gefahr läuft, sich in üblen > Hacks zu verstricken. Da hatte ich mal intensiver drüber nachgedacht. Das Problem bei dem Ansatz ist, dass man sich bei auftretenden Schwierigkeiten (von "synthetisiert nicht" bis "läuft nicht") dann doch wieder mit VHDL auseinandersetzen muss. Generiertes VHDL macht es da nicht besser. Andererseits ist man es auch leid, nicht gut funktionierende SystemC-Synthesetools oder mit je nach Version neuen überraschenden Bugs in den Hersteller-Toolchains für Verilog oder VHDL zu ertragen. Was ich mir wünsche ist eine open source Synthese-Toolchain für die Lehre, die von HDL bis zum Bitfile geht. Die muss nicht wirklich hochoptimale Designs erzeugen. Dafür sollten die Studis in die Lage versetzt werden, auch mal an Stellen im Code der Toolchain zu drehen (in der VL geht es aber auch um Parallelisierungs- und Synthesemethoden sowie Optimierungen dafür, nicht primär um den Hardwareentwurf). Die Xilinx- oder Altera-Toolchains sind halt monströse Black Boxes. -- Michael
Michael S1. schrieb: > Es ist ein gutes Zeichen, dass Jan Decaluwe so überzeugt von MyHDL ist Kommt häufiger vor, dass Entwickler einer Idee, von ihrem Nutzen überzeugt sind.
Flutschkopf schrieb: > Michael S1. schrieb: >> Es ist ein gutes Zeichen, dass Jan Decaluwe so überzeugt von MyHDL ist > Kommt häufiger vor, dass Entwickler einer Idee, von ihrem Nutzen > überzeugt sind. Absolutely right! And a sceptical public is even more common :-) All I can say is: MyHDL is for real. It has been and is being used for complex industrial applications. The main reason is Python. If Python is good enough for Google, Youtube, Dropbox ... than perhaps it is good enough for us, hardware designers. Technically, MyHDL is not a new language, but a Python library. That means that it is transparantly integrated in the whole Python ecosystem. Python is a fantastic language to write reference models in - arguably better than Matlab. MyHDL is the only HDL fully integrated with such a language. As systems become ever more complex, the emphasis will be more and more on verification through reference models. That is why I believe MyHDL owns the future.
Hard to image that Mr. Decaluwe observes this thread of google listed it already so he find an react within some minutes:-) Anyway I second the words in two ways: Python appears user friendly enough and is also easy to handle in terms of software maintenance and version control. If there is a way to quickly setup models and testbenches, this was an approach to push many lazy designers to that rather than programming synthesizing and testing what I often came across.
Moin, Michael Engel schrieb: > Da hatte ich mal intensiver drüber nachgedacht. Das Problem bei dem > Ansatz ist, dass man sich bei auftretenden Schwierigkeiten (von > "synthetisiert nicht" bis "läuft nicht") dann doch wieder mit VHDL > auseinandersetzen muss. Generiertes VHDL macht es da nicht besser. Das stimmt. Aber es ist so immerhin irgendwie debugbar. Das Problem ist ähnlich in der Softwareentwicklung: Kaum einer lernt Assembler, doch irgendwann muss er doch mal mit dem Disassembly-Debugger ran, weil die DLL wegen irgendwelcher Interna crasht. Mit dem Risiko, irgendwann mal ein Tool quasi reverse-engineeren zu müssen, weil es ev. daran schuld sein könnte (also kein 'idiotischer' Bug), muss fast jeder Entwickler und Projektleiter leben und es auch einkalkulieren. Unter dem Aspekt kann sich ein freies Tool in der Art durchaus amortisieren. Unter dem Lehraspekt: VHDL bietet ähnlich wie C eine Menge Möglichkeiten, 'falsch' anzufangen. Ich beobachte ab und an bei Studis einen gewissen Anfangs-Frust, da sie erst eine Menge komplexer Tools lernen müssen, und sich erst an dem Irrlicht VHDL die Nase blutig hauen, bevor es wirklich anfängt, Spass zu machen. MyHDL könnte da einen besseren Anfang machen - einfach nur schon, um sich besser auf die eigentliche Materie konzentrieren zu können. Mein Lieblingsspruch: "Python lernste in drei Tagen" :-) Jan: Have you ever tried submitting documentation/papers about your work to the Embedded World (Nuremberg) committee to lighten up the conference with some funky ideas?
Strubi schrieb: > "Python lernste in drei Tagen" :-) Naja, so isses nun auch wieder nicht. Die Sprache vielleicht - SW Konstruieren ist aber was völlig anderes. > Jan: Have you ever tried submitting documentation/papers about your work > to the Embedded World (Nuremberg) committee to lighten up the conference > with some funky ideas? There is also some demand for the forthcoming automation event. On several networks people are begging for papers :-) I assume, finally the one or the other indian guy will again appear and present something, he pretends to have invented, as usual.
Strubi schrieb: > Jan: Have you ever tried submitting documentation/papers about your work > to the Embedded World (Nuremberg) committee to lighten up the conference > with some funky ideas? No - but thanks for the pointer. (My emphasis and time allocation is focused on commercial (consultancy) activities though - not on academic discussions - do you think some kind of presence there could help my business?)
possibly yes, possibly no, depends on the value of your work. in your case, it might be useful to stress the benefit regarding testing and testbenching is there some example code which can Show the Advantage quickly ?
The "Embedded World" in Nuremberg is more of commercial than of academic nature. If you're able to show the advantages to the audience there, it might boost the project up a lot.
Ich wäre da einmal an praktischen Beispielen interessiert. Was braucht man für die Installation, wie aufwändig ist die Bildung eines Testszenarios, wann ist der break even zur klassischen testbench erreicht? Ich wäre z.B. daran interessiert, mir ein Modell meiner Phasik zu bauen, die von der VHDL-Elektronik geregelt und gefahren wird. Dann hätte ich zumindest ein ungefähres feedback von der Schaltung.
Ich habe bislang nur mit einfachen Dingen experimentiert. Zum Einsatz in einem echten Projekt hatte ich noch keine Gelegenheit. Klar ist, dass Python sehr viel elegantere Testbenches ermöglicht, die nach meiner Einschätzung sicher 50% Aufwand sparen können. Insbesondere wenn man sich entsprechend Libraries für wiederkehrende Aufgaben (z.B. Testpattern erzeugen) schaft. Wo ich noch meine Zweifel habe ist die recht mystische Umsetzung von Designs in VHDL, wo ich das Prinzip der Umsetzung wohl noch nicht richtig verstanden habe. Bei den kleinen Designs klappte es gut aber bei komplexeren Dingen hätte ich die Befürchtung, dass Fehler bei der Umsetzung passieren, die dann ja nicht von der Testbench abgedeckt wären.
Michael S1. schrieb: > Wo ich noch meine Zweifel habe ist die recht mystische Umsetzung von > Designs in VHDL, wo ich das Prinzip der Umsetzung wohl noch nicht > richtig verstanden habe. Bei den kleinen Designs klappte es gut aber bei > komplexeren Dingen hätte ich die Befürchtung, dass Fehler bei der > Umsetzung passieren, die dann ja nicht von der Testbench abgedeckt > wären. Das ist leider recht knifflig, da muss man aufpassen. Viele kleine Details sind nicht dokumentiert, aber die Umsetzung ist im Endeffekt recht logisch. Die Konvertierung geschieht per Zugriff auf interne Python-Compiler-Baumstrukturen via "ast". Bisher habe ich keine groben Bugs gefunden, bzw. die Bugs lagen meist im Code. Ich habe es sogar geschafft, mit gefährlichem Halbwissen eine weitere Konverter-Unterstützung reinzufrickeln. Beim ersten Anlauf amortisiert sich das Design gegenüber VHDL uU nicht. Beim nächsten grossen Design aber macht man's meist von Anfang an richtig und hat den Code schnell gefixt. Es macht sicher Sinn, das Design von Anfang an gleich zu VHDL zu konvertieren und zu schauen, ob es wenigstens synthetisiert. Schön sieht das VHDL allerdings nicht aus, und die Hierarchie bleibt nicht erhalten. Aber die schnelle und robust Testbenchfähigkeiten von Python wiegt das auf jeden Fall auf. Ein Bekannter hat in ca. 2 Monaten (!) einen CPU-Klon in MyHDL geschrieben, inkl. Testbench und Code-Generator für alle Hazard-Szenarien. Läuft schon testweise als system on chip auf der Hardware..
BoeserFisch schrieb: > Ein Bekannter hat in ca. 2 Monaten (!) einen CPU-Klon in MyHDL > geschrieben, inkl. Testbench Dabei wird das Problem aber eher das der CPU-Architekturkenntnis sein, würde ich mal behaupten und weniger das, der Formulierung. Ich habe mich auch mit myHDL befasst und sehe da kein Beschleunigung. Jedenfalls nicht bei std Strukturen. Beim Modellieren sieht es anders aus. Da ist das sehr hilfreich.
BoeserFisch schrieb: > in Bekannter hat in ca. 2 Monaten (!) einen CPU-Klon in MyHDL > geschrieben, inkl. Testbench und Code-Generator für alle > Hazard-Szenarien. Läuft schon testweise als system on chip auf der > Hardware.. Gibt es Aussagen, wie effektiv diese CPU ist? Wäre die mit C/C++ programmierbar? Oder wäre alternativ ein FPGA mit Python in dieser Weise schneller dazu zu bewegen, Formeln zu rechnen?
Nein. Nein und Nein. Ausführlicher mag es vielleicht Lothar dem "Freiberuflicher Softwareentwickler und Webentwickler - Spezialist für Software und Netzwerksicherheit" erklären.
Lars R. schrieb: > Nein. Nein und Nein. Ausführlicher mag es vielleicht Lothar dem > "Freiberuflicher Softwareentwickler und Webentwickler - Spezialist für > Software und Netzwerksicherheit" erklären. Hä? Martin K. schrieb: > BoeserFisch schrieb: >> in Bekannter hat in ca. 2 Monaten (!) einen CPU-Klon in MyHDL >> geschrieben, inkl. Testbench und Code-Generator für alle >> Hazard-Szenarien. Läuft schon testweise als system on chip auf der >> Hardware.. > > Gibt es Aussagen, wie effektiv diese CPU ist? > Wäre die mit C/C++ programmierbar? > > Oder wäre alternativ ein FPGA mit Python in dieser Weise schneller dazu > zu bewegen, Formeln zu rechnen? Ja, damit habe ich mich in letzter Zeit detaillierter beschäftigt. Falls mit der obigen CPU ein ZPU-Klon gemeint ist: zweimal Ja. Das Spiel habe ich auch mit einer MIPS-Architektur durch, mit weitgehender Verifikation gegen qemu/gcc, das ist in VHDL nicht realistisch zu schaffen. MyHDL nimmt einem nur beim Coden und Verifizieren viel Arbeit ab, natürlich nicht beim Denken :-) Zur ZPU-Architektur: Das Ding ist als Stack-Hybride nicht sonderlich schnell (typischerweise Faktor 4-5 unter der MIPS), aber aus Python lässt sich im Prinzip eine Formel hinschreiben und in Microcode oder wenn nötig harte Pipelines mit Fixpoint-Vektor-ALU übersetzen und "inline" aus dem C-Code aufrufen. Habe damit diverse Sachen wie JPEG-Encoder, schnelle Matrizenmultiplikation (Solver, u.ä. Filterkram) eingeschleift, schlussendlich schmeisst die ZPU nur noch die Prozesse an und lädt die "Microcode"-Applets. Das Framework dazu ist allerdings nicht publiziert, bzw. nur als OpenSource-Baremetal "MaSoCist" mit der alten Zealot ZPU. Man kann sich aber an den Arbeiten von Herrn Chris Felton und auch dem Migen-Ansatz inspirieren lassen. Zu empfehlen sind teils auch die Ideen von Herrn Yurkowski. Gruss, - Strubi
Strubi schrieb: > Lars R. schrieb: >> Nein. Nein und Nein. Ausführlicher mag es vielleicht Lothar dem >> "Freiberuflicher Softwareentwickler und Webentwickler - Spezialist für >> Software und Netzwerksicherheit" erklären. > > Hä? Deine Antwort finde ich informativ und interessant. Für Martin K., den Fragenden, ist sie jedoch wahrscheinlich eher irreführend. Den Hintergrund von Martin K. habe ich aus seiner microcontroller-Nutzerseite (Link neben Nutzername) zittiert. Zusammen mit der Art und Weise, wie er die Frage formuliert hat, vermute ich, dass Deine Antwort zwar auf dem persönlichen/sozialen Level schöner und freundlicher ist als meine, aber inhaltlich nicht hilfreicher. Edit: Im anderen Thread Beitrag "Ideen für FPGA-Projekte?" ist bereits die IMHO passendere Antwort gegeben: "System Generator for DSP" und ähnliches.
:
Bearbeitet durch User
> microcontroller-Nutzerseite (Link neben Nutzername) zittiert. Zusammen > mit der Art und Weise, wie er die Frage formuliert hat, vermute ich, > dass Deine Antwort zwar auf dem persönlichen/sozialen Level schöner und > freundlicher ist als meine, aber inhaltlich nicht hilfreicher. > Sehe ich anders, da ja auch deine Antwort nicht korrekt ist. Wenn sich der Ton immer weiter Richtung "Nein" ohne Begründung in diesem Forum bewegt, hat letzteres sein (konstruktives) Ziel verfehlt. > Edit: Im anderen Thread Beitrag "Ideen für FPGA-Projekte?" ist > bereits die IMHO passendere Antwort gegeben: "System Generator for DSP" > und ähnliches. Womit ein alter Kaffee zum n-ten Mal wieder aufgewärmt wird: Kann man auf "high level" zaubern anstatt herkömmlich Code schreiben? Lange Begründung für ein "Nein" kann gegeben werden, gehört aber nicht in die Rubrik Thema MyHDL und innovative Entwicklung. Mir ist schon klar, dass manche Antworten schwierig zu verwerten sind, aber dafür gibt's Suchdienste. Wer sich ernsthaft mit dem Thema (auch gerne aus der SW-Ecke) beschäftigt, wird dann schon signalisieren, wenn ihm was nicht hilfreich genug war. Und alles Knowhow gibts eben auch nicht umsonst.
Strubi schrieb: detailiert > Zur ZPU-Architektur Auf dem Trenz ZynqBerry Board mit Dual-Core ARM hard core für 109 EUR läuft ein ganzes Linux (ggf mit python). Das Trenz "Soft Propeller" Board für 59 EUR hat ebenfalls einen Dual-Core ARM hard core, der mit mehreren Hundert MHz läuft. Dazu gibt es die Entwicklungsumgebungen. Ähnliches zum Altera Cyclone 5. DDRx memory hard core, usw. Welches sind die Vorteile und Einsatzszenarien der 32Bit-ZPU mit wenigen dutzend MHz in Relation zu dem oben dargestellten und in Relation zu typischen 8- und 16Bit softcores?
:
Bearbeitet durch User
Jürgen S. schrieb: > Würdest Du sagen, dass ein Anfänger (allein) mit MyHDL starten kann / > sollte? Kann ja, sollte nein. MyHDL ist eine tolle Sache, um komplexe Designs zu beschreiben und zu simulieren. Aber beim Hardwaredesign bist Du früher oder später immer gezwungen, Dich mit den Details der Zeiltechnologie (z.B. FPGA) auseinander zu setzen. Softwareentwicklung kannst Du heute machen ohne einen blassen Schimmer von Prozessorarchitektur zu haben, Assembler brauchst Du nur noch exotischen Ausnahmefällen. Beim HDL-Design geht das nicht, da musst Du recht genau wissen, was sich unter der Motorhaube abspielt und welche Hardware aus welchem HDL-Code erzeugt wird. Das ist wie beim Schach: Nur mit der Kenntnis der Regeln allein gewinnst Du kein einziges Spiel. Als Anfänger hast Du den größeren Benefit, wenn Du VHDL oder Verilog lernst und wie man bestimmte Architekturen damit beschreibt. im Laufe der Zeit werden Deine Designs größer und Du wirst Dir wünschen, die Dinge mit etwas weniger Lines of Code beschreiben und simulieren zu können. Dann ist die Zeit für MyHDL gekommen. Zudem führt der MyHDL-Flow letzendlich auch über eine Zwischenstufe mit VHDL oder Verilog, bei der Du eingreifen kannst und wahrscheinlich auch musst. Decaluwe weist selbst ausdrücklich darauf hin, dass MyHDL kein Ersatz für die klassischen HDL-Sprachen ist, sondern eine Ergänzung.
Moin, offenbar hast du einige Missverständnisse mit der Löschung deines letzten Beitrags erfolgreich ausgeräumt. > > Welches sind die Vorteile und Einsatzszenarien der 32Bit-ZPU mit > wenigen dutzend MHz in Relation zu dem oben dargestellten und in > Relation zu typischen 8- und 16Bit softcores? Habe ich eigentlich bereits geschrieben. Ansonsten: - Multicore (statt Multitasking gibts einen weiteren Core per Prozess) - Stromsparend und passt noch auf einen MachXO2 - HWKosten, Zertifizierungen (je beweisbarer, desto billiger) - "Testsieger" der kompakten CPUs mit GCC-Support: Sowohl Code als auch HDL (ca. 700 LE für Core). Die Frage mit den MHz kommt oft. Wie schon geschrieben gibt es immer mal Spezialanwendungen, wo eben ein FPGA anstatt eines DSP her muss und auch der Linux-Bolide mit 1 GHz nicht genügend Performance bringt. Der Algorithmen-Entwickler soll sich aber nicht mit HDL herumschlagen müssen. Und merke: Es geht nich um embedded Python, oder Python auf dem Prozessor laufen zu lassen, sondern aus Python heraus HLS (high level synthesis) zu machen. Vancouver schrieb: > Softwareentwicklung kannst Du heute > machen ohne einen blassen Schimmer von Prozessorarchitektur zu haben, > Assembler brauchst Du nur noch exotischen Ausnahmefällen. Beim Klassisches Argument, aber sehe ich nicht so. Die exotischen Ausnahmefälle sind in vielen Branchen immer noch die Regel :-) Aber Banken/Webkram kann man auch schlecht mit embedded vergleichen. Ansonsten hast du schon recht, man muss sich wie gesagt dafür interessieren, was MyHDL ausspuckt. Spätestens dann, wenn es ums Debuggen geht. Ist aber bei der Software mit Assembler genauso, irgendeiner muss den Fehler auf der untersten Ebene finden. Ansonsten gibt es sehr wohl Applikationen, wo sich der MyHDL-Coder nicht für die HDL-Details interessieren muss (besagte HLS). Dafür ist er von jemandem abhängig, der auf der Synthese-Ebene debuggen kann. Ich höre des öfteren von der neuen "Generation Master", dass effektive HDL-Kenntnisse kaum vermittelt werden (können). Dann kann man's in der eh schon überbepackten Ausbildung gleich lassen, oder sich überlegen, ob man das Problem anders angeht und den Studenten die Frustration erspart, sich mit nervigen Details strenger Hochsprachen und Tools herumschlagen zu müssen, bevor es ans Verständnis geht. Auch da kann ich wieder nur in die Staaten verweisen, da haben einige Unis das Problem erkannt und machen im Rahmen diverser Coding-Projekte interessante Sachen in MyHDL (siehe GSoC). Gruss, - Strubi
Strubi schrieb: Hallo, > offenbar hast du einige Missverständnisse mit der Löschung deines > letzten Beitrags erfolgreich ausgeräumt. Mir war nach dem Posten klar geworden, dass ich die Diskussion nicht in diese Richtung lenken möchte. >> Welches sind die Vorteile und Einsatzszenarien der 32Bit-ZPU mit >> wenigen dutzend MHz in Relation zu dem oben dargestellten und in >> Relation zu typischen 8- und 16Bit softcores? > > Habe ich eigentlich bereits geschrieben. Eben nicht. > Ansonsten: > - Multicore (statt Multitasking gibts einen weiteren Core per Prozess) > - Stromsparend und passt noch auf einen MachXO2 > - HWKosten, Zertifizierungen (je beweisbarer, desto billiger) Die Zertifizierungen der ZPU können mit ARM mithalten? Wer hilft mir zur ZPU, wenn Du einen Verkehrsunfall hast? Wird die Unterstützung von Entwicklungsumgebungen zur ZPU weiter geführt; gibt es das überhaupt schon? Treiber; Peripherie? Multicore: Gibt es etablierte APIs für die Interprozess-Kommunikation? HWKosten: Beispiel bitte. Ein FPGA, in den nur ein oder 4 ZPUs hinein passen, kann nicht viel. Ein großer FPGA mit Dual-ARM hard core kostet kaum mehr als einer ohne ARM. Derjenige ohne ARM muss dann auch größer sein, um die ZPU soft cores zu beinhalten. > - "Testsieger" der kompakten CPUs mit GCC-Support: Sowohl Code als auch > HDL (ca. 700 LE für Core). Das finde ich auch unglaublich toll. Aber warum sollte ich es in diesem Zustand für ein Projekt hernehmen? > Die Frage mit den MHz kommt oft. Wie schon geschrieben gibt es immer mal > Spezialanwendungen, wo eben ein FPGA anstatt eines DSP her muss und auch > der Linux-Bolide mit 1 GHz nicht genügend Performance bringt. Und genau dafür gibt es doch die Dinge, die ich aufgezählt hatte; DSP war nicht darunter. Schon klar, dass der DSP dafür nicht geeignet ist. Ich frage Dich, was der Vorteil gegenüber a ist und Du antwortest, was der Vorteil gegenüber b ist, mit a!=b. > Und merke: Es geht nich um embedded Python, oder Python auf dem > Prozessor laufen zu lassen, sondern aus Python heraus HLS (high level > synthesis) zu machen. Weiter oben hattest Du davon angefangen, man könne prinzipiell aus Python-Code Op-Code erzeugen, der dann auf der ZPU läuft. > Vancouver schrieb: >> Softwareentwicklung kannst Du heute >> machen ohne einen blassen Schimmer von Prozessorarchitektur zu haben, >> Assembler brauchst Du nur noch exotischen Ausnahmefällen. Beim > > Auch da kann ich wieder nur in die Staaten verweisen, da haben einige > Unis das Problem erkannt und machen im Rahmen diverser Coding-Projekte > interessante Sachen in MyHDL (siehe GSoC). Nun schreibe ich doch einen Aspekt, den ich weiter oben gelöscht hatte: Was möchtest Du (bewirken)?
Strubi schrieb: > Die exotischen Ausnahmefälle sind in vielen Branchen immer noch die > Regel :-) Das stimmt, aber in vielen Fällen eher aus Gewohnheit als aus Notwendigkeit. Wer "seinen"Assembler beherrsscht, schreibt zeitkritische Funktionen halt schnell in Assembler runter, da weiß man, dass es funktioniert und fertig. Wiederverwertbarkeit, Wartbarkeit, Plattformunabhängigkeit spielen dabei nicht unbedingt die erste Geige. >Auch da kann ich wieder nur in die Staaten verweisen, da haben einige >Unis das Problem erkannt und machen im Rahmen diverser Coding-Projekte >interessante Sachen in MyHDL (siehe GSoC). oder in Planung, z.B. CASPER (https://casper.berkeley.edu/wiki/MyHDL_toolflow) MyHDL ist auf jeden Fall eine Sache, die in die Uni-Lehrpläne gehört, aber wie gesagt, allein damit kommt man nicht zum Ziel. HDL-Design ist ja kein Selbstzweck. Am Ende muss immer ein lauffähiger Chip oder FPGA dabei herauskommen, und das geht nur, wenn man den Unterbau verstanden hat.
Moin, > > Mir war nach dem Posten klar geworden, dass ich die Diskussion nicht in > diese Richtung lenken möchte. > Gute Idee. Ich tendiere dazu, mich aus sowas schnell auszuklinken. > > Die Zertifizierungen der ZPU können mit ARM mithalten? Wer hilft mir zur > ZPU, wenn Du einen Verkehrsunfall hast? Wird die Unterstützung von > Entwicklungsumgebungen zur ZPU weiter geführt; gibt es das überhaupt > schon? Treiber; Peripherie? Ich denke, sie können (auf weiteres bin ich noch gespannt). Das wird spätestens bei der Code-Coverage klar, die du für ARM9 z.B. gar nicht kriegen kannst. Warum denkst du, wurde bei einer bekannten Göteborger Schmiede ein eigener Prozessor entwickelt? Zur ZPU: Es gibt eine recht grosse ZPU-Community. Die Tatsache, dass sich der ZPU-Schöpfer Harboe auf andere Dinge konzentriert, heisst nicht, dass das Ding verwaist ist. Können dir sicher einige Nutzer bestätigen. > > Multicore: Gibt es etablierte APIs für die Interprozess-Kommunikation? > Shared Memory und HW-Semaphoren (aka Spinlocks). Mehr brauchts nicht (keep it simple). Wichtig ist primär ein robuster Debug-Port. > HWKosten: Beispiel bitte. Ein FPGA, in den nur ein oder 4 ZPUs hinein > passen, kann nicht viel. Ein großer FPGA mit Dual-ARM hard core kostet > kaum mehr als einer ohne ARM. Derjenige ohne ARM muss dann auch größer > sein, um die ZPU soft cores zu beinhalten. > Ok, ein Beispiel: Ich brauche eine Plattform mit einer Spezialschnittstelle, drei UARTs und einer hw-redundant rechnenden CPU. Gibt es (für mich) nicht auf dem Markt. So there. Lässt prima mit einem 250k Spartan3 erschlagen. Warum mit stromfressenden Kanonen auf Zecken schiessen? Dann etwas prinzipielles: 13 atomische Opcodes mit allen Kombinationen sind deutlich einfacher zu verifizieren als MIPSoide oder ARM mit einer deutlich darüber liegenden Zahl. Mindestanforderung: Befehls-Slot A und Slot B mit beliebigen Opcodes plus allen Exception-Zuständen verifizieren. Das ist für viele Anwender kein Thema, ich brauche was "beweisbares". >> - "Testsieger" der kompakten CPUs mit GCC-Support: Sowohl Code als auch >> HDL (ca. 700 LE für Core). > > Das finde ich auch unglaublich toll. Aber warum sollte ich es in diesem > Zustand für ein Projekt hernehmen? > Das musst Du selber wissen. Und die Frage kannst Du dir auch nur beantworten, wenn du dich mit der Sache beschäftigst. Wir wollen ja nicht spekulieren/Meinungsmache betreiben. Auch wenn Du offenbar dazu tendierst, mir ein Dienstleistungsgehabe anzusuggerieren: Ich bin nicht daran interessiert, das Ding als Entwicklerwerkzeug zur Verfügung zu stellen, wie ich ja schon angedeutet habe. Dazu gibt es genügend offene Referenzprojekte, obiges dient rein als Beispiel was mit MyHDL so machbar ist. >> Die Frage mit den MHz kommt oft. Wie schon geschrieben gibt es immer mal >> Spezialanwendungen, wo eben ein FPGA anstatt eines DSP her muss und auch >> der Linux-Bolide mit 1 GHz nicht genügend Performance bringt. > > Und genau dafür gibt es doch die Dinge, die ich aufgezählt hatte; DSP > war nicht darunter. Schon klar, dass der DSP dafür nicht geeignet ist. > Ich frage Dich, was der Vorteil gegenüber a ist und Du antwortest, was > der Vorteil gegenüber b ist, mit a!=b. > Wenn in einer Dimension a < b und c < a, dann gilt auch c < b :-) Nimm mal z.B. h264-encoding, oder schon einfache Sachen wie nahtlose DMA-Transfers. Einfache Sachen. Wenn ich Linux brauche, nehme ich einen dafür gut etablierten Prozessor und kein Zynq-Gefrickel. > > Weiter oben hattest Du davon angefangen, man könne prinzipiell aus > Python-Code Op-Code erzeugen, der dann auf der ZPU läuft. > Genau. Du hast aber möglw. das Konzept mit dem Mikrocode nicht verinnerlicht. Da man das aber alles im Internet nachlesen kann (also auch hier), rate ich mal zum Selbststudium, bevor wieder alles durcheinandergebracht wird. Oder du machst einen neuen Thread zum Thema ZPU auf und stellst gezielt Fragen, die auch anderen was bringen. >> Vancouver schrieb: >>> Softwareentwicklung kannst Du heute >>> machen ohne einen blassen Schimmer von Prozessorarchitektur zu haben, >>> Assembler brauchst Du nur noch exotischen Ausnahmefällen. Beim >> >> Auch da kann ich wieder nur in die Staaten verweisen, da haben einige >> Unis das Problem erkannt und machen im Rahmen diverser Coding-Projekte >> interessante Sachen in MyHDL (siehe GSoC). > > Nun schreibe ich doch einen Aspekt, den ich weiter oben gelöscht hatte: > Was möchtest Du (bewirken)? Ich bin durchaus auch an akademisch gefärbtem Geben & Nehmen oder schlicht Herumspielen mit interessanten Technologien interessiert. Nicht an einer Trollwiese, oder mir mehr Arbeit als nötig einzubrocken. Vancouver schrieb: > Das stimmt, aber in vielen Fällen eher aus Gewohnheit als aus > Notwendigkeit. Wer "seinen"Assembler beherrsscht, schreibt zeitkritische > Funktionen halt schnell in Assembler runter, da weiß man, dass es > funktioniert und fertig. Wiederverwertbarkeit, Wartbarkeit, > Plattformunabhängigkeit spielen dabei nicht unbedingt die erste Geige. Ich meinte damit eher die Notwendigkeit des Anpassens einer crt0.s bei einer neuen Plattform, oder die Wartung von Legacy/Alt-Plattformen (8051-style). Vancouver schrieb: > MyHDL ist auf jeden Fall eine Sache, die in die Uni-Lehrpläne gehört, > aber wie gesagt, allein damit kommt man nicht zum Ziel. HDL-Design ist > ja kein Selbstzweck. Am Ende muss immer ein lauffähiger Chip oder FPGA > dabei herauskommen, und das geht nur, wenn man den Unterbau verstanden > hat. Klar. Dass man an den FHs FPGA-Technik oft eher im Trial&Error-Verfahren lernt, bringt aber noch weniger. Es gibt nur noch einen Aspekt der Arbeitsteilung, nämlich der, dass der eine eben die Modellierung macht, und der Lowlevel-Spezi den Unterbau. Das geht im klassischen V* HDL nur von hinten durch die Brust, auch an der letzten Embedded hat mich das HLS-Zeug nicht überzeugt, bzw. stand nur drauf, war aber nicht drin :-) Dass das alternativ sehr gut ohne teure Tools und Herstellerabhängigkeit geht, hat der MyHDL-Vater ja schon mehrfach demonstriert.
Hallo, Strubi schrieb: >> [Zertifizierungen] Den dual ARM9 als hard core hat man in einem FPGA eben nur einmal genau so... > Warum denkst du, wurde bei einer bekannten Göteborger > Schmiede ein eigener Prozessor entwickelt? Weiß nicht. Und warum verschenkt/open source gemacht? > Spezialschnittstelle, drei UARTs und einer hw-redundant rechnenden CPU. > [...]. Lässt prima mit einem 250k Spartan3 erschlagen. Warum mit > stromfressenden Kanonen auf Zecken schiessen? Weil man das eben so macht, wenn es unter Berücksichtigung ALLER Kosten günstiger und risikoärmer ist. > Dann etwas prinzipielles: 13 atomische Opcodes mit allen Kombinationen > sind deutlich einfacher zu verifizieren als MIPSoide oder ARM mit einer > deutlich darüber liegenden Zahl. Mindestanforderung: Befehls-Slot A und > Slot B mit beliebigen Opcodes plus allen Exception-Zuständen > verifizieren. > Das ist für viele Anwender kein Thema, ich brauche was "beweisbares". Ja, sehr speziell. Trotzdem sehr gutes Beispiel. Danke. >> Nun schreibe ich doch einen Aspekt, den ich weiter oben gelöscht hatte: >> Was möchtest Du (bewirken)? > > Ich bin durchaus auch an akademisch gefärbtem Geben & Nehmen oder > schlicht Herumspielen mit interessanten Technologien interessiert. Es wäre für mich auch ok, wenn Du hättest etwas anbieten wollen. Ich versuche nur zu verstehen. Interessant finde ich Dinge, die dazu führen können, dass mehr von der Wertschöpfung beim Entwickler ankommt.
Lars R. schrieb: > Den > Hintergrund von Martin K. habe ich aus seiner > microcontroller-Nutzerseite (Link neben Nutzername) zittiert. Nett, dass Du Dich für meine Person interessierst, Ich nehme an, Du warst auch derjenige auf meine Xing-Profil. Dann hast Du sicher gesehen, dass ich auch FPGA mache, wenn auch nur hobbiemässig. Bisher. Zu Strubi: Alles habe ich nicht verstanden, aber es ging mir genau um eine Einschätzung eines Nutzers, damit ich nicht 3 Monate damit verbringe, um am Ende festzustellen, dass es nicht für mich nutzbringend ist. Für mich wäre interessant, mathematische Formeln und Befehle zu benutzen und eine einfache Implementierung in VHDL zu bekommen. Beispiel: Daten über eine serielle Schnittstelle mit konkret 115kBaud empfangen, decodieren, Zustände interner Variablen infolge der Befehle schalten und Werte ändern: 1. "wenn CODE = 56 dann Motor an". "wenn CODE = 99 dann Motor aus" 2. "wenn CODE1 = 3, dann Speed1 = Speed1 + CODE-Wert von CODE 3 und CODE 4" 3. "Filterwert2 = Filterwert2 + X 4. "Wert5 = Sinus (CODE6) und solche Dinge. Das ginge in VHDL noch recht einfach. Dann müssen aber allemöglichen Werte und Kurven auf ein Display gezeichnet werden, teilweise Punktweise, manchmal Graphen und das Display muss permanent ausgegeben werden, z.B. über VGA.
Martin K. schrieb: > Lars R. schrieb: >> Den > Hintergrund von Martin K. habe ich aus seiner >> microcontroller-Nutzerseite (Link neben Nutzername) zittiert. > > Nett, dass Du Dich für meine Person interessierst Prinzipiell. > Ich nehme an, Du > warst auch derjenige auf meine Xing-Profil. Nein. > Dann hast Du sicher gesehen, > dass ich auch FPGA mache, wenn auch nur hobbiemässig. Nein.
Moin, Martin K. schrieb: > Zu Strubi: Alles habe ich nicht verstanden, aber es ging mir genau um > eine Einschätzung eines Nutzers, damit ich nicht 3 Monate damit > verbringe, um am Ende festzustellen, dass es nicht für mich nutzbringend > ist. > Es ist recht knackig, aber in 3 Monaten kannst Du schon was reissen, wenn du dranbleiben kannst. Wenn du auf mittlerem Level mit MyHDL leckere Sachen machen willst, wird's kniffliger: 1) Dich in den 'ast' reinfuchsen 2) Klassenkonstrukte mit entsprechenden Generatoren (die @-Dekoratoren-Dinger) etablieren 3) Das Ganze dazu bringen, mit MyHDL korrekt zu interagieren > Für mich wäre interessant, mathematische Formeln und Befehle zu benutzen > und eine einfache Implementierung in VHDL zu bekommen. > > Beispiel: > > Daten über eine serielle Schnittstelle mit konkret 115kBaud empfangen, > decodieren, Zustände interner Variablen infolge der Befehle schalten und > Werte ändern: > > 1. "wenn CODE = 56 dann Motor an". "wenn CODE = 99 dann Motor aus" > 2. "wenn CODE1 = 3, dann Speed1 = Speed1 + CODE-Wert von CODE 3 und CODE > 4" > 3. "Filterwert2 = Filterwert2 + X > 4. "Wert5 = Sinus (CODE6) > > und solche Dinge. Das ginge in VHDL noch recht einfach. > > Dann müssen aber allemöglichen Werte und Kurven auf ein Display > gezeichnet werden, teilweise Punktweise, manchmal Graphen und das > Display muss permanent ausgegeben werden, z.B. über VGA. Gibt es dazu spezielle Anforderungen, das in HDL zu machen anstatt in einer simplen CPU? Ansich verfrachte ich typischerweise sowas wie deine Punkte 3 und 4 in die Mikrocode-Subroutinen (Beschleuniger), oder den "Coprozessor", sofern richtig harte Echtzeit/Robustheit gefordert ist. Das ist bei 115k doch so relaxed, dass du es mit einer CPU erledigen kannst. Kannst du fürs Display nicht einfach so ne klassische Ilitek/Sitronix-Schwarte nehmen, die Blit-Befehle per 8080/SPI frisst? Also sowas wie hier, nur in gross: http://tech.section5.ch/news/?p=380 Generische und 1-zyklen-effiziente Arithmetik zu backen geht fast mit keinem Tool so aus der Hand, auch nicht a la Simulink. Also Gedanken über die ALU-Architektur musst du dir schon machen, wenn alles nach 1-cycle pro Operation (innerhalb der gefüllten Pipeline) laufen soll. Erst dann kannst du mit deinen definierten Klassen Paralleloperationen im Prinzip als Formel hinschreiben, z.b.:
1 | a.re = b.re * c.im - c.re * b.im |
Musst du selber rausfinden, ob sich das für dich amortisiert oder es speziell für diesen Zweck doch von Hand codest.
Not convinced, who really wrote this, my 2 Cents though: Jan Decaluwe schrieb: > The main reason is Python. If Python is good enough for Google, Youtube, > Dropbox ... than perhaps it is good enough for us, hardware designers. I cannot second this. These apps differ totally in many aspects and cannot be an example for hw designs. But, as correctly stated: > Technically, MyHDL is not a new language, but a Python library. That > means that it is transparantly integrated in the whole Python ecosystem. THIS IS THE POINT. Python has (for what reason ever!) become a stable and supported system so it is dedicated to be used as a standard. The questions remains if it is effective enough and not only "more convenient for newbies" like so many other tools invented. And here comes the pro argument: > As systems become ever more complex, the emphasis will be more > and more on verification through reference models. EXACTLY. In nearly 90% of the PCBs I worked at the last 15 years, there are microcontrollers and DPSs attached, who configure FPGAs and internal functions. Simulation ist always an issue when it comes to complex triggering. At least for these purposes, a standard framework is an advantage. Since it moreover is possible to synthesize the Python Code, real time testing does not differ anymore very much from simulation which simplifies many things. > Python is ... better than Matlab A nice side effect :-)
:
Bearbeitet durch User
Wie würde man den myHDL gegen z.B. vivado HLS abgrenzen? Dort kann ich doch auch in C arbeiten und alles in VHDL übersetzen lassen. Wo wären Vorteil und Nachteile von myHDL?
Das isnd zwei grundlegend verschiedene Dinge. In HLS beschreibst Du einen Algorithmus in einer Hochsprache, ohne Dich um technische Details zu kümmern, und Vivado übersetzt diesen Algorithmus in eine VHDL-Strukturbeschreibung. In MyHDL beschreibst Du diese Struktur selbst, aber mit den Sprachlementen von Python. Während des gesamten Entwurfsprozesses muss Dir bewusst sein, dass Du keinen Algorithmus beschreibst, sondern eine Struktur, die einen Algorithmus berechnet. MyHDL macht keine Highlevelsynthese.
M. W. schrieb: > Wie würde man den myHDL gegen z.B. vivado HLS abgrenzen? Dort kann > ich > doch auch in C arbeiten und alles in VHDL übersetzen lassen. > > Wo wären Vorteil und Nachteile von myHDL? Weiss nicht, wie Vivado das genau macht, da ich bei C(++) nach VHDL bisher eher aufgelaufen bin und seit myHDL nix neues mehr ausprobiere. Vom Programmieraufwand her kann ich aber dazu was sagen. Da gibt's zwei Ansätze: a) C parsen und per register-transfer-language (RTL) HDL erzeugen (wie GCC) b) C++-Klassen und Generatoren für HDL schreiben, Executable backen, ausführen. Auf der Embedded World habe ich einen Xilinx-MA dazu ausgequetscht. Stellte sich dann heraus, dass die Roboter-Demo komplett auf dem ARM des Zynq lief, und die Filterkernels nicht per HLS erzeugt waren. Aus "Zeitgründen". Naja... Ansonsten scheinen sich die HLS-Demos auf Realtime-Apfelmännchen zu konzentrieren. Auch ein Naja. Bei Python hast du selber die komplette Kontrolle, wie du Code generierst. Die Trennung von a) und b) wie in C gibt es nicht. Um die Parserei musst du dich nicht kümmern, Python parst sich quasi selbst, du musst allenfalls 'nur' die Syntax-Bäume auswerten und kannst selbst definieren, wie das in HW-Instanzen oder Programmcode umgesetzt wird. Auf unterer Ebene hast du aus MyHDL die intbv oder Feltons fixbv-Erweiterung. Damit kannst du analog VHDL/Verilog deine DSP-Pipeline designen. Aufbauend darauf kannst du aber auch eine sich selbst parsende Toolchain (generatoren) basteln, die Modellierung/Simulation/HDL-Ausgabe in Einem macht. MyHDL ist als Modul da nur ein Teil von, die wahre Kraft liegt genaugenommen in Python mit den Object-Factories als Werkzeug. Bei Geschichte a) musst du alles dem RTL-Optimizer überlassen und hast a priori keine Kontrolle über die Ausgabe. Bei b) braucht's ein gehöriges Framework, um Parallelisierungen reinzubringen. Und dann muss man es immer wieder regress-testen. Python ist da als Interpretersprache von Haus aus mächtiger. Zudem hast du (mit einem gewissen Initialaufwand, zugegeben) alles in einem, auch die RTL. Fehlt nur noch die Netzlisten-Ausgabe :-) Narrensicher ist das eh alles nicht. Man muss immer irgendwann in den Interna stochern - da ist dann Opensource und Wiederverwertbarkeit nach 10 jahren eben nett. Denn wer garantiert mir, dass die Vivado HLS nach 5 Jahren die gleiche Ausgabe macht, geschweige, dass ich es auf andere HW portieren kann? Ab wann sich die Investition Python->HDL lohnt, ist insofern auch vom Problem abhängig. Gibt sicher Szenarien, wo Vivado ein schnelles brauchbares Ereignis liefert.
Eben erst gab es ein Webinar von PLC2 zum Thema HLS Vivado. Es wurde gut veranschaulicht, was da geht und wie und man kann sich auch vorstellen, was nicht geht. Vielleicht kann das irgendwie nachträglich geladen und angesehen werden. Vom Prinzip ist das recht bequem, vorhandenen C-Code zu nehmen und dort ins FPGA zu werfen, aber Ich sehe da nach wie vor die typischen Probleme des Ansatzes an solchem: 1. Es macht nicht viel Sinn, das Problem in C statt in VHDL zu formulieren, weil C Einschränkungen hat, die es in VHDL nicht gibt. Meine 2D- und 3D-pipelines wären in C nicht zu formulieren, jedenfalls nicht so, dass das bei rauskommt, was gewollt ist ;.) Genau die Thematik meine ich in einem Beispiel wiedererkannt zu haben, wo es darum ging, wo das bottle neck entsteht, wenn schleifen flachgerechnet werden. 2. Auch wenn das C-Programm schon verhanden ist, braucht es geeignete constraints und eine konkrete Vorstellung von Parallelität, um das Gewünschte zu erzielen. Gfs muss der Code umgeschrieben werden. Die typischen Konstrukte, die sich leicht übersetzen lassen, kann man auch optisch erkennbar in VHDL formulieren, denn sie sind da nicht aufwändiger und haben fast dieselbe Syntax. Allerdings kann die C-Struktur unterschiedlich übersetzt werden und aus einer Beschreibung unterschiedliche Cores erzeugt werden. 3. Es gibt zwar Optionen zum automatischen Ausrollen von squentiellen Strukturen, wie schon angedeutet, aber das passiert offenbar nur eindimensional (siehe parallel pipes). Der Weg durch die toolchain mit verschiedenen Iterationen, um in die Nische zu kommen, scheint mir mitunter auch recht aufwändig im Vergleich zu dem Vorgehen, es direkt zu formulieren, wenn man die Topologie vor Augen hat. Die hardware sehen und hinscheiben ist nach wie vor zielführender, meine ich. 4. Der Vorteil, für die, die das nicht können und mit C trotzdem zu einem FPGA zu gelangen, um schneller zu werden, ist zwar generell da - für mich aber nicht unzweifelhaft, weil die meisten Aktionen in Programmen Verwaltung und Sequenzielles sowie Sprünge und unkorrellierte Verzeigungen sind, die nicht von Parallelisierung profitieren können. Sequenzielle Rechnungen laufen aber jeweils in beiden Welten taktweise ab, tun das im FPGA aber mit viel geringerer Frequenz, als z.B. in einem ARM. Wieviel man da dann noch rausholen kann, hängt von Grad des pipelinings drumherum und vor allem der Dateneinsteuerung ab. Ich habe die Frage zu der Performance mal gestellt und ob da viel Beschleunigung möglich ist. Vorteile sehe ich darin, wenn man in einem FPGA arbeitet und eine überschaubare Zusatzaufgabe hat, die so komplex ist, dass sie in C besser zu formulieren ist. Ich denke da an Sortieren, verkette Listen und Ähnliches. Das ist vielleicht nicht schnell, aber schneller programmiert! Dann kann man sich einen Core bauen und reinstopfen. Floating-Point-Verarbeitung wäre da auch so ein Beispiel, wenn man mit einem Prozessor redet. Das müsste sich einfach und effektiv herstellen und nutzen lassen. Und es gibt gewisse Synergien mit der Validierung und dem Test. Ist halt in C durchaus auch einfacher, als in VHDL. Das muss man schon sagen. Allerdings wird in der Präsentation auch damit eröffnet, dass HLS kein tool für das gänzliche FPGA sei, sondern nur zur Herstelung eines Cores für Teile davon. Mit der Einschätzung würde ich mitgehen.
Strubi schrieb: > M. W. schrieb: > Vom Programmieraufwand her kann ich aber dazu was sagen. Da gibt's zwei > Ansätze: > > a) C parsen und per register-transfer-language (RTL) HDL erzeugen (wie > GCC) > b) C++-Klassen und Generatoren für HDL schreiben, Executable backen, > ausführen. > Könntest Du dazu Aussagen wegen Zeitaufwänden und Erfolg machen? Ich meine, was bringt es, das C++ auf einen FPGA zu bringen? Welche konkreten Applikationen gab es und wie war der Geschwindigkeitsgewinn?
Martin K. schrieb: >> > Könntest Du dazu Aussagen wegen Zeitaufwänden und Erfolg machen? Ich > meine, was bringt es, das C++ auf einen FPGA zu bringen? > Bevor da Missverständnisse aufkommen: C++ generiert in b) die HDL. Am Schluss hast du harte Logik. Hat Nullnix mit HLS zu tun, Du musst mit deinen Klassenkonstrukten eine HDL-*Beschreibung* machen. Es schenkt sich ansich vom Denken her nix zum Entwurf in V*-HDL, bzw. ist es dann wieder so abstrahiert, dass nur gewisse Sachen gehen. Da dieser C++-Code sich ohne aufwendige Runtime-Sachen nicht selbst verifizieren kann, muss man dann GENAU wissen, was man tut (und wer weiss das bei C++...), insofern ist es kaum universell brauchbar. > Welche konkreten Applikationen gab es und wie war der > Geschwindigkeitsgewinn? Von C++ und entsprechenden HDL-Ansätzen habe ich sehr schnell wieder die Finger gelassen, d.h., das hätte sich nicht amortisiert, darum: meine konkreten Anwendungen dieser Art sind in Python verfasst. Spontan fällt mir sonst an C++-Ansätzen die Toolchain von SiliconSoftware dazu ein, die speziell für Bildverarbeitungs-Pipelines entwickelt wurde. Am "high end" gibts dann vielleicht noch Celoxica, die wohl mit HF-Trading ihre Kohle machen, sonst hat sich das ziemlich ausgedünnt..
Bei Bildverarbeitung kommt es darauf an, was man machen will: Bei allen iterativen Ansätzen, die unterschiedlichen Aufwand bedeuten, wie Objekterkennung, Pixelkorrektur, die aber komplex sind, macht ein C++ Ansatz Sinn, weil man die Datenbehandlung von C verwenden kann. Ausserdem ist der Algogrithmus während er Entwicklung gut zu testen. Ansonsten sehe Ich wenig Ansätze. C++ im FPGA ist etwas für Softwarefreaks, die sich gerne mal damit brüsten wollen, ein FPGA entwickelt zu haben.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.