verbinden von modulen

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

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.