Hallo an alle, ich habe eine Leiterplatte entwickelt mit einem Spartan 6 darauf. Ich konnte diesen mit dem ISE Project Navigator programmieren und habe ein paar einfache Logiken ausprobiert. Hat alles auf Anhieb funktioniert. Nun würde ich gerne "richtig" VHDL lernen, um auch anspruchsvollere Aufgaben umsetzen zu können. Die Frage lautet nun: Wie lerne ich das am besten? Habt ihr das mit Büchern(welche?), Online-Tutoriale(URL?), Kurse(bei wem und wo?) gelernt oder hattet ihr jemandem der euch das beigebracht hat?
Bei mir hat es in der Uni angefangen bzw. das Interesse geweckt an VHDL. Später habe ich mich im Job weiter entwickelt, ohne Anderen (Arbeitskollegen) bei LearningByDoing. Natürlich mit Hilfen von Forenseiten, wie z.B. µC.net :-) (sollte ja bekannt sein). Empfehlen kann ich dabei folgendes Buch: VHDL-Synthese Entwurf digitaler Schaltungen und Systeme 5. Auflage (könnte neuere geben) von Jürgen Reichardt und Bernd Schwarz ISBN 978-3-486-58987-0 Kurse von PLC2 (siehe Hompage) sind sehr gut. Da gibt es auch Einsteigerkurse und auch professionelle für später. Kann man sich also gut weiter entwickeln. Gruß Cihan
Dennis R. schrieb: > Nun würde ich gerne "richtig" VHDL lernen, um auch anspruchsvollere > Aufgaben umsetzen zu können. Konterfrage: willst du "VHDL" lernen, oder willst du "FPGA" lernen? Denn 95% von VHDL ist für die Simulation gut, 5% für die Synthese... > Die Frage lautet nun: Wie lerne ich das am besten? In der Praxis, mit dem RTL-Schaltplan. Denn da siehst du erst mal, was die Synthese aus deiner Beschreibung macht. Und manchmal siehst du ganz unerwartete Dinge, wie dort die zwei zusätzlichen Inverter, obwohl die Beschreibung genau gleich ist: http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html > Habt ihr das mit Büchern(welche?), Ich habe einige Bücher über VHDL gekauft, aber die Augen geöffnet haben mir Reichardt&Schwarz. Und zwar so gut, dass ich jetzt auch die Fehler bzw. Probleme in diesem Buch erkennen kann: Beitrag "Re: Verständnisproblem Xilinx XC9572 CPLD" > Online-Tutoriale(URL?), Nein. Gabs so gut wie nicht... > Kurse(bei wem und wo?) gelernt oder hattet ihr jemandem der euch das > beigebracht hat? PLC2. Eugen Krassin ist einer der alten Xilinx-Haudegen...
Dennis R. schrieb: > Nun würde ich gerne "richtig" VHDL lernen, um auch anspruchsvollere > Aufgaben umsetzen zu können. Die Frage lautet nun: Wie lerne ich das am > besten? Cihan Kalayci schrieb: > Natürlich mit Hilfen von > Forenseiten, wie z.B. µC.net :-) (sollte ja bekannt sein). Nur zur Sicherheit. Die VHDL Seite hier bei www.mikrocontroller.net inkl. der Links unten auf der Seite hast Du schon gesehen, oder? http://www.mikrocontroller.net/articles/VHDL
Cihan Kalayci schrieb: > Empfehlen kann ich dabei folgendes Buch: > VHDL-Synthese > Entwurf digitaler Schaltungen und Systeme > 5. Auflage (könnte neuere geben) > von Jürgen Reichardt und Bernd Schwarz > ISBN 978-3-486-58987-0 Bei mir war es im Studium und mit dem Buch. Laut Autor kommt die neue Auflage des Buches Anfang Dezember.
Die Denkweise hab ich an der FH gelernt (Prof. Feske, HTW Dresden). In der Praxis dann musste ich gleich ins kalte Wasser springen (bzw. wurde gestoßen) und ein industrietaugliches Design aus einem zusammengestümperten Schematic Design machen. Da musste ich mir viel selbst beibringen. Ansonsten viel lesen. Kurse von PLC2 sind wohl wirklich sehr gut, aber das was ich bräuchte, ist zu speziell (MGT, PCIe), die sind immer ausgefallen wegen zu wenig Teilnehmern. Die Basic und Expert VHDL Kurse sind aber regelmäßig.
Cihan Kalayci schrieb: > von Jürgen Reichardt und Bernd Schwarz Das Buch wird immer wieder genannt und ich weiss nicht warum. Der Erkläranteil ist für einen Anfänger viel zu gering und für einen Fortgeschrittenen zu viel. Da muss was anderes bei. Ausserdem wird dort zu sehr auf die Sprache abgehoben. Was aber gebraucht wird, sind die Schaltungstechniken, also die Funktionen, nicht nur deren Umsetzung.
Vielen Dank für die Antworten. - Das Buch VHDL-Synthese habe ich nun - Ich würde gerne VHDL/FPGA lernen, so dass ich sowohl Simulationen fahren kann, als auch praktisch Logiken, Zähler, Seriell-Parallel-Wandler, Speicher etc. aufbauen kann - Danke für die Links Ich werde mal schauen, was ich mit Ausprobieren, Büchern und Google-Suche hinbekomme.
Dennis R. schrieb: > Habt ihr das mit Büchern(welche?) Ich hab mich durch den "Designer's Guide to VHDL" (Peter Ashenden) geackert, nur um dann festzustellen, daß nur ein Bruchteil von VHDL im FPGA synthetisiert werden kann (wie Lothar schon erwähnt hat). Ich wage mal zu behaupten, daß Beste ist üben, üben, pop-üben. Mit kleinen Sachen anfangen (LED-Lauflicht, Zähler, UART) und nicht gleich zuviel auf einmal wollen.
Pesto schrieb: > Das Buch wird immer wieder genannt und ich weiss nicht warum. > Der Erkläranteil ist für einen Anfänger viel zu gering und für einen > Fortgeschrittenen zu viel. Da muss was anderes bei. Ja, kennst du eines? Es ist (mit allen Fehlern) noch das überschaubarste und nachvollziehbarste "VHDL für FPGAs"-Buch, das ich gefunden habe. Und ich habe einige VHDL-Bücher... Ich muss allerdings sagen, dass ich vor ich dieses Buch gefunden habe, mit einigen anderen Büchern sehr auf die Nase gefallen bin. Da wurde total unreflektiert irgendwas hingeschrieben und simuliert. Und wenn die Simulation dann funktionierte, war das Design fertig. Wie (und ob überhaupt) die Beschreibung implementiert werden würde, war bei diesen VHDL-Büchern kein Thema. Es ging eben nur um VHDL, nicht um FPGAs...
Was Bücher betrifft finde ich "FPGA Prototyping by VHDL Examples" von Pong P Chu und auch noch ein anderes Buch vom gleichen Autor sehr erhellend und erfrischend praktisch. Das Reichard/Schwarz Buch finde ich ein bischen trocken, halt typisch für Fachbücher deutscher Autoren.
Hey Christian R, du kommst auch von der HTW? Welcher Jahrgang ? Gruß Marco
exseler schrieb: > "FPGA Prototyping by VHDL Example" von Pong P Chu > und auch noch ein anderes Buch vom gleichen Autor Dazu nur meine Bemerkungen in dem Beitrag "Re: Suche VHDL Buch" BTW: Ich hab mein Buch von Chu immer noch. Keiner wollte es mir abkaufen... :-(
@Dennis .R Hallo ich habe einen Tip Dr. Chu's books da ist VHDL u. auch Verilog dabei. Ich habe da schon einiges für ein test Design rausgeholt. Das ist was gutes ...auch Mico8 u. Xilinx Xilinx MicroBlaze SOC FPGA Hint: FSM SATE ENGINE mit Bildern. http://academic.csuohio.edu/chu_p/rtl/chu_rtL_book/rtl_chap10_fsm.pdf ********************************************************************* Da in den Büchern sind *.pdf HW samples drin. http://academic.csuohio.edu/chu_p/rtl/index.html ###################################################### Guss Holger.
Lothar Miller schrieb: > exseler schrieb: >> "FPGA Prototyping by VHDL Example" von Pong P Chu Das Buch ist didaktisch sehr gut. Die Beispiele sehr greifbar. Ein weiteres gutes Buch ist "Circuit Design and Simulation with VHDL" von Volnei A. Pedroni Du musst dir auch einen Simulator suchen mit dem du klarkommst. Der Code wird simuliert und dann muss er laufen. Die Kunst ist das Wechselspiel simulieren und in Hardware testen. Darin musst du lernen dich selbst einzuschätzen. Wann du den Code reif für die Hardware ist.
Holger Harten schrieb: > @Dennis .R > Hallo ich habe einen Tip > Dr. Chu's books da ist VHDL u. auch Verilog dabei. > Ich habe da schon einiges für ein test Design rausgeholt. > Das ist was gutes ...auch Mico8 u. > Xilinx Xilinx MicroBlaze SOC FPGA > Hint: > FSM SATE ENGINE mit Bildern. > http://academic.csuohio.edu/chu_p/rtl/chu_rtL_book... > ********************************************************************* > Da in den Büchern sind *.pdf HW samples drin. > http://academic.csuohio.edu/chu_p/rtl/index.html > ###################################################### > > Guss Holger. Sag mal Holger, was machst du eigentlich Beruflich? Ich kann mir kaum vorstellen, dass jemand, der wirklich nur unlesbaren Zeichensalat in seinen Beiträge produziert, in der Lage ist professionell und strukturiert Entwicklungsprojekte durchzuführen. =-O
Mal wieder interessante Beiträge. Was man aber nicht vergessen darf: 1. Nicht auf ein Buch vertrauen, mehrere lesen. 2. Dokus der Hersteller lesen (zu Design-Umgebungen,Devices etc...) 3. Designs der Dev.Kits durchackern (manche sind gut, andere OH+OH^2) 4. Constraints zu I/O/Logic verinnerlichen (oh man macht das Spass!) 5. hab ich was vergessen??
> 2002 habe ich gestartet und CT/AT studiert.
Ok das war noch vor meiner Zeit. Ich hatte erst 2006 angefangen.
Bist du noch im Raum Dresden tätig?
Entwickler12345 schrieb: > Bist du noch im Raum Dresden tätig? Ja, bin ich, hab einen tollen Job in der Forschung.
Christian R. schrieb: > Die Denkweise hab ich an der FH gelernt (Prof. Feske, HTW Dresden). Der Fischer hat mir in DS jeden Spaß an dem Fach genommen :-( Laut HTW-Seite gibts den wohl aber nicht mehr...
Hans Franz schrieb: > Der Fischer hat mir in DS jeden Spaß an dem Fach genommen :-( Naja, der Fischer war aber auch ein Ar***, das kann ich bestätigen. Das hatte auch nix mit Digitaltechnik zu tun, sondern mit Recht-Haben. Ich hab da eine 4 in der Prüfung bekommen, weil ich die Stromlaufpläne zwar richtig, aber nicht nach seinem eigenartigen Geschmack gezeichnet habe. Und sein Praktikum mit ABEL (Haben wir damals "advanced bastler encrypted language" genannt) auf GALs konnte man getrost in die Tonne bzw. in die Steinzeit kloppen. Prof. Feske hat allerdings sehr gut erklärt, wo der Unterschied zwischen einer HDL und einer Programmiersprache liegt, wie man am besten rangeht und wozu das eigentlich gut ist. Das Modelsim Praktikum war auch nicht schlecht. Haben aber wahrscheinlich weniger als eine handvoll Leute bei uns verstanden. Ist vielleicht auch gut so, sonst gäbe es viel mehr VHDL-Masochisten. Das meiste hab ich zwar in der Praxis durch Learning by doing mitbekommen, aber die Grundlagen hat der Feske gelegt.
Christian R. schrieb: > Naja, der Fischer war aber auch ein Ar***, das kann ich bestätigen. Das > hatte auch nix mit Digitaltechnik zu tun, sondern mit Recht-Haben. Ich > hab da eine 4 in der Prüfung bekommen, weil ich die Stromlaufpläne zwar > richtig, aber nicht nach seinem eigenartigen Geschmack gezeichnet habe. Kann ich so nur bestätigen. Beim Fischer hätte es gereicht, in der DS-Prüfung bei jeder Aufgabe eine halben Punkt zu vergeben. Entwender die Aufgabe war richtig und nach seinem einzigen Lösungsweg gelösst (halber Punkt) oder sie ist komplett falsch, auch wenn nur ein Zwischenschritt ein Fehler enthält. > Und sein Praktikum mit ABEL (Haben wir damals "advanced bastler > encrypted language" genannt) auf GALs konnte man getrost in die Tonne > bzw. in die Steinzeit kloppen. Das waren die LED-Lauflichter und die 7-Segmentanzeigen die da hochgezählt haben. Der Kühn hat das Praktikum mal mit betreut und sich über den Fischer lustig gemacht.
Hans Franz schrieb: > Der Kühn hat das Praktikum mal mit betreut und sich > über den Fischer lustig gemacht. Haha, na das glaub ich. Erst vor paar Tagen war ich als Gutachter/Betreuuer unseres Diplomanden bei ihm in der Verteidigung. Immer wieder herrlich seine Sprüche.
Christian R. schrieb: > 2002 habe ich gestartet und CT/AT studiert. Hey, willkommen im Club! Ich allerdings KT.
Nee, ich war der betriebliche Betreuer, war mit meinem Hiwi/Diplomanden an der HTW nur zur Verteidigung. Ich arbeite bei einer großen Forschungsgesellschaft, die in DD viele Institute hat...
Ich habe mit 2 ATler meine Diplomarbeit beim Hübi gemacht. Der eine hieß glaube ich Andre ?Thieme? und der andere war so ein kleiner Blonder, die hingen immer im Doppelpack zusammen.
VHDL habe ich gelernt mit Kesel, Bartholomä : Entwurf von digitalen Schaltungen und Systemen mit HDLs und FPGAs (Ich kenne nur die 1.Auflage.) Merkwürdig, dass das Buch hier im Forum so gut wie nie erwähnt wird.
Ich kaufe mal einige Bücher. Dennoch wird es hier sicher einiger Nachfragen bedürfen und einige Nervenzusammenbrüche mit sich bringen.
Der Fischer ist zum Glück in Rente und nun wird dort VHDL gelehrt. Der Kühn war mein Diplombetreuer zum Thema USB3.0. Da kann ich mir denken wo du arbeitest ;) Bist du eigentlich noch am FX3 dran? Ich bin nun fertig soweit ;) Gruß Marco
Dennis R. schrieb: > Ich kaufe mal einige Bücher. Dennoch wird es hier sicher einiger > Nachfragen bedürfen und einige Nervenzusammenbrüche mit sich bringen. Also ich würde mir nicht allzu viele Bücher kaufen. Geh doch mal in die Bib einer FH oder Uni. Da stehen oft ein paar Bücher zum Thema VHDL / FPGA rum. Schwarz/Reichardt reicht meiner nach am Anfang völlig aus. Denn es gibt im Netz auch noch ganz gute Quellen. Und wenn du mal mehr mit Simulationen machst kann ich das hier erwähnte Buch von Ashenden nur empfehlen. Ich habe mir einige Bücher in der Bibliothek angeschaut und dann nur die beiden erwähnten gekauft. Hat bis jetzt gereicht. Denn den Rest bekommst du entweder über die Doku des Herstellers oder ein Forum auch raus. Gruß Boris
Ebenfalls viele Grüße in die HTW-Runde. Ich kenne sowohl Prof. Fischer (und erinnere mich ungern an den ABEL-Quatsch), sowie seinen Nachfolger ;-) Duke P.S.: Und auch ich verdiene meine Brötchen in der Dresdner Forschungslandschaft...
Mein erstes Buch war: Lehmann/Wunder/Selz: Schaltungsdesign mit VHDL - gibt es als pdf. Insgesamt nicht wirklich schön und mittlerweile 18 Jahre alt. Ausserdem: Peter J. Ashenden - The Designers Guide to VHDL Und zum Weiterlernen in Verilog: Palnitkar: Verilog HDL: A Guide to Digital Design and Synthesis Ciletti: Advanced Digital Design with the Verilog(tm) HDL Doku, AppNotes, Eugen Krassin. Ansonsten: Übung macht den Meister!
Habt ihr da noch den Master nachgelegt? Ich dachte immer als FHler wird man in der Dresdner Forschung etwas ausgebeutet. Fachlich bestimmt sehr interessant aber vom Gehalt her bleibe ich lieber in der Industrie (Dresdner Umland) Gruß Marco
USB 3.0 mit dem FX3 läuft prima, macht mittlerweile keine Probleme mehr. Ich werde besser bezahlt als Kollegen mit Uni-Diplom, bin Teamleiter eines kleinen, effizienten Entwicklerteams. Ist doch alles Verhandlungssache, aber es stimmt, zum Anfang braucht man einen langen Atem. Dafür gibts einen sicheren Arbeitsplatz und spannende Themen.
Na das klingt doch super. Ich war auch immer wieder mal kurz davor mich zu bewerben. Eben weil das ein spannenderes und interessanteres Arbeiten ist. Nur viele raten mir immer ab, eben weil schlechter bezahlt und weil meistens nur befristet eingestellt wird.
Schlechter bezahlt kommt halt immer drauf an. Ist Ostdeutschland kann der TVÖD durchaus mit Mittelständlern mithalten, in Wilschdorf oder bei Infineon verdient man natürlich deutlich mehr. Anfangs ist immer befristet, das ist richtig, ich hab aber mittlerweile auch einen unbefristeten Vertrag, und wie geschrieben recht gute Konditionen.
Christian R. schrieb: > Anfangs ist immer > befristet, das ist richtig, ich hab aber mittlerweile auch einen > unbefristeten Vertrag, und wie geschrieben recht gute Konditionen. Magst/Kannst/Darfst du das etwas quantifizieren?
Nicht präziser als ich weiter oben angedeutet habe, der Rest lässt sich über die TVÖD Tabellen (Bund) rausfinden. Klar, nicht vergleichbar mit dem was man in der Industrie bekommen kann, aber für Ostdeutschland sehr gut und um nächstes Jahr den hausbau zu starten, reichts dicke aus.
Hallo Christian, was für eine EG bekommt ein FHler bei euch gewöhnlich.
Kommt drauf an, was er macht und wie sehr sich der Abteilungsleiter beim Chef für ihn einsetzt. FH geht aber prinzipiell erst mal von 10 bis 12. Und dann kanns da noch Forschungszulagen oben drauf geben. Mit einer 12 + Zulage kann man schon ganz ordentlich leben. Wenn man wirklich wissenschaftlich tätig ist, Projektanträge schreibt oder so, dann geht auch die 13 bei FH-lern, das ist nicht so starr wie manche immer denken.
> Autor: Pesto (Gast) > Cihan Kalayci schrieb: > von Jürgen Reichardt und Bernd Schwarz > Das Buch wird immer wieder genannt und ich weiss nicht warum. > Der Erkläranteil ist für einen Anfänger viel zu gering und für einen > Fortgeschrittenen zu viel. Da muss was anderes bei. Ausserdem wird dort > zu sehr auf die Sprache abgehoben. Was aber gebraucht wird, sind die > Schaltungstechniken, also die Funktionen, nicht nur deren Umsetzung. Das schätze ich genauso ein. Das Buch isz ganz nett und hilft erst mal weiter, aber das Gelbe vom Ei ist es auch nicht. Ich kann folgendes Buch wärmstens empfehlen: Andrew Rushton "VHDL for logic synthesis", Wiley http://www.amazon.com/gp/reader/0470688475/ref=sib_dp_pt#reader-link Der Autor beschränkt sich auf die Synthese und verschont den HW-Entwickler, der auf VHDL umsteigt, mit dem ganzen Testbench-Gerassel und den Simulationskonstrukten, die beim Lernprozess nur stören. Hier ist jede Klammer und jedes Semikolon erklärt und nicht in den Rang des Geheimwissens erhoben. Durch dieses Buch wurden mir schlagartig viele Fehlermeldungen des Parsers klar. Das Buch ist flüssig und verständlich geschrieben, was für mich als Nicht-Englisch-sprechenden absolut wichtig ist. Der Autor lässt nicht die ansonsten übliche "Guckt mal, was ich noch alles weiß"-Masche heraushängen, sondern erklärt das Problem verständlich und sachorientiert. Angenehm fällt auf, dass VHDL aus sich selbst heraus erklärt und nicht ständig mit irgendwelchen C-Auswüchsen verglichen wird. Voraussetzung: Der Leser kennt sich in der HW bereit gut aus und fängt dort nicht beim Urschleim an. Der Mann weiß, wovon er schreibt. Diesen Eindruck vermisse ich bei unseren Herren Professoren.
>und verschont den HW-Entwickler, der auf VHDL umsteigt, mit dem ganzen >Testbench-Gerassel und den Simulationskonstrukten, die beim Lernprozess nur >stören. Ahh, ein Befürworter der Scharfes-Hinsehen-Methode. So ein Buch würde in nicht einmal in meine verstaubte Schublade legen. >Der Mann weiß, wovon er schreibt jep, ganz offenbar ;-)
Die Testbenches sind selbstredend im Buch beschrieben, aber dort, wo sie hingehören - an das Ende, nachdem die Synthese beschriebeb wurde. Andere Autoren bevorzugen den Nudeltopfstil, wo bei der Synthese ständig entnervende und chaotisch auftauchende Simulationsbeispiele nebenher auftauchen. Das ist eben nicht jedermanns Geschmack. Ich bevorzuge in diesem Fall eine klare Strukturierung.
Bürovorsteher schrieb: > Die Testbenches sind selbstredend im Buch beschrieben, aber dort, wo sie > hingehören - an das Ende, nachdem die Synthese beschriebeb wurde. Ich glaube da liegt ein Verständnisproblem vor: Die Testbenches sind vom Namen her zwar ein Test, also ein Mittel zum Prüfen einer realen Baugruppe bzw eines jkonkreten, gefertigen Exemplars, sie werden im Umfeld der C und HDL-Entwicklung aber während der Entwicklung der Schaltungsbescheibung genutzt. Eine Testbench in VHDL ist also zum Simulieren da und nicht zum Fertingsendtest. Sie kommt als logisch gesehen VOR der Synthese. Z.B. prüfen VHDL-Entwickler, die nur entwicklen ihre Schaltung mit der Testbench und übergeben den Code dann an den Empfänger. Der kann - muss aber nicht - in der selben Anteilung sitzt. Er kann bei zugeliefertem Code auch in einer anderen Firma sitzen. Syntheschecks und deren Simulation sind wieder etwas anderes.
Robert Kuhn schrieb: > Z.B. prüfen VHDL-Entwickler, die nur entwicklen ihre Schaltung mit der > Testbench und übergeben den Code dann an den Empfänger. Der kann - muss > aber nicht - in der selben Anteilung sitzt. Er kann bei zugeliefertem > Code auch in einer anderen Firma sitzen. Kurz: die Testbench ist das Pflichtenheft des VHDL-Entwicklers. Gegen eine vom Kunden gestellte Testbench muss das entwickelte Design ohne Fehler laufen.
Lothar Miller schrieb: > Kurz: die Testbench ist das Pflichtenheft des VHDL-Entwicklers. Abstrakt gesehen, ja. Ändert aber nichts daran, dass a) dieses "PH" de fakto im Bereich der Entwicklung wirkt und nicht im Test (mein erster Einwand) und damit streng genommen nicht "Test"-bench heissen sollte, b) die TBs praktisch zum Simulieren gehören, das aus der sicht der Entwicklungssequenz vor der Synthese erfolgt. Von daher ist es nicht einleuchtend, dass ein Buch dass a) die TB von der Entwicklung getrennt aufführt, b) diese nach der Synthese bringt. Meines Erachtens sollten Bücher aus didaktischer Sicht so weit als möglich dem design flow folgen.
Bürovorsteher schrieb: > Der Autor beschränkt sich auf die Synthese und verschont den > HW-Entwickler, der auf VHDL umsteigt, mit dem ganzen Testbench-Gerassel > und den Simulationskonstrukten, die beim Lernprozess nur stören. Zustimmung! Mit VHDL wird Hardware beschrieben, das muß beim Lernen im Vordergrund stehen. Also das Beschreiben von synthesefähigen Code. Läuft das durch die Synthese kann man (als Anfänger) mit der TB weitermachen. So würde auch vermieden, das Anfänger mit artfremdem Konstrukten versuchen Signalwechsel zu beschreiben ('event). Das lernen sollte in der Abstraktion nach oben gehen, also Erste Hardware lernen (AND, MUX, FF, FSM, etc) dann synthese-fähige Hardwarebeschreibung, dann abstrakte Modellierung und auf testtiefe optimierte Simulationen. Gerade ein Praktiker macht es sich leichter sein FPGA-Design auf die Gewohnte Weise (Testboard, Interne Signale auf dbg-pins, Scope, LED's, (Chip-Scope)) zu debuggen. Wohlgemerkt, das ist eine Vorgehensweise fürs learning by doing; im Entwicklungsalltag mit anderen Fokus (ISO9000, Zuverlässigkeit, ASSIC-Entwurf) sieht das natürlich anders aus. Aber auch da trennt man gern zwischen VHDL-Hardware Schreiber (Designer) und VHDL-Simu Schreiber (Verifikant). Das nennt man zwei paar Augen Prinzip. MfG ,
Ermel Hoch schrieb: > Aber auch da trennt man > gern zwischen VHDL-Hardware Schreiber (Designer) und VHDL-Simu Schreiber > (Verifikant). Das nennt man zwei paar Augen Prinzip. Einverstanden, wobei zumindest ein Teil der HDL, die formelle Verifikation darstellt, zuerst da sein muss, da ohne sonsts keine VHDL vom "Hardware-Schreiber" läüft.
Bürovorsteher schrieb: > Es ist absolut sinnlos, in diesem Forum etwas zu schreiben. Sinnlos vielleicht nicht, aber manchmal schwierig. Ich kann Dir z.T. recht geben, weil VHDL wirklich anfangs eine verwirrende Sache ist, da kann ich aus eigener Erfahrung bestätigten. Nachdem ich mein erstes Buch über VHDL gelesen hatte, habe ich mich gefragt was das alles mit HW zu tun hat. Der Ansatz nur über die Synthese ist meiner Meinung nach deshalb problematisch, weil VHDL eine Simulationssprache ist. Wenn man das nicht von vorne herein versteht, dann tauchen so Fragen auf, wie: "Wo läuft denn nun mein Prozess im FPGA und wieviele Prozesse kann ich maximal laufen lassen?" Nur wenn man VHDL als Simulationsbeschreibung versteht, dann hat man VHDL verstanden und dann hat man das Konzept der Testbench eh schon akzeptiert.
Robert Kuhn schrieb: > Einverstanden, wobei zumindest ein Teil der HDL, die formelle > Verifikation darstellt, zuerst da sein muss, da ohne sonsts keine VHDL > vom "Hardware-Schreiber" läüft Du meinst wohl formAle Verifikation nicht formElle. Gemeint ist mit formaller verifikation die Überprüfung der Spezifikation auf prinzipielle Funktionsfähigigkeit (z.B. "lebendig FSMs (z.B. erreichbarer Anfangszustand). Das ist weniger eine Aufgabe für den VHDL-Entwickler als für den Systemarchitekt o.ä. . MfG,
Ich bestreite in keinster Weise die Notwendigkeit der Simulation und der Verifikation. Ich bestreite ebenfalls nicht, dass VHDL in erster Linie eine Simulationssparache war oder ist, was mir auch völlig Wurst ist. > "Wo läuft denn nun mein Prozess im FPGA und wieviele Prozesse kann ich > maximal laufen lassen?" Diese Frage stand nach 30 Jahren HW-Entwicklung für mich auch nie. Für mich bestand das Problem darin, meine Schaltung bzw. Funktionalität in VHDL dergestalt niederzuschreiben, dass der Parser halbwegs unfallfrei durchläuft und nicht in jeder Zeile zwei oder mehr Fehler stecken. Dazu muss ich die Eigenschaften der Sprachelemente kennen und ein Grundverständnis der Sprache als Synthesemittel habe. Im didaktischen Prozess hat die Verifikation/Simulation erst einmal eine nachrangige Bedeutung, da ich diesen Prozess nicht sofort komplett in VHDL verstehen muss, weil ich hier die Simulationswerkzeuge des FPGA-Herstellers nutzen kann. Wenn ich ein Auto fahre, muss ich nicht unbedingt wissen, wie die Motorelektronik funktioniert und ob deren Software in C oder im Assembler geschrieben ist. Jedenfalls ist es zumindest für mich als VHDL-Autodidaktiker einfacher, in der Verständnisphase auf den randständigen Ballast zu verzichten und die korrekte Sprachbenutzung zu erlernen. Ohne daass es eine Entschuldigung sein soll - mit fast 60 Jahren ist man nicht mehr der geistige Überflieger der längst vergangenen Studienzeit. Wenn ich die Verfikation vollständig erlernen will, muss ich eben dass nächste Buch kaufen, na und? Als ich in der Schule dass ABC gelernt habe, musste ich nebenher auch nicht den "Faust" lesen. Bitte jetzt nicht den technologischen/ingenieurbürokratischen mit dem didaktischen Prozess verwechseln. Es tut mir aufrichtig leid, dass ich meinen DiplIng im Jahre 1977 gemacht habe und nicht komplett mit den geistigen Höhenflügen einiger jüngerer Forennutzer mithalten kann. Für mich ist das Buch genau richtig, weil es mich mit meiner geistigen Unbeweglichkeit und Ignoranz dennoch befähigt, unfallfrei Schaltungsbeschreibungen zu erzeugen, die am Ende auch tatsächlich so funktioniern, wie gewünscht.
>Für mich ist das Buch genau richtig, weil es mich mit meiner geistigen >Unbeweglichkeit und Ignoranz dennoch befähigt, unfallfrei >Schaltungsbeschreibungen zu erzeugen, die am Ende auch tatsächlich so >funktioniern, wie gewünscht. OK, einverstanden. Dennoch macht eine Testbench sehr viel Sinn, um eine Änderung am HW-Modul-Code zu überprüfen, ohne jedesmal ein iteratives Vorgehen bestehend aus "Bitfile generieren" + "In Hardware überprüfen" zu durchlaufen.
>dass ich meinen DiplIng im Jahre 1977
Da war ich noch ein Jahr flüssig ;-)
> ennoch macht eine Testbench sehr viel Sinn, um eine > Änderung am HW-Modul-Code zu überprüfen, ohne jedesmal ein iteratives > Vorgehen bestehend aus "Bitfile generieren" + "In Hardware überprüfen" > zu durchlaufen. Ich benutze vorzugsweise den Aldec-Simulator aus Lattice Diamond, das geht genauso fix bzw. noch schneller wie eine TB selbst zu schreiben, weshalb sollte ich mir das mit den Bitfiles antun oder es jedesmal an der Hardware überprüfen? Wenn man das Tutorial aufmerksam liest, bekommt man den Simulator schlussendlich sogar zum Laufen. Es ist Aufgabe des Ingenieurs, die vorhandenen und teils sogar kostenlosen Ressourcen effektiv zu nutzen.
DuArte schrieb: > Dennoch macht eine Testbench sehr viel Sinn, um eine > Änderung am HW-Modul-Code zu überprüfen, ohne jedesmal ein iteratives > Vorgehen bestehend aus "Bitfile generieren" + "In Hardware überprüfen" > zu durchlaufen. Das ist eine Frage des Aufwandes. Bei einem SOC-Design, bei dem ein Softcore erst booten muß, bevor der FPGA seinen eigentlichen zweck erfüllt, ist ein in Echt schneller als eine Simulation des Softcore und die Nachmodellierung der Peripherie. Mal abgesehen von fehlern in der Simu resp Bibliotheken. Ganz abgesehen von debuggen von timing-problemen. Simu ist kein Allheilmittel, MfG,
Ermel Hoch schrieb: > Bei einem SOC-Design Bei einer Software, die im FPGA läuft simulierst du i.d.R. ja auch im Softwareentwicklungs-Kit und nicht im VHDL-Simulator :-)
R. schrieb: > Ermel Hoch schrieb: >> Bei einem SOC-Design > > Bei einer Software, die im FPGA läuft simulierst du i.d.R. ja auch im > Softwareentwicklungs-Kit und nicht im VHDL-Simulator :-) Was den Aufwand (Kauf oder Erstellung zum Core passenden Kit, Einarbeitung+Lernkurve) gegenüber einem Reallife Test noch weiter erhöht. Und bei einer HW/SW Co-Simulation kommt man um einen Simulator nicht umhin, SoC meint ja nicht den uC-Core allein sondern beinhalten auch Custom-VHDL. Den großen Vorteil beim FPGA-prototyping schnell in Echt testen zu können muß man nutzen wo möglich und sinnvoll. Simu hat den Vorteil der besseren Beobachtbarkeit interner Signale und der Forcierung kritischer Testfälle (tiefe sequentielle Zustandsübergänge, bspw Überlauf breiter Zähler) durch Zustandsinjektion. Eint Entweder oder denken ist weder angebracht noch notwendig. MfG,
Ermel Hoch schrieb: > Den großen Vorteil beim FPGA-prototyping schnell in Echt testen zu > können muß man nutzen wo möglich und sinnvoll. schnell in echt verflüchtigt sich recht zügig wenn die Synthese mehrere Stunden oder nen Tag braucht.
D. I. schrieb: > Ermel Hoch schrieb: >> Den großen Vorteil beim FPGA-prototyping schnell in Echt testen zu >> können muß man nutzen wo möglich und sinnvoll. > > schnell in echt verflüchtigt sich recht zügig wenn die Synthese mehrere > Stunden oder nen Tag braucht. Jepp, hier bei mir: Dienstleister liefert den FPGA, natuerlich keine Simulation. Inbetriebnahme, es geht nix, im Gegenteil, es wird 'warm'. Also dann rumpfuschen, neu synthetisieren, flashen, probieren. Wieder nix, und auf ein Neues... 'Ne Simulation sollte dann doch eine 'gescheite' Simulation sein. Und gar keine Simulation heisst fuer mich: Funktioniert nicht! Basta!
D. I. schrieb: > Ermel Hoch schrieb: >> Den großen Vorteil beim FPGA-prototyping schnell in Echt testen zu >> können muß man nutzen wo möglich und sinnvoll. > > schnell in echt verflüchtigt sich recht zügig wenn die Synthese mehrere > Stunden oder nen Tag braucht. Hier im Thread geht es um Anfängerdesigns, da ist in höchstens 5 Minuten der Frosch rasiert! Und auch bei Industrie-designs sind bei heutiger Rechenzeit Synthese/P+R Laufzeiten länger als 60 minuten die Ausnahme. Und da man modular entwickelt lässt man die nicht benötigten Module weg resp. ersetzt sie mit dummies. Clever optimiertes Placing das Extraoptimierungsstufen überflüssig macht hilft auch. Ggf reduziert man den Takt. Dagegen wird man für einen Regressionstest mit hoher Testtiefe alle Rechenzeit aufwenden die man kriegen kann und es werden immer Fehler durchschlüfen, die man in Echt besser nachweisen kann. MfG,
berndl schrieb: > D. I. schrieb: >> Ermel Hoch schrieb: >>> Den großen Vorteil beim FPGA-prototyping schnell in Echt testen zu >>> können muß man nutzen wo möglich und sinnvoll. >> >> schnell in echt verflüchtigt sich recht zügig wenn die Synthese mehrere >> Stunden oder nen Tag braucht. > Jepp, hier bei mir: Dienstleister liefert den FPGA, natuerlich keine > Simulation. Wieso "natürlich keine", habt ihr aus Kostengründen nicht mitbestellt? Aus Dummheit die Inbetriebnahme selbst übernohmen, den Kunden das Produkt selbst abnehmen lassen???!! > Inbetriebnahme, es geht nix, im Gegenteil, es wird 'warm'. ?wenn der FPGA warm bedeudet doch das er arbeitet, bleibt er kalt war es ein Schuß in den Ofen, oder die Reset-Polarity stimmt nicht. Die Basics der Inbetriebnahme scheinen dir nicht geläufig. > Also dann rumpfuschen, neu synthetisieren, flashen, probieren. Wieder > nix, und auf ein Neues... Systematische Fehlersuche bspw mit Chipscope oder Testmultiplexor scheint dir auch unbekannt. > 'Ne Simulation sollte dann doch eine 'gescheite' Simulation sein. Und > gar keine Simulation heisst fuer mich: Funktioniert nicht! Basta! Nunja, ein Profi der die Spec selbst geschrieben hat oder zumindest versteht, sollte sich an einem Arbeitstag eine Testbench zusammengehämmern können (Takt als stimuli, registersettings per force signal und ein paar asserts die auf ein toggle lauern an alle Ausgänge . Und vorher dem Dienstleister klar gemacht haben, das das Honorar erst nach Abnahme überwiesen wird. "Basta schreien" ist nur eine andere Schreibweise für Lautstarkes Kapitulieren. MfG,
Fritz Jaeger schrieb: > ...registersettings per force signal... Finde ich persönlich eher heikel und sollte in der Regel nicht verwendet werden. Viel besser, den gewünschten Zustand aus dem Initialzustand (nach Config-Load bei FPGA, nach Reset bei ASIC) durch Stimulation der Eingangssignale zu erreichen. Man stellt damit sicher, dass der gewünschte Zustand in der Realität auch erreicht werden kann, was bei "force"-Aktionen nicht zwingend der Fall sein muss.
Peter K. schrieb: > Fritz Jaeger schrieb: >> ...registersettings per force signal... > > Finde ich persönlich eher heikel und sollte in der Regel nicht verwendet > werden. Viel besser, den gewünschten Zustand aus dem Initialzustand > (nach Config-Load bei FPGA, nach Reset bei ASIC) durch Stimulation der > Eingangssignale zu erreichen. Man stellt damit sicher, dass der > gewünschte Zustand in der Realität auch erreicht werden kann, was bei > "force"-Aktionen nicht zwingend der Fall sein muss. Ja das ist heikel, aber für AdHoc StepbyStep Analyse und schnelles Kennenlernen/Nutzen des Simulators geeignet. Muss man nicht für jeden Schritt die Testbench erweitern neucompiliern und and die kritische Stell ransimulieren. Und es ist für die Entwicklung einzelner SOC-Module von Vorteil, da man nicht die gesamte Controllogik mit simulieren resp modellieren muß. Für den konkreten Fall (Inbetriebnahme bei fhelnder Gesamtsimulation) passend, für einen Regressionstest der die Software mit-emuliert (treiber, der den FPGA per Register schreiben/lesen steuert) eher nicht. force signal lässt sich auch bequem im tcl script nutzen, da kann man schneller komplexe pattern und Checks auf referenz-werte ausführen als in VHDL mit Text-IO und report. Auch bei der Analyse von langwierigen PowerUpsequenzen (verschiedenen Spannungsregler einschalten und dazwischen 10 msec warten, dann externen VCO zuschalten, Einschwingzeit abwarten ...) geeignet um Simuzeit zu sparen. Bei den I/O pins sehe ich keine signifikanten Unterschiede im Vergleich zu VHDL-Stimulifile. Und es ist nicht so, das man in echt keine internen FPGA-Signale setzen kann, dazu hats den Chipscope-VIO. MfG,
Dennis R. schrieb: > Nun würde ich gerne "richtig" VHDL lernen, um auch anspruchsvollere > Aufgaben umsetzen zu können. Die Frage lautet nun: Wie lerne ich das am > besten? Habt ihr das mit Büchern(welche?), Online-Tutoriale(URL?), > Kurse(bei wem und wo?) gelernt oder hattet ihr jemandem der euch das > beigebracht hat? Online-Tutorials gab es zu meiner Lehrzeit noch nicht, jetz aber, eine kleine Auswahl findest Du im wiki: http://www.mikrocontroller.net/articles/Lehrvideos Meine persönlichen Buchempfehlungen: 0-13-082599-9 und 0-9651934-3-8 auch brauchbar ist: 0-7695-0023-4 MfG,
>Nunja, ein Profi der die Spec selbst geschrieben hat oder zumindest >versteht, sollte sich an einem Arbeitstag eine Testbench >zusammengehämmern können Ich mache irgendetwas falsch ...
Die Testbencherei kann mitunter recht aufwändig werden, wenn man Prozessorinterfaces testen will und Busse hat. Meistens muss noch irgend ein damischer Chip angetrigger werden, wobei die schönen Testbenches erst laufen, wenn der Chip anwirtet. Jetzt bringe mal einen VHDL chip Modell das richtige Antworten bei, wenn er verschieden Betriebszustände hat. Beispiel DDS-Chip, Transceiver, Controller,
B.B. schrieb: > Jetzt bringe mal einen VHDL chip > Modell das richtige Antworten bei, wenn er verschieden Betriebszustände > hat. > > Beispiel DDS-Chip, Transceiver, Controller, Nicht selten gibt es dafür schon VHDL-Modelle die man beziehen kann (z.B. DDR3-Speichermodelle), manchmal vom Hersteller, manchmal von einem Drittanbieter und bei weder noch hast du schon ne Marktlücke...
Naja, die Speicher sind weniger das thema. Einmal Zugriff, immer Zugriff. Marktlücke? Nun ja, ich baue mir natürlich die Modelle und der Kunde bekomt sie und bezahlt sie indirekt, aber bisher habe ich keinen zweiten Chip / dessen Reaktion zweimal gebraucht :-(
B.B. schrieb: > Die Testbencherei kann mitunter recht aufwändig werden, wenn man > Prozessorinterfaces testen will und Busse hat. Meistens muss noch irgend > ein damischer Chip angetrigger werden, wobei die schönen Testbenches > erst laufen, wenn der Chip anwirtet. Jetzt bringe mal einen VHDL chip > Modell das richtige Antworten bei, wenn er verschieden Betriebszustände > hat. > > Beispiel DDS-Chip, Transceiver, Controller, Ja für komplexe Modelle ist VHDL, obwohl auch dafür ursprünglich entwickelt nicht sonderlich gut geeignet. Als Nachfolger setzen die großen e und Specman ein, Oder systen C, oder plain C-referenzmodell ... Gerade im Hobbybereich mit den fliegenden Aufbauten ist ein Verhalten schneller nachgemessen als modelliert/simuliert. Oder man kürzt eine Simulation bis zum Erreichen des gewünschten Betriebszustände ab, in dem per signal -force den erforderlichen Zustand herbeizwingt. Deshalb sollte man als Einsteiger Simulation und VHDL-Verständniss nicht zum Selbstzweck betreiben. Wichtig ist die richtige Mischung und kurze Abfolge aus Selbsttudium und Erfolgserlebnis. Danach wird man zum Vollprofi durch Erstellen paramtrisierbarer Regressionstests mit voller funktionaller Testtiefe, die alle Testpattern aus dem Pflichtenheft abarbeiten können.
Nur weil's grad so schön passt, morgen findet ein Webinar zum Thema statt: "Advanced VHDL Verification - OS-VVM and more..." http://www.doulos.com/content/events/adv_vhdl_verification.php Gruß Marcus
Hallo, ich bin auch gerade dabei VHDL zu lernen. Ich habe zwei Bücher gefunden, kann mich aber nicht entscheiden. Wo ist da eigentlich der Unterschied? http://www.amazon.de/Lehrbuch-Digitaltechnik-Eine-Einf%C3%BChrung-VHDL/dp/3486706802/ref=sr_1_1?ie=UTF8&qid=1355082453&sr=8-1 und http://www.amazon.de/VHDL-Synthese-Entwurf-digitaler-Schaltungen-Systeme/dp/3486589873/ref=sr_1_3?ie=UTF8&qid=1355082453&sr=8-3 Gruß Felix
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.