Datei-struktur und Benamung bei der VHDL Entwicklung

[René D. (Firma: www.dossmatik.de) (dose)]

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?

[woko (Gast)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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.

slv15d0Ausgang <= ('others'0'); -- std_logic_vector 15 downto 0
u4t9Bits       <= "010101";     -- unsigned 4 to 9
i0t3456Wert    <= 1234;         -- integer 0 to 3456

Und insbesondere bei Zuständen von FSM wird das dann komplett 
undurchschaubar:

type state_t is (reset, idle, work, done);
signal Zustand : state_t := idle;

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:

Ausgang <= (Ausgang'range->'0');
Bits    <= Bits(Bits'left-1 downto 0) & '1';
Wert    <= Wert'max;

[Christian R. (supachris)]

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.

[Duke Scarring (Gast)]

Einige opencores-Projekte liefern da auch Anhaltspunkte.

Meine übliche Struktur sieht so aus:

modul_A 
  + rtl
  + rtl_testbench
  + doc
       
modul_B 
  + rtl
  + rtl_testbench
  + doc

top_modul
  + rtl
  + rtl_testbench
  + syn

Je nach Bedarf gibt es weitere Unterverzeichnisse für C-Quellcode oder 
Generatorskripte. Die jeweiligen Programme (Simulator, Synthesizer, 
etc.) werden per makefile gestartet.

Duke

[Maik H. (littlechip)]

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

[Fpgakuechle K. (Gast)]

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

[Georg A. (Gast)]

> 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.

[Matthias G. (mgottke)]

> *_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.

[Fpgakuechle K. (Gast)]

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

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Christian R. (supachris)]

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.

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Christian R. (supachris)]

Dem Anwender sind doch da völlig frei, es sollte nur durchgängig sein.

[René D. (Firma: www.dossmatik.de) (dose)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Frei nach dem Motto:  Nach dem Takt ist vor dem Takt...  ;-)

[Fpgakuechle K. (Gast)]

Lothar Miller schrieb:
> Frei nach dem Motto:  Nach dem Takt ist vor dem Takt...  ;-)

:-))

[Matthias G. (mgottke)]

>> (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.

[Duke Scarring (Gast)]

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:

type channel_t is record
  cs  : std_logic;
  clk : std_logic;
end record;

type adc_t is record
  ch1 : channel_t;
  ch2 : channel_t;
end record;

signal adc: adc_t;

[...]

adc.ch1.clk <= ...;

Der Aufwand rentiert sich schon bei der "Verdrahtung" von 
Modulen/entitys.

Duke

[René D. (Firma: www.dossmatik.de) (dose)]

records ist was Tolles in VHDL.

Nutze ich auch viel zu wenig.

[Matthias G. (mgottke)]

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:

process(channel_t.rst, channel_t.clk)
begin
   if channel_t.rst = '1' then
      channel_t.data <= (others => '0');
   elsif rising_edge(channel_t.clk) then
      if channel_t.cs = '1' then
         xyz <= channel_t.data;
      end if;
   end if;
end process;
-- Hoffentlich habe ich mich diesmal nicht vertippt.

Wenn ich aber mehrere Kanäle habe könnte sich da der record schon 
lohnen.

[René D. (Firma: www.dossmatik.de) (dose)]

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ß.

[Johann (Gast)]

Ich nehme immer das Prefix S_ für signale

S_Counter <= "010101010";

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ich nehme immer das Postfix "<=" für Signale     :-/

Counter <= "010101010";

[Georg A. (Gast)]

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:

       DDR_MCH_OPB_1: ddr_mch_opb
                port map (
                        clk132, clk132n,
                        clk132_90, clk132_90n,
                        clk132_fb90, clk132_fb90n,
                        clk66, low,
                        dcm_3_lock,
                        mch1_in, mch1_out,  -- mch dcache
                        mch0_in, mch0_out,  -- mch icache                        
                        bm0_in, bm0_out,    -- DMA 0
                        bm1_in, bm1_out,
                        bm2_in, bm2_out,
                        
                        sd_ck_p, sd_ck_n, sd_cke, sd_cs,
                        sd_ras, sd_cas, sd_we,
                        sd_dm, sd_ba, sd_a,
                        sd_dq, sd_dqs,
                        ddr_dbg);

[Matthias G. (mgottke)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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.

[Georg A. (Gast)]

> 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.

[nice gast (Gast)]

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

[Klaus (Gast)]

René D. schrieb:
> In C hat sich die hungrian Natation durchgesetzt.

Das wage ich zu bezweifeln.

[Heinrich H. (Firma: Ich.AG) (hhanff)]

http://web.engr.oregonstate.edu/~traylor/ece474/lectures/opencores_coding_guidelines.pdf

Da findest Du eine empfohlene Ordnerstruktur sowie übliche 
Signalnamenerweiterungen.

[Martin G. (Firma: Leckermittag.de) (morin)]

> 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)

[nice gast (Gast)]

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?

[D. I. (Gast)]

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.

[Marcus H. (mharnisch)]

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 H. (mharnisch)]

Marcus Harnisch schrieb:
> vi hat sicherlich auch ähnliches zu bieten.

Ich meinte natürlich vim.

[René D. (Firma: www.dossmatik.de) (dose)]

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/

[Martin G. (Firma: Leckermittag.de) (morin)]

> 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 :)

[Heinrich H. (Firma: Ich.AG) (hhanff)]

nice gast schrieb:
> ps. danke Heinrich für interresante Link! Ist in opencores.org
> programmiert man nur mit verilog?
... Nein, VHDL und Verilog.

[Klaus (Gast)]

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.

[René D. (Firma: www.dossmatik.de) (dose)]

Hier noch ein Link zu dem gleichen Programm.


http://www.volkerschatz.com/hardware/vhdocl.html#man

[RakiDeFrance (Gast)]

>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.

[Martin G. (Firma: Leckermittag.de) (morin)]

> 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.