Struktur eines VHDL Codes

[Meth J. (arren)]

Hallo,

Ich habe eine Verstädnisfrage zum generellen Aufbau einse VHDL Codes. 
Vor einigen Tagen habe ich ebenfalls ein Thema im Forum aufgemacht 
welches sich speziell auf meine Ausarbeitung bezieht und bei den 
Antworten gemerkt das mir etwas für das Grundverstädnis fehlt. Um es 
plastisch und beispielhaft zu halten, beziehe ich mich auf die 
angehängte Darstellung.


Ist es richtig, dass (vermutlich ein möglicher Lösungsansatz) ich für 
die Kodierung der Darstellung die "enitity", "architecture Struktur 
(beinhaltet "component sowie port map"), sowie "architecture Verhalten" 
brauche?

Kurze Erläuterung zu meiner Herangehensweise:

- entity definiert mir die Ein- und Ausgänge

- architecture Struktur -> component definiert mir die Ein- und Ausgänge 
von BS1, BS2, BS3

- architecture Struktur -> Signal definiert mir die Bezeichnungen der 
Verbindungen zwischen BS1, BS2, BS3

- Architecture Stuktur -port map definiert mir die Verbindungen zwischen 
BS1, BS2, BS3

Nach dem nun alle Ein- und Ausgänge, sowie deren Zusammenhänge 
deklariert wurden, geht das die Funktion von BS1, BS2, BS3 zu 
beschreiben

-architecture Verhalten: der hier befindliche Code ist nur exemplarisch 
und soll nur meine Herangehensweise verdeutlichen. Jetzt wo zuvor die 
Grundstruktur definiert wurde, kann ich mich im archtecture Verhalten um 
die definition von BS1, BS2 und BS3 kümmern.


Sehe ich das ganze so richtig?

1  library IEEE;        
2  use IEEE.STD_LOGIC_1164.ALL;        
3  use IEEE.NUMERIC_STD.ALL;        
4          
5          
6          
7  entity Ordnung is        
8    port (clk, a, b  : in std_logic;    
9    z    : out std_logic;)  
10  end Ordnung;        
11          
12          
13          
14  architecture Struktur of Ordnung is        
15          
16          
17    component BS1      
18      port (a, clk: in std_logic;    
19        c: out std_logic);  
20    end component;      
21          
22          
23    component BS2      
24      port (b, clk: in std_logic;    
25        d: out std_logic);  
26    end component;      
27          
28          
29    component BS3      
30      port (e,f  : in std_logic;  
31                    g: out std_logic);    
32    end component;      
33          
34        
35          
36          
37    signal clk, s1, s2: std_logic;      
38    signal s3  : std_logic;    
39          
40          
41  begin        
42          
43          
44    B1: BS1      
45      port map (clk => clock, a => a, c => s1);    
46          
47    B2: BS2      
48      port map (clk => clock, b => b, d => s2);    
49          
50    B3: BS3      
51      port map (e => s1, f => s2, g => z);    
52          
53          
54          
55          
56          
57  architecture Verhalten of BS1 is         
58          
59  signal c : integer range 0 to 24999999 := 0;         
60  signal x : std_logic:= '0';          
61          
62  begin         
63     process begin          
64        wait until rising_edge(clk);          
65        if (c<24999999) then        
66            c <= c+1;        
67        elset:         
68            c <= 0;         
69            x <= not x;         
70        end if;         
71     end process;         
72     c <= x;        
73  end Behavioral;        
74          
75          
76          
77          
78          
79  architecture Verhalten of BS2 is         
80          
81  signal c : integer range 0 to 1999999 := 0;         
82  signal x : std_logic:= '0';          
83          
84  begin         
85     process begin          
86        wait until rising_edge(clk);          
87        if (c<1999999) then        
88            c <= c+1;        
89        elset:         
90            c <= 0;         
91            x <= not x;         
92        end if;         
93     end process;         
94     d <= x;        
95  end Behavioral;        
96          
97          
98  architecture Verhalten of BS3 is         
99          
100  .        
101  .        
102  .        
103  .        
104  .        
105  .        
106          
107  end Behavioral;

[J. S. (engineer)]

Ja, wobei ich hier wieder einige Dinge erkenne, die in die falsche 
Richtung führen können, daher nur soviel:

Wie du die arch nennst, ist egal. Das behavio(u)ral ist nur ein 
lapidarer Hinweise. Man nutzt es zum Kennzeichnen, weil man an eine 
entity auch mehrere austauschbare arch binden kann / könnte.

Die Reihenfolge, die Du da so schön aufziehst, ist ebenfalls belanglos.

Wie Du VHDL-Code aufbaust, vor allem in Sachen Hierarchien, wird sich an 
der Aufgabe anlehnen.

