Moin Gemeinde, Für einige komplexere Sachen sind wir hier an die Grenzen mit der klassischen Simulationstaktik (brav VHDL-coden/ Testvektoren generieren) gestossen. Deswegen habe ich mir mal GHDL unter die Lupe genommen, und bin ziemlich begeistert (bis auf weiteres darf Isim mal schlafen). Das eigentliche Problem: Man kann ja C-Routinen aus einem 'process' aufrufen (über das mehr oder weniger bei GHDL kaum dokumentierte VHPI-Interface), aber zur gezielten Kontrolle durch einen C-Master gibt's vermutlich keinen einfachen Weg, ausser, das ganze mit einem separat laufenden Thread und einem Interface (in diesem Fall ein simples Software-FIFO) zu lösen. Aber vielleicht kann mich da einer der GHDL-Experten belehren.. Die Lösung mit dem Thread ist insofern elegant, dass man über lokale Pipes/Sockets oder Netzwerk (netpp) dieselben C-Testroutinen für die Hardware wie auch für die Simulation benutzen kann. Per netpp ist auch das Python-Scripting gleich mit erschlagen. Habe mal hier ein sehr primitives Framework angefangen: http://section5.ch/downloads/ghdlex-0.0eval.tgz Interessant für akademische Zwecke wäre u.U. ein virtuelles FPGA-Board, das man damit auch erschlagen könnte. Z.B. ein Front-End in Java, welches so ein paar 7-Segment-Anzeigen, Buttons (natürlich mit Tastenprell-Simulation), usw. implementiert. Können die üblichen Moloch-Pakete wie Labview ja alles, aber das will sich ev. nicht jeder antun. Kennt da jemand ein Framework, was sich ev. zum Aufbohren eignen würde? Hat das ev. schon mal jemand mit Qucs versucht? Grüsse, - Strubi
Hört sich nicht so schlecht an. Ich bin ebenfalls dabei, mich mit GHDL zu befassen. ISIM nervt mich schon lange.
Moin, inzwischen habe ich ein paar ganz kranke Sachen versucht, z.B. einen virtuellen JTAG-Adapter mit angehängtem Softcore in der Simulation laufen lassen, der mit der echten Software (die auch die Hardware bedient) spricht. Ist zwar kein Ausbund von Geschwindigkeit, aber läuft immerhin einigermassen brauchbar mit dem gdb im Remote-Debugging-Betrieb. So lässt sich auch prima die Software verifizieren und ne Menge Testcases durchnudeln. Allerdings sollte man bzgl. kompletter Migration von isim nach GHDL vorsichtig sein, ich habe einige Probleme bei der Simulation von XilinxCoreLib-RTLs. Weiss noch nicht, ob's ein Bug ist, oder es am übel geschriebenen (und künstlich verstümmelten) Xilinx-Simulations-VHDL liegt. Weitere Updates (englisch): http://tech.section5.ch/news/ Grüsse, - Strubi
(über das mehr oder weniger bei GHDL kaum dokumentierte VHPI-Interface) Ja GHDL ist etwas schlecht in der Dokumentation. Ich habe deshalb mal ein Skript für GHDL geschrieben. http://www.dossmatik.de/ghdl/ghdl_unisim.pdf Seit dem Skript ist die Akzeptanz von GHDL deutlich gestiegen. Wenn du da auch was dokumentieren könntest wäre es nicht schlecht. Davon lebt das freie Tool. Dass jeder auch etwas zurück gibt oder einen Praktikanten mal ansetzen. Es ist auch gut für sich selbst zu dokumentieren, sonst muss man jedem im Projekt, und es kommen und gehen ständig welche, es erneut erklären und das kann schlauchen. > inzwischen habe ich ein paar ganz kranke Sachen versucht, z.B. einen > virtuellen JTAG-Adapter mit angehängtem Softcore in der Simulation > laufen lassen, der mit der echten Software (die auch die Hardware > bedient) spricht. Ist zwar kein Ausbund von Geschwindigkeit, aber läuft > immerhin einigermassen brauchbar mit dem gdb im > Remote-Debugging-Betrieb. So lässt sich auch prima die Software > verifizieren und ne Menge Testcases durchnudeln. > Das klingt sehr interessant. Bin auch an einem eigen Mips Softcore dran und hätte es ähnlich gelöst. Wenn ich Zeit habe schaue ich es mir mal an.
Hi René, ja, deinen Artikel kenne ich, Daumen hoch dafür. Klappt soweit auch, nur der Xilinx floating_point_v4_0 core bringt mein GHDL zum crashen. Noch kein Echo von den GHDL-Jungs... Ich probier's ev. irgendwann mal wieder mit den neueren Cores, die Sache hab ich nur interessehalber versucht zu portieren. Dokumentation zu der Geschichte ist geplant (erst mal Doxygen). Die Bibliothek waechst ansich laufend, wenn es auch andern dient - fein. Wenn die Nachfrage wächst, wird auch der Doku-Druck grösser, momentan ist das nur alles bisschen auf low prio (und ich tendiere zu: read the source, luke). Mips klingt interessant. Ich hatte mal vor einer geraumen Weile den Plasma-Core angeguckt. Was den meisten Cores halt fehlt, ist ein vernuenftiger JTAG-HW-Debugger (meine Spezialität seit einigen Jahren). Hast Du Plaene, den EJTAG-"Standard" zu implementieren? Habe das mal bei der Plasma evaluieren wollen, bin aber wegen der Einfachheit doch erst mal bei der ZPU steckengeblieben und habe nen relativ generischen TAP-Layer rangebacken. U.U. würde ein MIPS-Core später interessant, aber momentan läuft alles noch auf alten Spartan3s, da wird das alles etwas eng und langsam. Deine (geplanten) Specs zu deinem Core würden mich natürlich interessieren. Grüsse, - Strubi
hi Strubi s > ja, deinen Artikel kenne ich, Daumen hoch dafür. Klappt soweit auch, nur > der Xilinx floating_point_v4_0 core bringt mein GHDL zum crashen. Noch > kein Echo von den GHDL-Jungs... Ich probier's ev. irgendwann mal wieder > mit den neueren Cores, die Sache hab ich nur interessehalber versucht zu > portieren. ja ich habe auch bei einem anderem Core Probleme gehabt und mich an Xilinx gewendet. Rückantwort null. Die Stelle lokalisiert und mich an die Entwickler von GHDL gewandt. Es wird sich nicht an dem VHDL Standard gehalten. > Wenn die Nachfrage wächst, wird auch der Doku-Druck grösser, momentan > ist das nur alles bisschen auf low prio (und ich tendiere zu: read the > source, luke). GHDL source code habe ich mich mir noch nie angeschaut. > > Mips klingt interessant. Ich hatte mal vor einer geraumen Weile den > Plasma-Core angeguckt. Was den meisten Cores halt fehlt, ist ein > vernuenftiger JTAG-HW-Debugger (meine Spezialität seit einigen Jahren). > Hast Du Plaene, den EJTAG-"Standard" zu implementieren? Habe das mal bei > der Plasma evaluieren wollen, bin aber wegen der Einfachheit doch erst > mal bei der ZPU steckengeblieben und habe nen relativ generischen > TAP-Layer rangebacken. > U.U. würde ein MIPS-Core später interessant, aber momentan läuft alles > noch auf alten Spartan3s, da wird das alles etwas eng und langsam. Deine > (geplanten) Specs zu deinem Core würden mich natürlich interessieren. Spec: momentan bin ich bei 125Mhz Maximal Frequenz auf dem Spartan6. Ich habe den Plasma mal neu strukturiert. Da ist die eigentliche Neuerung. Die Interrupts und den Coprocessor 0 konnte ich im Code nicht mehr klar erkennen. Es tauchen immer mal neue kleine Probleme auf und die schlauchen. Die Debug Engine habe ich mir mal angeschaut, so kompliziert ist die gar nicht. Etwas verdrängt momentan. Die JTAG Statemaschine ist mir noch etwas unklarer. Wird sicher bald aktueller um effektiver selber zu validieren. Momentan kämpfe ich mit den Befehlen laden und speichern. Hier werde ich Notgedrungen ein paar Stalls (pipeline anhalten) einbauen müssen. Da die Compiler Mist erzeugen können.
Hi René, René D. schrieb: > ja ich habe auch bei einem anderem Core Probleme gehabt und mich an > Xilinx gewendet. Rückantwort null. Die Stelle lokalisiert und mich an > die Entwickler von GHDL gewandt. Es wird sich nicht an dem VHDL Standard > gehalten. Das ist ja beim grossen X andauernd so, aber diesmal ist's irgend ein interner Bug mit illegalen Werten. Hat hoffentlich nicht mit 32/64-Bit zu tun.. > GHDL source code habe ich mich mir noch nie angeschaut. Eigentlich meinte ich die C-Erweiterung. Mit Ada-Interna hab' ich mich noch nicht beschäftigt.. Zu deiner Plasma-Version: 125 MHz ist ja ganz ordentlich. Beim nächsten "Upgrade" werde ich mir das wohl auch mal ansehen, die ZPU ist nicht das Ende der Strasse.. Der Debug-Kram ist eigentlich keine Hexerei, der TAP- und JTAG-Controller ist hier als git-Fork zur ZPU verfügbar: http://repo.or.cz/w/zpu.git/commit/91e13ae045ee76c25b8883013d386beab3cb8086 Da soweit generisch, lässt sich das ansich relativ leicht auf andere CPUs anpassen. ABER: Für den gdb nach JTAG proxy ('gdbproxy') muss man pro CPU-Architektur ein target-backend implementieren. Planst Du das openzusourcen? Ev. würde ich mir dann den Debug-Schuh anziehen. Man müsste sich nur auf einen "Standard" einigen und überlegen, wie man den eigentlichen JTAG-Port nach aussen implementiert und ob man die EJTAG-Spec nutzt. Es gibt da bei Xilinx die USER-Register, über die man Kommandos tunneln könnte, per Xilinx-Primitive kann man dann mit einem Softcore im Prinzip sprechen. Bin aber auf dieser Seite nicht weiter vorgestossen und habe einfach direkt nen JTAG-ADapter an generische I/Os angehängt. Gruss, - Strubi
> Planst Du das openzusourcen? Ev. würde ich mir dann den Debug-Schuh > anziehen. Man müsste sich nur auf einen "Standard" einigen und Open source hatte ich vor, doch nicht GPL. Ich bin selbstständig und muss auch mein Geld verdienen. Da würde ich mich selber bei eigenen Projekten aussperren. Leider habe ich schon viel Zeit reingesteckt und hätte mit was anderem Geld verdienen können. Ich dachte an 10Freie Lizenzen (für die Bastler) und bei höheren Stückzahlen dann an eine Gebühr (gewerbliche Verwendung). Genau habe ich mir das auch noch nicht überlegt. Ich habe den Aufwand betrieben, weil ich mir keine Microblazelizenz für mal eben zum Spielen leisten kann. Wenn ich ein Projekt gehabt hätte, dann hätte ich die 3000Euro Umlegen können. Alle könnten sich die Lizenzgebühr sparen, dann sollte auch war für mich drinnen sein. Sicher Unterstützung wäre manchmal nicht schlecht. Auch ein Gesprächsparter fehlt mir manchmal. Ich muss das Ganze mal dokumentieren. >Es gibt da bei Xilinx die USER-Register, über die man Kommandos tunneln Es gibt eine Möglichkeit den JTAG Chain um den TAP des Softcores zu ergänzen. (ein weiterer Knoten ist in der Kette)
René D. schrieb: > Es gibt eine Möglichkeit den JTAG Chain um den TAP des Softcores zu > ergänzen. (ein weiterer Knoten ist in der Kette) Dazu musst du aber doch eine der üblichen BSCAN-Primitiven nutzen, richtig? Ich dachte, die unterstützen nur USERx-Kommandos und keine eigens definierten. Wäre aber kein Problem. Man hat dann halt nur zwei verschiedene TAP-Treiber (einen für den EJTAG-Standard, einen für die "getunnelte" Xilinx-Version. Habe es auch noch nicht probiert, BSCAN-Primitiven zu kaskadieren (ich weiss nicht mal ob das mein Sp3 kann). Zum Thema Geld verdienen: Volles Verständnis. Ich hoffe, du holst den reingesteckten Aufwand übers Consulting rein. Klappt bei mir bestens.. GPL is teils fragwürdig, aber du könntest ein Dual-Lizenzmodell machen (wer seinen Code nicht offenlegen will, braucht eine Lizenz). Das aber nur so am Rande.
Strubi schrieb: > Dazu musst du aber doch eine der üblichen BSCAN-Primitiven nutzen, > richtig? Ja. Dummerweise heißen die in jeder Familie etwas anders (BSCAN_$FAMILY)und sie unterscheiden sich auch leicht voneinander. > Ich dachte, die unterstützen nur USERx-Kommandos und keine > eigens definierten. Wäre aber kein Problem. Man hat dann halt nur zwei > verschiedene TAP-Treiber (einen für den EJTAG-Standard, einen für die > "getunnelte" Xilinx-Version. Vorteil der Xilinx-Variante ist, das man kein extra Kabel/Adapter und keine extra Pins bräuchte. Ansonsten wollte ich mal Danke sagen für Eure Arbeit. Ich werde mir bei Gelegenheit die GHDL/C Integration mal anschauen. Duke
> Zum Thema Geld verdienen: Volles Verständnis. Ich hoffe, du holst den > reingesteckten Aufwand übers Consulting rein. Klappt bei mir bestens.. Hast du ein festen Baukasten und bietest dann Kundenanpassung an? Oder wie läuft das? > GPL is teils fragwürdig, aber du könntest ein Dual-Lizenzmodell machen > (wer seinen Code nicht offenlegen will, braucht eine Lizenz). Das aber > nur so am Rande. GPL verbietet auch das Einsetzen von Cores, die nicht offen gelegt sind. Und wenn ein Modul im FPGA das nicht ist geht es nicht. Dual Lizenz habe ich auch dran gedacht, doch wenn jemand im GPL Code was schreibt, kann ich es in der anderen Lizenz nicht verwenden. Ich hatte eher an BSD Lizenz gedacht oder so was ähnliches. Es fehlt mir da auch die Erfahrung.
Hi René, Baukasten stimmt genau. Im Grunde genommen ist es ein Kompromiss zwischen OpenSource (auf das sich die Fachwelt auch langsam einschwingt) und vielen eigenen closed tools und Hardware (JTAG-Toolchain). Leider wird man mit dem 100%igen OpenSource-Ansatz oft beklaut... Die Kunden wollen ja meist einen Mix aus: - Günstig, aber nicht billig - Robust und kalkulierbares Risiko - Offen für eigene Entwicklungen und Erweiterungen - Gute Doku - Fallback-Szenario, falls du mitten im Projekt eine Gräte verschluckst, usw. Also bietet sich bewährtes OS mit eigenen cleveren Erweiterungen an, wenn du Segger und Konsorten (in einer gewissen Nischt natürlich nur) Konkurrenz machen willst. Aber es gibt sicher sehr viel mehr "DOs" als "DONT's", und irgendwie findest Du eben deine Nische. Zu GPL: das Problem mit Fremdcode hast Du natürlich unter Umständen. Aber es ist ja kein Problem, vom Autor des Fremdcode ein Nutzungsrecht unter deiner "kommerziellen" Lizenz zu erwerben. Es soll ja jeder seine Arbeit auch irgendwie bezahlt bekommen. Mit der BSD-Lizenz ermunterst Du den Kunden allenfalls weniger, deine Entwicklung zu bezahlen. GPL is halt insofern schickes "Boilerplate", dass Du den Bastlern die Freiheit gibst, Modifikationen vorzunehmen, aber dem Kunden ansich zunächst Steine in den Weg legst, weil er mit dem einbauen von GPL-Code seinen Code infiziert (oder Lizenzimkompatibilitäten schafft). Ok, da gibt es genügend Firmen, die sich darum einen Käse scheren, aber das sind eh nicht deine Kunden, und wenn, verarschen sie dich sowieso :-) Mit deiner kommerziellen Lizenz löst Du dieses Problem wieder, zudem kannst du damit ein Supportpaket verkaufen, welches dem Kunden eine gewisse Sicherheit garantiert - solange du keine Gräte verschluckst. Und wenn das doch geschehen sollte, hat er immerhin die Sourcen. Ich denke, das Argument zieht bei den meisten mittelständischen Betrieben die von den teuren (und teils altmodischen) closed-source-Lösungen die Schnauze voll haben. Natürlich kannst Du unter obigen Aspekten auch deine eigene Lizenz entwerfen, der den Bastler zwingt, seine Veränderungen/Erweiterungen unter deine Lizenz zu stellen, aber das ist ev. für den Anfang zuviel Arbeit. Bezogen auf Busines-Model basierend auf einem Soft-Core ist das noch knifflig, denke ich. Die meisten Kunden sind für solche Technik einfach noch nicht "ready" oder trauen nur dem grossen X oder A oder L. Ich denke aber, es ist eine Frage der Zeit, wann Du mit einem clever designten Core und guten Beispielanwendungen so einige Projekte ins Haus holen kannst, denn die Tage der 'alleskönnenden' DSPs werden u.U. bald gezählt sein.. irgendwann bestellen wir unsern ASIC wie die Platine beim PCB-Pool :-) In diesem Sinne: Bloss nicht aufgeben. Gruss, - Strubi
Hallo René (und ev. interessierte), habe mal angefangen, ein paar Tricks zu dokumentieren, allerdings erst mal auf englisch (worum man ja eh nicht wirklich rumkommt). Habe mir natuerlich auch erlaubt, dein HOWTO zu zitieren. Link: http://www.fpgarelated.com/showarticle/20.php Wenn mehr gute Beispiele/Anwendungen Schule machen, motiviert das vielleicht auch noch ein paar andere. Gruss, - Strubi
Strubi schrieb: > Wenn mehr gute Beispiele/Anwendungen Schule machen, motiviert das > vielleicht auch noch ein paar andere. Das ist richtig und würde mich freuen, wenn es mehr zu lesen gibt. Hallo Strubi, du kannst mich gerne erwähnen. Ich habe gemerkt, nach dem ich meine Einführung in GHDL geschrieben habe, dass die Akzeptanz für GHDL gestiegen ist. Dass GHDL in ADA geschrieben ist, schreckt die Meisten ab. Weiter hinten erwähnen, sonst wird von vielen der Artikel nicht weiter gelesen. Im Englischen Wortschatz bis du mir voraus. Dein Artikel ist gut, hat aber ein paar Macken. Wenn ich meine Anmerkungen hier geben darf. Ich hoffe du nimmst es mir nicht übel. In dem ersten Prozess brauchst du keine loop. Der Prozess wird selbst immer wieder erneut gestartet. In deinem VHDL Beispiel sind in der Mitte der beiden Prozesse Fehler!! Es fehlen die Zuweisungen: clk<= not clk; sigterm<='1'; Die Extension hätte ich in der Einführung mit dem linker ld zusammengehangt und nicht erst eine library erzeugt. Die Library macht es Unverständlicher. Eine Library zeugt man sich mit einem höherem Level.
Hi René, > > Ich habe gemerkt, nach dem ich meine Einführung in GHDL geschrieben > habe, dass die Akzeptanz für GHDL gestiegen ist. Dass GHDL in ADA > geschrieben ist, schreckt die Meisten ab. Weiter hinten erwähnen, sonst > wird von vielen der Artikel nicht weiter gelesen. > Das glaube ich eigentlich nicht...die meisten GHDL-User sind eben auch 'User' und wollen nicht am Simulator direkt herumprogrammieren. > Im Englischen Wortschatz bis du mir voraus. > Dein Artikel ist gut, hat aber ein paar Macken. Wenn ich meine > Anmerkungen hier geben darf. Ich hoffe du nimmst es mir nicht übel. > > > In dem ersten Prozess brauchst du keine loop. Der Prozess wird selbst > immer wieder erneut gestartet. > Ist die Testbench..also der Stimulus. Das muss schon so. > > In deinem VHDL Beispiel sind in der Mitte der beiden Prozesse Fehler!! > Es fehlen die Zuweisungen: > clk<= not clk; > sigterm<='1'; > Ja, der Editor mag irgendwie meine HTML-Konversion nicht und zersaebelt mir fortlaufend das File. Habs nun reingelinkt. > > Die Extension hätte ich in der Einführung mit dem linker ld > zusammengehangt und nicht erst eine library erzeugt. Die Library macht > es Unverständlicher. Eine Library zeugt man sich mit einem höherem > Level. Mit der library ist es 'sauberer', wenn man spaeter weitere Abhaengigkeiten einfuegt. Die '-Wl,-W$(objfile)'-Konstrukte fuer GHDL kann man sich zwar per Makefile generieren, aber wenn Dir noch eine elegantere Loesung einfaellt, schreib sie doch in die Kommentarzeile rein. Gruss, - Strubi
Martin S. schrieb: > Mit der library ist es 'sauberer', wenn man spaeter weitere > Abhaengigkeiten einfuegt. Die '-Wl,-W$(objfile)'-Konstrukte fuer GHDL > kann man sich zwar per Makefile generieren, aber wenn Dir noch eine > elegantere Loesung einfaellt, schreib sie doch in die Kommentarzeile > rein. Die Library ist sicher was Höherwertigeres als der Vorschlag von Rene. Rene`s Vorschlag hat was mit Methodik zu tun, wie man etwas vermittelt. Du hast so viele Tools aus der gcc-Toolchain eingeführt, wo ich passen muss. Die Sache hätte mich auch interessiert. Mit Sicherheit ist es auch für einen User mit einem niedrigerem Level nutzbar.
Martin S. schrieb: Hallo Martin, >> >> In dem ersten Prozess brauchst du keine loop. Der Prozess wird selbst >> immer wieder erneut gestartet. >> > > Ist die Testbench..also der Stimulus. Das muss schon so. > Ich sehe du hast eine delay Zeit vor dem Takt erzeugt. Das war mir nicht ersichtlich in der fehlerhaften Html Darstellung des Codes. > aber wenn Dir noch eine > elegantere Loesung einfaellt, schreib sie doch in die Kommentarzeile > rein. Ich merke im muss mich schleunigst mal hier Einarbeiten. > Zu Otto Martin scheint mehr von der Softwareschiene zu kommen, und hat hier mehr Ahnung als ich. Vielleicht sollte ich mit Martin mal ein Paper zusammenschreiben.
Salut, der Thread ist zwar schon etwas vergilbt, aber vielleicht ist es ja für einige von euch GHDL-Hackern interessant: Der obige 'subversive' Ansatz hat trotz Naserümpfen in Richtung Linux einigen Anklang gefunden (siehe auch Linux-Magazin 02/2012), so wird sich also an der embedded world 2012 (Nürnberg) die Gelegenheit ergeben, einige GHDL-Lösungen vorzustellen. René: Hast Du ev. noch eine interessante Beispielanwendung zu Deinem MIPS-Clone? Falls einer von Euch (am 29. oder 1.) an die Messe ginge, ergäbe sich ev. die Chance, ein paar interessante Sachen einzubringen oder einfach bei einem Bierchen zu diskutieren. Grüsse, - Strubi
Martin S. schrieb: > Salut, > > der Thread ist zwar schon etwas vergilbt, aber vielleicht ist es ja für > einige von euch GHDL-Hackern interessant: Der obige 'subversive' Ansatz > hat trotz Naserümpfen in Richtung Linux einigen Anklang gefunden (siehe > auch Linux-Magazin 02/2012), Ich dachte schon der Thread ist tot, hatte auch schon Sorgen. Der gefiel mir auch gut. Ich habe das Heft nicht vorliegen. Im Netz habe ich nur erfahren unter weitere Themen im Heft, Hardware-Simulation. Hast du den Artikel geschrieben? >so wird sich also an der embedded world > 2012 (Nürnberg) die Gelegenheit ergeben, einige GHDL-Lösungen > vorzustellen. Hast du einen Vortrag oder so? > René: Hast Du ev. noch eine interessante Beispielanwendung zu Deinem > MIPS-Clone? Bin noch dran. Aber ich hätte noch andere schöne Sachen. Leider fehlt mir gerade die Zeit. Wie wäre es mit einem seriellen Terminal. Zeichen kommen an einem Seriellen Port an und werden als ASCII auf dem VGA-Monitor dargestellt. So ähnlich wie ein VT100 nur ohne Esc Sequenzen. Das wollte ich schon länger mal als Fortführung zu meinem Intro pdf schreiben. VHDL code ist schon geschrieben und in Hardware getestet. Für eine "GHDL geniale" Simulation müssten noch zwei kleine C-code Programme geschrieben werden. a) ein Eingabeprogram, die Zeichen verschickt/ (genialer wäre eine virtuelle COM, dan könnte man Hterm sogar nutzen) b) eine Software geschrieben werden, die eine Bildschirmausgabe simuliert. Da gab es auch schon mal einen guten Anfang in einem Thread mit SDL. Wobei ich QT oder gtk bevorzugen würde. Das als Demo würde den Vogel abschießen, Ich hätte noch ein paar andere Sachen, doch als Lernschritt ist eine Zeichenausgabe wichtig und gut erklärbar. > Falls einer von Euch (am 29. oder 1.) an die Messe ginge, ergäbe sich > ev. die Chance, ein paar interessante Sachen einzubringen oder einfach > bei einem Bierchen zu diskutieren. Würde mich auch freuen, sich mal kennen zu lernen. ES ist noch nicht ganz raus ob ich fahre. Gut zu wissen, dass du dorthin fährst. René
Hi René, die Idee mit dem Terminal ist gut, ich habe auch mal so'n Spassprojekt mit nem LCD angefangen, allerdings ist das letzte Drittel, um's auf nen virtuellen Schirm aufzubohren, doch noch ein Stück hin. Ich dachte ansich eher an ein simples Beispiel zum Debugging (darüber geht die Präsentation), wie das hier: http://section5.ch/doc/jtag/movies/inspect.html Mit einem MIPS wäre das ev. relativ "heiss". Die angesprochenen C-Progrämmchen sind ansich kein grosses Ding mehr, die Zeichen-I/O könnte man mit den ghdl-extensions per Pipe erschlagen. Ist halt leider nicht bidirektional, dass man mit dem Terminal drauf kann.. Muss da mal drüber nachdenken. Sollte halt irgendwie was mit JTAG/debugging dabei sein.. Gruss, - Strubi
Martin S. schrieb: > Hi René, > > die Idee mit dem Terminal ist gut, ich habe auch mal so'n Spassprojekt > mit nem LCD angefangen, allerdings ist das letzte Drittel, um's auf nen > virtuellen Schirm aufzubohren, doch noch ein Stück hin. > Ich dachte ansich eher an ein simples Beispiel zum Debugging (darüber > geht die Präsentation), wie das hier: Ich würde in C parallel ein Bildschrimspeicher fahren und nicht das array aus VHDL. Dieser Bildschirm muss nur geändert werden, wenn ein neues Zeichen in den Bildschirmspeicher geschrieben wird. Da müssen nur die Änderungen aktualisiert werden. > http://section5.ch/doc/jtag/movies/inspect.html > > Mit einem MIPS wäre das ev. relativ "heiss". > > Die angesprochenen C-Progrämmchen sind ansich kein grosses Ding mehr, > die Zeichen-I/O könnte man mit den ghdl-extensions per Pipe erschlagen. > Ist halt leider nicht bidirektional, dass man mit dem Terminal drauf > kann.. > Muss da mal drüber nachdenken. Eine virtuelle Com Schnittstelle wäre was. Das VHDL-Programm hat eine serielle Schnittstelle dazu wird ein C Programm gelinkt. (GHDL VHPI) Das C-Programm hat den Zweck eine Serielle Schnittstelle im System herzustellen. Unter /dev/vcom1 wird ein Link auf die Exe. Dann sollte es sich wie ein eine normale Com Verhalten. Es brauch nur eine Baudrate zu unterstützen. Oder einen Zufallsgenerator in VHDL und eine statistische Auswertung der Verteilung in C. Zur Validierung des Zufallsgeneratiors. Sollte halt irgendwie was mit > JTAG/debugging dabei sein.. Jtag habe ich leider nichts. Ich verstehe dein Anliegen. René
Hi René, hast Du deine virtuelle COM als OpenSource geplant? Wäre was für die ghdlex library (da sind schon FIFO und Pipe-Interfaces dabei). Leider ist grade vor allem JTAG im Fokus. Aber mal sehen, was noch so kommt. Habe mal die restlichen Mitschnitte der Debug-Beispiele hochgeladen. Hätte das gerne noch mit dem Plasma gemacht, aber dazu reicht die Zeit nicht mehr. http://section5.ch/doc/jtag/movies/ Grüsse, - Strubi
Hallo Martin, hier ist noch ein JTAG Projekt. Das wäre auch noch ein richtiger Bringer. Wenn du den Sump Logik analyzer hinbekommst, da kann man die Simulation mit der Hardware richtig vergleichen. Beitrag "Logic Analyzer im FPGA via JTAG" hast Du deine virtuelle COM als OpenSource geplant? Wäre was für die ghdlex library (da sind schon FIFO und Pipe-Interfaces dabei). Die Virtuelle COM habe ich noch nicht angefangen.
Hi René, > hier ist noch ein JTAG Projekt. Das wäre auch noch ein richtiger > Bringer. > Wenn du den Sump Logik analyzer hinbekommst, da kann man die Simulation > mit der Hardware richtig vergleichen. > > Beitrag "Logic Analyzer im FPGA via JTAG" Den Sump kenne ich, nur mag ich das Java-Zeug überhaupt nicht. GTKwave macht den Job optial. Der Knackpunkt an dieser Art "Logik Analyzer" ist, dass man eine höchst schnelle und synchrone JTAG-Logik braucht, um vernünftig auslesen zu können. Da macht es IMHO mehr Sinn, einen dedizierten LA schon im FPGA zu integrieren und über einen Cypress FX2 anzusteuern. Habe das vor Urzeiten mal auf nem EFM01-Board (cesys) implementiert, aber nie wirklich benutzt, es ist dann oft doch einfacher, den echten LA bzw. Oszi mit den anständigen Probes anzustöpseln. Denn mit Chipscope-artigen Debuggern siehst Du nie die wirklich heftigen Timing-Probleme, bzw. ist das ganze so oder so "intrusive" und tut genau dann nicht, wenn du nicht den Debugger drin hast, und solche Spässe. Die andere Taktik ist, einfach einen dedizierten Trace-Buffer per Emulation auszulesen. Das klappt prima, wenn man das Event, welches das Problem verursacht, auf der Hardware eingekreist hat und man es leicht per In-Circuit-Emulation triggern kann. Insofern sehe ich den Nutzen (für mich persönlich) bei einem weiteren Chipscope nicht wirklich. Grüsse, - Strubi
Strubi schrieb: > Hi René, > >> hier ist noch ein JTAG Projekt. Das wäre auch noch ein richtiger >> Bringer. >> Wenn du den Sump Logik analyzer hinbekommst, da kann man die Simulation >> mit der Hardware richtig vergleichen. >> >> Beitrag "Logic Analyzer im FPGA via JTAG" > > Den Sump kenne ich, nur mag ich das Java-Zeug überhaupt nicht. GTKwave > macht den Job optial. Das Java find ich auch doof. Ich wollte dir was mit JTAG vorstellen. > Die andere Taktik ist, einfach einen dedizierten Trace-Buffer per > Emulation auszulesen. Das klappt prima, wenn man das Event, welches das > Problem verursacht, auf der Hardware eingekreist hat und man es leicht > per In-Circuit-Emulation triggern kann. Was ist ein dedizierter TRACE Buffer? Kannst du das noch etwas genauer erklären?
René D. schrieb: > Was ist ein dedizierter TRACE Buffer? > Kannst du das noch etwas genauer erklären? Einfach ein interner oder auch externer RAM-Buffer (SRAM), der Clock-Nummer und States oder Signale der CPU bzw. State-Machine mitloggt. Dediziert deshalb, weil das Trace-Modul immer mehr oder weniger auf das eigentliche Problem angepasst wird. Die Trace-Unit wird per I/O-Register über den Soft-core konfiguriert und auch ausgelesen. Per Script wird dann u.U ein VCD-Wavefile ausgeworfen. Wenn die Buffer schnell genug auch per USB ausgespuckt werden, geht's sogar 'live' mit GTKwave. Salut, - Strubi
Strubi schrieb: > René D. schrieb: >> Was ist ein dedizierter TRACE Buffer? >> Kannst du das noch etwas genauer erklären? > > Einfach ein interner oder auch externer RAM-Buffer (SRAM), der > Clock-Nummer und States oder Signale der CPU bzw. State-Machine > mitloggt. Dediziert deshalb, weil das Trace-Modul immer mehr oder > weniger auf das eigentliche Problem angepasst wird. Die Trace-Unit wird > per I/O-Register über den Soft-core konfiguriert und auch ausgelesen. > Per Script wird dann u.U ein VCD-Wavefile ausgeworfen. Wenn die Buffer > schnell genug auch per USB ausgespuckt werden, geht's sogar 'live' mit > GTKwave. > > Salut, > > - Strubi Das klingt interessant. Ich hatte nur mal so etwas auf dem Ethernet ausgegeben. Doch da war ich auf 8 bit breite beschränkt. Weil mein Ethernet Puffer 8bit breit war. Die Daten habe ich mir mit wireshark angeschaut. Nicht so ideal wie gtkwave. Könnte man die Skripte auf eine Uart standardisieren?
Die Ethernet-Lösung hört sich heiss an. Die Byte-Grössen sind ja kein
Problem, könnte man mit nem Coregen-FIFO schnell umgehen.
> Könnte man die Skripte auf eine Uart standardisieren?
Ist von der Python-Seite ansich unabhängig vom Interface, es gibt immer
einen Device-Wrapper (für Simulation, USB, oder auch serielle, etc.) und
ein Buffer, der über netpp (Netzwerk) per Python ausgelesen wird.
Zur Ausgabe in .vcd kannst Du Dir bei myhdl einiges abgucken.
Grüsse,
- Strubi
Thomas Ulrich schrieb: > Habt ihr das Thema weiterverfolgt? Ich arbeite mti GHDL sehr viel und möchte das Tool nicht missen. Die C Schnittstelle habe ich lange nicht mehr benutzt. Als reinen VHDL Simulator ist GHDL ein sehr sinnvolles Tool.
Thomas Ulrich schrieb: > Habt ihr das Thema weiterverfolgt? Jau, die Entwicklung ist noch recht aktiv. Es gibt eine vollständige Virtualisierung eines SoC, der genauso wie die Hardware, nur etwas langsamer mit den virtuellen Interfaces mit der Software kommuniziert bzw. per VirtualTAP (JTAG-Emulation) debuggt wird. Mehrere SoC-Instanzen laufen teils verteilt auf verschiedenen Kisten. Habe mal ein ghdlex-Update der Null-Version auf der GHDL-Mailing-Liste gepostet. Gruss, - Strubi
Hört sich ja alles sehr vielversprechend an. Sobald die aktuelle ModelSIM Lizenz meines Momentankunden abgelaufen ist, werde ich mich mal damit befassen. Die 12k sollte man ja wohl einsparen können.
Thomas Ulrich schrieb: > Hört sich ja alles sehr vielversprechend an. Sobald die aktuelle > ModelSIM Lizenz meines Momentankunden abgelaufen ist, werde ich mich mal > damit befassen. Die 12k sollte man ja wohl einsparen können. Die 12k auf jeden Fall. Es wird ein Prozess sein. Einfach umswitchen ist es auch nicht. Man gewöhnt sich auch an den Code, den GHDL simulieren kann und wenn die Simulation gut war, lief Sie auch in der Hardware.
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.