Also ich bin derweilen an einem kleinen Ordnungsproblem bei meinen Entwicklungen gestoßen. Gibt es ein sinnvolle Hierarchie in der Filesytemstruktur? -vhdl_code -primitive -lib -sim_work -fit_work Und dann noch eine git und Subversion zur Versionsverwaltung. Wenn man die ganzen Tools auf den VHDL code loslässt, dann erzeugen diese auch noch weiter Dateien und das Verzeichnis wird ganz schnell zugemüllt. Ich copiere z.B. zu Simulieren Files extra um, weil ich gar kein Löschen durchführen kann, ohne was von einem anderen Tool mit zu lösen. Alles nicht ideal. Kann hier jemand eine Struktur empfehlen? Es kann auch von einem Standardtool sein, mit dem ich noch nie gearbeit habe. Ich frage mich manchmal wie würde es bei Mentor oder Synopsys aussehen. Hatte leider noch nicht das Vergnügen. Das zweite Problem ist die Benamung innerhalb des VHDL-Codes z.B von Signalen. In C hat sich die hungrian Natation durchgesetzt. Gibt es so etwas ähnliches auch in VHDL Sprachraum? z.B. Negative Signale werden im eine Querstrich im Schaltplan gekennzeichnet. Entsprechend in Englischen heisst der Strich bar. so habe ich z.B. rst_b eine negative Reset-Leitung genannt. So richtig gefiel mir das auch nicht mehr, dass ich jetzt bei rst_n bin. Hat hier jemand Erfahrung, oder gar ein QM-Handbuch, um den Text auf Dauer lesbarer zugestalten? Bin gespannt auf eure Antworten, wie haltet Ihr auf euren Rechner Ordung?
Gast
#1561849
Hallo,
bei mir schaut die Struktur immer so aus:
projektX | hier liegen die ganzen ISE/Quartus Dateien drin
+ SRC (VHDL sourcen für den FPGA)
+ SIM (simulationsordner)
+ TB (testbench files)
+ FUNC (ordner für funktionelle simulation)
+ TIME (ordner für timingsimulation)
zur Namenskonvention:
Inputs: iClk1 (i vorne)
Outputs: oOutx (o vorne)
IOs: ioBusA (io vorne)
Signale: sSignal (s vorne)
Variablen: vTemp1 (v vorne)
negierte Logik: iResetn (n hinten)
Sg,
Wolfgang
> In C hat sich die hungrian Natation durchgesetzt. Gibt es so etwas > ähnliches auch in VHDL Sprachraum? In C werden meist eine sehr überschaubare Anzahl fester Datentypen mit definierten Datenbreiten (8,16,32 Bit) eingesetzt. Daher macht dort ein Variablenname wie u8Counter Sinn. In VHDL definiere ich mir jede Menge neuer Datentypen und Subtypen (Zustände, Vektoren, Speicher) und müsste da dann diese Information auch mit in den Namen aufnehmen.
1 | |
2 | |
3 | |
Und insbesondere bei Zuständen von FSM wird das dann komplett undurchschaubar:
1 | |
2 | |
Denn eigentlich müsste jetzt im Signalnamen Zustand ja irgendwie der Typ state_t auftauchen (analog zu 'C': u8Zustand, hier ist der Datentyp ein unsigned int 8 Bit breit). Und allein, um zu unterscheiden, ob es ein Signal oder eine Variable ist, da wäre mir der Speicherplatz auf der Platte zu schade und die Tipparbeit zu viel. Da vertraue ich auf den Syntax-Check, der mir bei falscher Verwendung auf die Finger klopfen wird. Der Knackpunkt und der große Vorteil bei VHDL ist, dass jedes Signal seinen Typ immer mit dabei hat, und ich mit Attributen ('base, 'left, 'right, 'range...) darauf zugreifen kann. Daher kann ich an jeder Stelle im Code einfach den Wertebereich feststellen:
1 | |
2 | |
3 | |
René D. schrieb: > In C hat sich die hungrian Natation durchgesetzt. Gibt es so etwas > ähnliches auch in VHDL Sprachraum? Zum Glück hat sich dieser Mist nicht durchgesetzt. Höchstens bei über 40-jährigen Programmierern, die noch nie sowas wie IntelliSense gesehen haben. Lass das mal gleich sein, vor allem bei VHDL wirds dann noch grausamer als in C. Wie Lothar schon schrieb.
Gast
#1561942
Einige opencores-Projekte liefern da auch Anhaltspunkte. Meine übliche Struktur sieht so aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
Je nach Bedarf gibt es weitere Unterverzeichnisse für C-Quellcode oder Generatorskripte. Die jeweiligen Programme (Simulator, Synthesizer, etc.) werden per makefile gestartet. Duke
Ich habe mir irgendwann mal die Notation nach https://eecms.ee.ethz.ch/?id=1608 angewoehnt und bin damit ganz zufrieden. Das hat auch den Vorteil, dass der Emacs vhdl-mode da direkt drauf triggert. Aber eigentlich ist es egal wie man es macht, solange man eine kurze zusammenfassung in den Header packt, damit sich andere Leute da auch schnell zurecht finden. Zum Aufbau: projectroot: +.git ;) + rtl + sim + tb + doc + temp (fuer die ganzen Programme die einen immer so zumuellen, ISE ist da Weltklasse drinnen) Bei der Simulation arbeite ich viel mit .do Dateien und wenn es dann an die Synthese geht kommen ein paar Precision Skripte zum Einsatz, aber die sind alle sehr simpel gehalten und machen eigentlich nur ein paar Programmaufrufe
Gast
#1562315
Namenskonventionen; Meiner Erfahrung *_n für low aktive Signale *_q für FF und andere getaktete Ausgänge (für STA) *_clk für Taktnetzwerke *_rst für asynchrone Resets *_i für Ports vom Typ IN *_o für Ports vom Typ OUT *_io für Ports vom Typ INOUT c_* für constanten v_* für variablen t_* für typen _arch für die architecture von tb_* für die testbench von * *_pkg für packages Das erspart die meisten verdrahtungsfehler (z.B. lesen vom outport, <= für variablen) und die Hardwarestruktur (Taktnetzwerke, kombinatorik (LUT), Speicherelemente (FF)) ist gut erkennbar. MfG
Gast
#1563247
> Ich habe mir irgendwann mal die Notation nach > https://eecms.ee.ethz.ch/?id=1608 Oje, wieder diese lästige Gross/kleinschreibung. Kann ich schon in C nicht ausstehen ;) Kann auch sicherlich zu netten Verwirrungen führen, weil VHDL nicht case-sensitive ist, das Auge aber schon... > Das erspart die meisten verdrahtungsfehler (z.B. lesen vom outport, > <= für variablen) Dafür habe ich doch den Compiler... Ich glaube auch nicht, dass man sich damit wirklich Zeit spart, wenn man VHDL halbwegs kann. Solche Syntax-Bugs entstehen bei mir entweder durch vertippt oder geistig abwesend. Dagegen hilft eine Konvention auch nicht. Und gegen die richtigen Bugs, die einem beim Debugging die viele Zeit kosten, auch nicht. Die "fremden" Codes, die ich bisher so gesehen habe und die sich sklavisch an eine Notation gehalten haben (zB. das Zeug aus dem Xilinx-EDK) waren oft absolut unleserlich, sinnlos tot-dokumentiert, tot-modularisiert (wo steckt hier eigentlich die Funktion...) und häufig trotzdem/gerade deswegen(???) fehlerhaft.
> *_i für Ports vom Typ IN > *_o für Ports vom Typ OUT > *_io für Ports vom Typ INOUT Für die stinknormalen Signale finde ich das überflüssig. Eine *_n für negative Signale hat sich bewährt. Das negative denken liegt mir nicht so, deshalb verwende ich immer nur Positive Signale. Alle negativen Ein- und Ausgänge werden am Anfang eines Moduls in positive Signale gewandelt (z.B. rst <= n_rst). Ebenso Takte diese immer clk (bei mehreren clk_*) zu verwenden. Bei Reset rst. Ebenso schreibe ich alles Klein. Nur Konstanten werden komplett in Großbuchstaben geschrieben. Das macht den Code nach langer Zeit schnell leserlicher. Vor allem wenn Konstanten in globalen Bibliotheken deklariert werden.
Gast
#1563456
Matthias G. schrieb: >> *_i für Ports vom Typ IN >> *_o für Ports vom Typ OUT >> *_io für Ports vom Typ INOUT > > Für die stinknormalen Signale finde ich das überflüssig. Eine *_n für > negative Signale hat sich bewährt. Das negative denken liegt mir nicht > so, deshalb verwende ich immer nur Positive Signale. > Alle negativen Ein- > und Ausgänge werden am Anfang eines Moduls in positive Signale gewandelt > (z.B. rst <= n_rst). Fehlt hier die negation? BTW, für Code der mich nicht verlässt, verwende ich keine positiven oder negativel Pegel, sondern den Typ boolean. Ist natursprachlich, leichter lesbar und FPGA intern ist es wurscht ob nun '1' oder '0' eine Aktion auslöst. >Ebenso Takte diese immer clk (bei mehreren clk_*) > zu verwenden. Nach schlechten Erfahrungen (übersehene Taktübergänge) lehne ich einen einzigen Namen für unterschiedliche Takte ab. Wie gesagt die Grundstruktur der Hardware wie versch Taktdomainen sollte sichtbar sein, System_clk, sample_clk, oder auch wenn das bei Reuse wiederumbenannt werden muss 48MHz_clk, 250MHz_clk. Grad bei Projekten mit mehreren Entwicklern, kann nicht jeder die Spec für jedes einzelne Signal kennen. Da sollte man mehr Info in die Signalnamen packen ohne Bandwurmidentifier zu schaffen. MfG
Ja die globalen Sachen, wie die Clocks mussen klar definiert sein und sauber in alle Schichten weitergereicht werden. Da erinnert mich an eine Entwicklung mit einem 2D Koordinatensystem. Da war der Ursprung nicht klar definiert. Jede Ebene hatte ein Offset benutzt und in einer anderen das Koordinaten System gar gespiegelt, damit hatte eine Achse ein anderes Vorzeichen. Jeder Programmierer benutzte ein anderes Koordinatensystem mit einem anderen Ursprung und es war doch das gleiche. Die Kurzanhänge sind auch nicht schlecht. Da muss ich mir mal eine List überlegen. Gerade bei State machine Definitionen baut man einen Typ und danach das entsprechende Signal mit dem State machine type. Die Porttypen sind meistens überschaubar und es ist auch das Erste was man sich anschaut. Probleme sind eher Signale, die als Zwischenspeicher dienen, um das Signal einen Takt zu verzögern. Oder asynchrone Ereignisse.
René D. schrieb: > Probleme sind eher Signale, die als Zwischenspeicher dienen, um das > Signal einen Takt zu verzögern. Da schreib ich immer Signal_d (1x Signal verzögert), Signal_d1 (2 mal verzögert) usw. viel mehr als 2...3 Registerstufen hat man ja selten.
Und was für einen Buchstaben, wenn es eher ist als das eigentliche Signal? _pre z.B. write_enable wird einen Takt später freigeben, um alles Zustände stabil zu haben.
Dem Anwender sind doch da völlig frei, es sollte nur durchgängig sein.
Ich habe gerade eine Idee: die Zahl davor ist das Signal vor dem Ereignis wie d1_wr_en und eine Zahl dahinter ist das verzögerte Signal data_d1
Frei nach dem Motto: Nach dem Takt ist vor dem Takt... ;-)
Gast
#1565040
Lothar Miller schrieb:
> Frei nach dem Motto: Nach dem Takt ist vor dem Takt... ;-)
:-))
>> (z.B. rst <= n_rst). > Fehlt hier die negation? Oh, tatsächlich, habe ich übersehen. > Nach schlechten Erfahrungen (übersehene Taktübergänge) lehne ich einen > einzigen Namen für unterschiedliche Takte ab. Wie gesagt die > Grundstruktur der Hardware wie versch Taktdomainen sollte sichtbar sein, > System_clk, sample_clk, oder auch wenn das bei Reuse wiederumbenannt > werden muss 48MHz_clk, 250MHz_clk. Grad bei Projekten mit mehreren > Entwicklern, kann nicht jeder die Spec für jedes einzelne Signal kennen. > Da sollte man mehr Info in die Signalnamen packen ohne > Bandwurmidentifier zu schaffen. Das ist für mich einleuchtend. Glücklich wer nur einen Takt benötigt. In Bereichen, in denen aber keine Verwechslungsgefahr besteht reicht mir aber ein clk ohne weitere Angaben. Grundsätzlich finde ich es aber geschickter die Zusätze hinten anzustellen. Das bringt eine bessere Lesbarkeit. So z.B. clk_50MHz clk_66MHz Ebenso versuche ich die Signalnamen Sinnvoll von hierarchisch von oben nach unten zu Gliedern. Man sieht dann sofort wo die Signale zugeordnet sind. Die Trennung erfolgt mit einem Unterstrich. Unterstriche finde ich persönlich besser lesbar als die Großbuchstabentrennung. Beispiel: adc_ch1_cs adc_ch1_clk adc_ch2_cs adc_ch2_clk ... Man muss nur aufpassen, dass das nicht in die Bandwurm_ewiglange_Signalnamen_Problematik verfällt.
Gast
#1570413
Matthias G. schrieb: > adc_ch1_cs > adc_ch1_clk > adc_ch2_cs > adc_ch2_clk ... > > Man muss nur aufpassen, dass das nicht in die > Bandwurm_ewiglange_Signalnamen_Problematik verfällt. Dafür wurden ja auch die records erfunden:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Der Aufwand rentiert sich schon bei der "Verdrahtung" von Modulen/entitys. Duke
records ist was Tolles in VHDL. Nutze ich auch viel zu wenig.
hmmm, Bisher habe ich records eher verwendet um zusammengehörige Datenpakete zu Bündeln (Datensätze). Z.B. Ein Messwert mit einem zugehörigen Status. Irgenwie sträubt sich bei mir was. Wenn ich obiges Beispiel hernehme und es entsteht dann sowas:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Wenn ich aber mehrere Kanäle habe könnte sich da der record schon lohnen.
So super kommt das nicht in diesem Beispiel rüber. Weil man clk und reset häufiger benötigt. In so einem record können z.B. drei Koordinaten x,y,z zusammengefasst werden. Oder Funktionen können auch records als Rückgabewert zurückliefern. Dann macht es richtig Spaß.
Gast
#1571080
Ich nehme immer das Prefix S_ für signale S_Counter <= "010101010";
Ich nehme immer das Postfix "<=" für Signale :-/ Counter <= "010101010";
Gast
#1571410
Leider gehen Records als Ports nur in eine Richtung. Und das gerade da, wo sie am hilfreichsten wären (Prozessorbusse, etc.). Ausser man macht inout draus, aber schön ist das auch nicht und beisst einen recht schnell wieder... Aber übersichtlich wirds auch trotz Aufsplitten von in&out. zB. mein DDR-Controller mit 5 internen R/W-Ports sieht für >400 Signale recht kurz aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
René D. schrieb: > In so einem record können z.B. drei Koordinaten x,y,z zusammengefasst > werden. Also ein Datensatz! Johann schrieb: > Ich nehme immer das Prefix S_ für signale s_* sind wunderbar für States geeignet. Folgende Präsentation ist ja nicht unbedingt schön, aber in Sachen Code-Styling sind gute Ansätze enthalten: http://klabs.org/richcontent/MAPLDCon02/presentations/session_p/p30_cohen_s.pdf
> Leider gehen Records als Ports nur in eine Richtung.
Nein, es geht eingentlich und an und für sich schon, du kannst sie z.B.
als inout deklarieren. Wichtig ist dann allerdings das Vorbelegen der
Ausgänge mit 'Z', sonst gibt es Konflikte bei der Simulation. Siehe dazu
den Anhang.
Gast
#1573092
> Nein, es geht eingentlich und an und für sich schon, du kannst sie z.B. > als inout deklarieren. Wichtig ist dann allerdings das Vorbelegen der > Ausgänge mit 'Z', sonst gibt es Konflikte bei der Simulation. Genau das meinte ich mit "nicht schön" ;) Ist halt dann doch kein reines "out". Und Zuweisungen auf einen Eingang "aus Versehen" merkt man dann auch erst bei der Simulation (wenn überhaupt) und nicht schon bei der Compilation.
Gast
#2167941
Matthias G. schrieb: > Folgende Präsentation ist ja nicht unbedingt schön, aber in Sachen > Code-Styling sind gute Ansätze enthalten: > http://klabs.org/richcontent/MAPLDCon02/presentati... Hallo zusammen, hab mir grad den Link von Matthias geschaut, das ist interresant. In dem Link wird verweist zu einen anderen Link http://schwick.home.cern.ch/schwick/vhdldoc/Welcome.html. Ich hab gern eine Frage: Hat jemand diese HTML-Documantationerzeugung unter Windows probiert? In online-manual beschreibt man wie es geht nur in Linux. Ich hab die Windows-Version und perl runtergeladen. Wie gehts es weiter, damit man Docus erzeugen lassen kann? Vielen Dank im voraus! lg nice gast
Gast
#2167996
René D. schrieb: > In C hat sich die hungrian Natation durchgesetzt. Das wage ich zu bezweifeln.
http://web.engr.oregonstate.edu/~traylor/ece474/lectures/opencores_coding_guidelines.pdf Da findest Du eine empfohlene Ordnerstruktur sowie übliche Signalnamenerweiterungen.
> Man muss nur aufpassen, dass das nicht in die > Bandwurm_ewiglange_Signalnamen_Problematik verfällt. Ich würde hier gerne mal anmerken, dass in der Sprache Java solche Bandwurmnamen verwendet werden und überhaupt kein Problem darstellen. Für "BandwurmEwiglangeSignalnamenProblematik" würde man in Eclipse b a ctrl+space tippen und dann den richtigen Namen aus der Dropdown-Box auswählen, sind ja i.A. nicht mehr viele. Das ist quasi die Weiterentwicklung der tab-Funktion der "bash" inkl. Dropdown, und zeigt nur Vorschläge an, die syntaktisch möglich sind und in der Reihenfolge der Sinnhaftigkeit anhand des Typsystems. Im Visual Studio heißt das Ding wie oben schonmal genannt IntelliSense und ist dem Tool aus Eclipse zwar unterlegen, aber immer noch sehr brauchbar. Es gibt erstmal keinen Grund, das bei VHDL nicht genauso zu machen, außer dass derart nützliche Tools wohl im HDL-Bereich nicht so bekannt sind wie im Java-Bereich. (Ansonsten könnte sich so ein Schrott wie ISE wohl auch kaum auf dem Markt halten)
Gast
#2168745
danke euch! habt ihr schon mal probiert mit HTML-docu Erzeugung? Das ist sicher interresant oder? lg, nice gast ps. danke Heinrich für interresante Link! Ist in opencores.org programmiert man nur mit verilog?
Gast
#2168786
Martin Geisse schrieb: > Es gibt erstmal keinen Grund, das bei VHDL nicht genauso zu machen, > außer dass derart nützliche Tools wohl im HDL-Bereich nicht so bekannt > sind wie im Java-Bereich. (Ansonsten könnte sich so ein Schrott wie ISE > wohl auch kaum auf dem Markt halten) SIGASI kann das und das möchte ich nicht mehr missen.
D. I. schrieb: > Martin Geisse schrieb: >> Es gibt erstmal keinen Grund, das bei VHDL nicht genauso zu machen, > > SIGASI kann das und das möchte ich nicht mehr missen. Und natürlich (X)Emacs. vi hat sicherlich auch ähnliches zu bieten. -- Marcus
Marcus Harnisch schrieb: > vi hat sicherlich auch ähnliches zu bieten. Ich meinte natürlich vim.
Mich freut, das dieser Thread mal wieder aufgekommen ist. Die kleinen Ideen waren sehr lehrreich. Ein zweiter sehr interessanter Thread war Beitrag "VHDL Debuging" >Link wird verweist zu einen anderen Link >http://schwick.home.cern.ch/schwick/vhdldoc/Welcome.html. Leider läuft mein perl skript nicht ansonsten sieht das Dokutool sehr interessant aus. Kennt jemand so ein Tool skript, das auch Latex Dateien erzeugt? Der Frage nach dem idealen Editor wurde auch in anderen Thread nicht gelöst. Der veditor hat auch eine interessante Funktion mit strg+Leertaste. Zamiacad ist leider kein plugin für eclipse geworden, sondern ein eigenständiges Programm. http://zamiacad.sourceforge.net/web/
> Der veditor hat auch eine interessante Funktion mit strg+Leertaste. Ich habe veditor mal ausprobiert. Der Ansatz ist genau das was ich meinte, aber veditor steckt wirklich noch in den Kinderschuhen verglichen mit dem was die Java-Tools in Eclipse können. > Und natürlich (X)Emacs. vi hat sicherlich auch ähnliches zu bieten. vi/vim ist nicht wirklich was für mich, aber Emacs müsste ich für VHDL-Entwicklung mal ausprobieren. Danke, bin leider nicht selbst auf die Idee gekommen :)
nice gast schrieb: > ps. danke Heinrich für interresante Link! Ist in opencores.org > programmiert man nur mit verilog? ... Nein, VHDL und Verilog.
Gast
#2169972
Martin Geisse schrieb: > Ich habe veditor mal ausprobiert. Der Ansatz ist genau das was ich > meinte, aber veditor steckt wirklich noch in den Kinderschuhen > verglichen mit dem was die Java-Tools in Eclipse können. Und leider wird der veditor auch nicht mehr weiterentwickelt.
Hier noch ein Link zu dem gleichen Programm. http://www.volkerschatz.com/hardware/vhdocl.html#man
Gast
#2175723
>René D. schrieb: >> In C hat sich die hungrian Natation durchgesetzt. >Das wage ich zu bezweifeln. Ich arbeite seit 20 Jahren mit C-Software, aber ich habe noch nie eine solche Notation real gesehen. > *.n für low aktive Signale Es gibt keine loaktiven Signale, sondern nur ... > Negative Signale sagen wir koorekt "negierte Signale" >rst_b eine negative Reset-Leitung genannt. nee, lieber n_rst wobei man sich 3mal überlegen sollte, ob man überhaupt negierte Signale ins Design reinführt, wenn man nicht unbedingt muss und nicht auch die negierte Form in Verwendung hat. Im Grunde genommen sind negierte Signale nur in den seltensten Fällen sinnvoll. Schließen bauen wir Schaltungslogik und Funktionslogik und die ist positiv immer noch ein Einfachsten zu formulieren.
> Ich arbeite seit 20 Jahren mit C-Software, aber ich habe noch nie eine > solche Notation real gesehen. In der Win32-API und entsprechenden Beispielen kam das IIRC vor. Der Code war ziemlich schwer zu lesen, deshalb kann ich nur davon abraten. Das war wohl vor allem gut, damit man am Namen den Datentyp und Variablenart (z.B. Instanzvariable / "Member") erkennen konnte; das machen heute aber die IDEs automatisch. > >rst_b eine negative Reset-Leitung genannt. > nee, lieber n_rst wobei man sich 3mal überlegen sollte, ob man überhaupt > negierte Signale ins Design reinführt, wenn man nicht unbedingt muss und > nicht auch die negierte Form in Verwendung hat. > > Im Grunde genommen sind negierte Signale nur in den seltensten Fällen > sinnvoll. Schließen bauen wir Schaltungslogik und Funktionslogik und die > ist positiv immer noch ein Einfachsten zu formulieren. Ein Anwendungsfall sind off-Chip-Signale. Wenn ein Peripheriechip das Signal negiert braucht, dann braucht er es halt so. Solche Signale wandele ich gleich im Top-Level-Design in nicht-negierte Signale um und arbeite dann mit denen. Ich könnte mir auch vorstellen, dass man das noch ein wenig weiterspinnt, um bessere Kontrolle über die Platzierung der Inverter zu haben, z.B. um die Taktrate bis zum letzten hochzuschrauben. Das wird aber denke ich mit der Evolution der Tools auch nach und nach verschwinden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.