Was man tun sollte, ist Physik von Logik zu trennen und damit gleichsam 
die oft harten herstellerspezifischen- und bausteinspezfischen 
Funktionen von den soften Funktionen zu trennen, die optimiert werden 
können und anwendungsspezifisch verwendet werden.

Zudem Thema könnte man aber Bücher schreiben.

[Klakx (Gast)]

da siehst du schon einiges richtig.

ohne vollständig zu sein:

Nennen wir es das Modul "ordnung", dann hast du es schonmal richtig 
angegangen eine Entity "ordnung" für die Ein- und Ausgänge zu 
beschreiben. Richtig auch der Inhalt "struktur" als architecture.

Ein Fehler ist "signal clk". Denn "clk" ist bereits schon als Signal 
durch die entity bekannt.

Wie du es auch richtig darstellst, setzt du Untermodule (BS1,..) in 
deine Beschreibung "struktur" ein. Diese machst du in deiner 
Beschreibung bekannt durch component .. end component; und durch die 
Instanziierung.

Was noch fehlt ist die entity für BS1, BS2 und BS3. Denn jedes Modul hat 
eine entity und mindestens (in der Regel jedoch meist) eine 
Architecture. "Component" ist nur für den Aufruf des Moduls da, das 
Modul muss jedoch weiterhin vollständig beschrieben werden.

[Meth J. (arren)]

Klakx schrieb:

> Was noch fehlt ist die entity für BS1, BS2 und BS3. Denn jedes Modul hat
> eine entity und mindestens (in der Regel jedoch meist) eine
> Architecture. "Component" ist nur für den Aufruf des Moduls da, das
> Modul muss jedoch weiterhin vollständig beschrieben werden.


Vielen Dank soweit für die Antworten.

Klakx, du erwähnst die entities für BS1, BS2 und BS3. Sehe ich das 
richtig, wenn ich die Entities ergänze, dass ich die "Components" 
weglassen kann? Sonst wäre es doppelt gemoppelt.

[Meth J. (arren)]

Eine weitere Frage, die mir gerade aufkommt, betrifft die architecture 
Verhalten.

In den jeweiligen architectures von BS1, BS2, BS3 deklariere ich signale 
wie "c" und "x". Diese kommen in BS1 und BS2 doppelt vor. Stellt es ein 
Problem dar? Wohl eher nicht, weil die architectures für sich 
geschlossen wirken, richtig?

[Klakx (Gast)]

Meth J. schrieb:
> Vielen Dank soweit für die Antworten.
>
> Klakx, du erwähnst die entities für BS1, BS2 und BS3. Sehe ich das
> richtig, wenn ich die Entities ergänze, dass ich die "Components"
> weglassen kann? Sonst wäre es doppelt gemoppelt.

Bitte schön. Nein, in diesem Fall brauchst du sie. Entitys sind die 
Interface-Beschreibung des Moduls und Architectures sind die Inhalte des 
Moduls. Wenn du ein anderes Modul aufrufen willst, dann musst du es dem 
Hauptmodul bekannt machen.

In etwa so:
ordnung (entity,architecture)
bs1(entity,architecture)
bs2(entity,architecture)
bs3(entity,architecture)

das sind vier Module, die ohne weitere Informationen voneinander 
unabhängig sind.
Es ist auch eine geläufige Methodik diese in 4 Dateien zu separieren. 
Manche Compiler verlangen das sogar von dir.

Nun instanzierst du ein Modul vom Typ BS1 nämlich B1. Aber woher weiß 
"Ordnung" wie das Interface aussieht? --> durch die 
Componentbeschreibung.

Ja es wirkt doppelt-gemoppelt. Erste Abhilfe wäre die 
Componentbeschreibung in ein Package auszulagern (Das macht z.B. Xilinx 
mit den unisim-Modulen). In der Regel schreib ich die 
Componentbeschreibung hin.

Meth J. schrieb:
> Eine weitere Frage, die mir gerade aufkommt, betrifft die
> architecture
> Verhalten.
>
> In den jeweiligen architectures von BS1, BS2, BS3 deklariere ich signale
> wie "c" und "x". Diese kommen in BS1 und BS2 doppelt vor. Stellt es ein
> Problem dar? Wohl eher nicht, weil die architectures für sich
> geschlossen wirken, richtig?

richtig. Die Deklarationen von c und x in der Architecture gelten nur 
dort.


zwei Sachen noch :)

Pro-Tipp: Das sind viele Grundlagenfragen, die frei in Netz mehrfach in 
pdfs und powerpoints erklärt werden.

Pro-Tipp 2: Hol dir eine Entwurfsumgebung. Wie z.B. Xilinx-Webpack. Der 
Syntax checker und die herangehensweise helfen dir an dich Sache 
praktischer ranzugehen.