Hi, sehe ich es richtig, daß wenn ich mehrere vhdl-module habe, die ich im Toplevel verbinde, die verbindungen zwischen den einzelnen modules als signale im toplevel definieren muss, oder gehts einfacher?
> oder gehts einfacher?
Nein, du brauchst für die Verbindungen zwischen zwei Komponenten
Signale. Nur die Signale, die vom Top-Entity-Port raus- oder reingehen,
kannst du direkt verbinden.
Als Tipp: mach nicht so viele Komponenten, dann mußt du nicht so viel verdrahten... ;-)
Da gebe ich lkmiller vollkommen recht. Mit mehreren Komponenten ist es zwar meist etwas übersichtlicher, aber gerade bei Programmen die man auf einem CPLD und nicht auf einem FPGA implementieren will kann das dazu führen, dass man schnell an die Grenzen der Makrozellen kommt. Da du ja für die Module zusätzliche Ein- und Ausgänge benötigst werden hier bei einem CPLD Latches angelegt die wiederum Makrozellen verbraten. Aber auf einem FPGA hat man ja meist genug Ressourcen, da spielt das keine Rolle ;-). Gruß Phil
Phil schrieb: > Mit mehreren Komponenten ist es > zwar meist etwas übersichtlicher, aber gerade bei Programmen die man auf > einem CPLD und nicht auf einem FPGA implementieren will kann das dazu > führen, dass man schnell an die Grenzen der Makrozellen kommt. Das stimmt so nicht. Die Anzahl der verwendeten Makrozellen hängt nur von der Komplexität der Schaltung ab. Ob man diese in Module aufteilt oder alles in einen Prozess schreibt, ist komplett egal. > Da du ja > für die Module zusätzliche Ein- und Ausgänge benötigst werden hier bei > einem CPLD Latches angelegt die wiederum Makrozellen verbraten Quatsch.
>> Da du ja für die Module zusätzliche Ein- und Ausgänge benötigst werden Das sind nur interne Signalnamen, die werden vom Synthesizer sofort wieder rausgeworfen und durch eine Verbindung ersetzt. >> hier bei einem CPLD Latches angelegt die wiederum Makrozellen verbraten Latches werden ganz anders und meist eher aus Versehen angelegt...
Zum Verbinden habe ich auch noch eine Frage. Es gibt zwei Varianten wie man eine Komponente einbinden kann. Variante 1: Wenn man eine Komponente einbindet schreibt man in die architecture.
1 | architecture Behavioral of ps2_to_uart is |
2 | |
3 | signal ................ |
4 | |
5 | |
6 | --ich nenne es mal deklarieren
|
7 | --
|
8 | COMPONENT Uart_8N1_TR |
9 | PORT( |
10 | clk : IN std_logic; |
11 | load : IN std_logic; |
12 | data_in : IN std_logic_vector(7 downto 0); |
13 | busy : OUT std_logic; |
14 | tx : OUT std_logic |
15 | );
|
16 | END COMPONENT; |
17 | |
18 | begin
|
19 | -- hier wird eine Instanz davon in die Hardware eingebaut und
|
20 | -- mit Signalen verdrahtet
|
21 | Inst_Uart_8N1_TR: Uart_8N1_TR PORT MAP( |
22 | clk => clk, |
23 | load => load, |
24 | data_in => data, |
25 | busy => open, |
26 | tx => TX ); |
27 | --
|
Variante 2:
1 | architecture Behavioral of ps2_to_uart is |
2 | -- man spart sich die Deklaration
|
3 | |
4 | begin
|
5 | uart_receiver: entity work.Uart_8N1_RX |
6 | PORT MAP( |
7 | clk => clk50_in, |
8 | store_out => uart_in, |
9 | data_out => data_uart, |
10 | rx => rx_in |
11 | );
|
Ich bevorzuge die Varinate 2, weil wenn in der Entwicklung ein Port sich ändert, ist diese Änderung an zwei Stellen durchzuführen und der Quellcode wird außerdem kürzer. Leider weiß ich über das Schlüsselwort work zu wenig. Welche Mechanismen werden hier verwendet und welche Randbedingungen hängen hier dran?
work ist einfach der Name der Bibliothek, in der die Komponente liegt. Alles, was man nicht explizit in eine eigene Bibliothek packt, landet in work.
Bitte 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.