Trennung von Entity/Architecture

[pks (Gast)]

Servus,

ich krieg jedes mal Pickel, wenn ich mich in fremden Code einarbeiten 
muss, bei dem Entity und Architecture in getrennten Dateien liegen.
Dieses Vorgehen:
- verdoppelt die Anzahl der Dateien.
- macht das Nachverfolgen von Signalen durch mehrere Instanzen ziemlich 
mühselig.

Deshalb frage ich mal in die Runde - macht das von Euch jemand so und 
wenn ja warum :-) Gibt es einen guten Grund dafür? (Hat unser Prof 
damals auch so gemacht ist keiner! ;-))

[Christoph Z. (christophz)]

> macht das von Euch jemand so

Ich nicht.

> Gibt es einen guten Grund dafür?

Ich bin immer interessiert an objektiven Gründen für ein bestimmtes 
Vorgehen.

[Klaus F. (kfalser)]

Christoph Z. schrieb:
>> Gibt es einen guten Grund dafür?
>
> Ich bin immer interessiert an objektiven Gründen für ein bestimmtes
> Vorgehen.

Das Ganze betrifft mehr Simulationsumgebungen als synthetisierbare 
Dateien.

Ein Grund ist, dass es verschiedene Implementierungen (architectures) 
für eine entity geben kann.
Man kann dann in eine library eine weitere architecture nachträglich 
hineinkompilieren, ohne die Interface-Beschreibung zu ändern.

Hätte man die Enitity Beschreibung und die Architecture im gleichen 
File, dann würde der Simulator jedesmal merken, dass Entity Beschreibung 
neuer ist als der Rest und würde verlangen, dass alle darauf aufbauenden 
Entities auch neu kompiliert werden müssen.
Das kann dann einm Rattenschwanz sein, der sich bis ins Top_level 
hinzieht.

Hat man die Interface Beschreibung in einem getrennten File, dann wird 
diese nicht jedesmal mitkompiliert, wenn man die Architecture ändert 
oder erweitert.
Der Simulator weiss in diesem Fall, dass sich die Schnittstellen nicht 
geändert haben kann, und verkangt keine Neukompilation der darauf 
aufbauenden Units.

[pks (Gast)]

Ok, sowas habe ich mir schon gedacht...
Aber findest Du es sinnvoll das pauschal für alle Module zu machen?
Bei mir kommt dieser Fall nur mal für einzelne Module vor, wenn ich z.B. 
während der Entwicklung mal was ausprobieren will. Dann kopiere ich halt 
einfach die Datei und benenne das Original um.

[Christoph Z. (christophz)]

Klaus Falser schrieb:
> Hat man die Interface Beschreibung in einem getrennten File, dann wird
> diese nicht jedesmal mitkompiliert, wenn man die Architecture ändert
> oder erweitert.
> Der Simulator weiss in diesem Fall, dass sich die Schnittstellen nicht
> geändert haben kann, und verkangt keine Neukompilation der darauf
> aufbauenden Units.

Active-HDL (Weiss nicht seit wann, sicher >9.1) scheint das 
auseinanderhalten zu können, auch wenn es in der selben Datei ist.
Solange ich die Entity nicht ändere muss ich nur die geänderte Datei 
(Mit Entity und Architecture) neu kompilieren und die Simulation neu 
starten. Wenn ich die Entity ändere und den Rest nicht kompiliere, 
werden bei der Initalisierung der Simulation Fehlermeldungen generiert. 
(Gefühlt machen die das so, dass die VHDL Architekturen in C++ Klassen 
übersetzt werden. Solange die Entity unverändert ist, lassen sich 
fehlerfrei Objekte kreieren und verbinden).

Wie sieht das bei anderen Simulatoren aktuell aus (ModelSim, GHDL etc.)?

[Freddy (Gast)]

Ich kenne das Verfahren noch aus Studienzeiten. Damals hatten wir noch 
mit irgendwelchen ASIC Tools Mentor Graphics unter SunOS gearbeitet.
Sehr verwirrend, wenn der Prof im Labor nur kleine Adder, Subtrahierer, 
etc. demonstrieren will und man sowieso erstmal den Wald vor lauter 
Bäumen nicht sieht.
Jetzt in der Entwicklung für synthesefähige Designs kommt es selten vor, 
dass man sowas macht. Höchstens, wenn man mal im Design ein Modul mit 
gl. Schnittstelle neu schreibt. Das kann u.a. vorkommen wenn man dieses 
Modul anders beschreibt um zu sehen wie es sich bezüglich Laufzeit und 
Routing verhält.

[Klaus F. (kfalser)]

pks schrieb:
> Aber findest Du es sinnvoll das pauschal für alle Module zu machen?

Nein, ich nicht.

Christoph Z. schrieb:
> Wie sieht das bei anderen Simulatoren aktuell aus (ModelSim, GHDL etc.)?

Habe jetzt auch schon länger nicht mehr mit ModelSim gearbeitet, es kann 
aber sein dass es dort auch intelligenter gelöst ist.

Bei ISIM, diesem Depp, muss man sowieso immer alles neu kompilieren.