Forum: FPGA, VHDL & Co. Variable Modularisierung mit VHDL möglich?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von zwiepack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo in die Runde,

ich bin auf der Suche nach Programmierkonstrukten mit denen ich in 
wenigen Handgriffen neue Module in VHDL einbinden kann. Was meine ich 
damit? Die Sachen mit den Components sind mir klar und werden genutzt, 
aber ich hab ein etwas anderes Anliegen. Und zwar suche ich, um es mal 
bildlich auszudrücken, eine Art Steckdosenleiste variabler Länge. Wobei 
ich die Stecker zur Synthese selbst hinzufüge oder entferne, je nach 
Bedarf.

Also ich hab Module (die Stecker) , deren entity Ein- und Ausgänge immer 
gleich bleiben und ein weiteres Modul (die Steckdosenleiste), welche all 
die Module aufnimmt.

Nun suche ich nach einem Kniff, damit ich diese Idee in VHDL umsetzen 
kann.

von Pat A. (patamat)


Bewertung
0 lesenswert
nicht lesenswert
So ganz genau verstehe ich nicht, was Du möchtest, aber evtl. hilft Dir 
eine for-Schleife über ein 'generate'. Damit kann man u.a. auch eine 
variable Anzahl von Komponenten instanziieren und mit 'if' auch 
verschiedene - wenn es sein muss.

: Bearbeitet durch User
von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe und glaube auf was du hinaus willst.. quasi stört es immer 
die ganzen Entities umzuschreiben.

Schau mal, ob du input und output records nutzen kannst. Damit kannst du 
viele Signale zusammenfassen.

Wie Vorposter schon sagt, sind generates auch eine gute Möglichkeit für 
mehrere Komponenten.

Wenn man die Steckdosenleiste als Anlehnung weiterverfolgt, sollten 
Bus-Interfaces auch von Bedeutung sein.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wie variabel soll das sein?  Ich meine, die neuen Module können jegliche 
Gestalt haben und man weiß im Vorhinein nicht, was sie an IN OUTs haben.

von Schlumpf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zwiepack schrieb:
> Also ich hab Module (die Stecker) , deren entity Ein- und Ausgänge immer
> gleich bleiben und ein weiteres Modul (die Steckdosenleiste), welche all
> die Module aufnimmt.

Klakx schrieb:
> quasi stört es immer
> die ganzen Entities umzuschreiben.

So wie ich es verstanden habe, sind die Entities immer identisch. Es 
geht nur darum, die Anzahl der verwendeten Components (mit identischen 
Entities) variabel zu halten.

Ich denke, pauschal kann das nicht beantwortet werden.
Dazu müsste man wissen, welche Funktion hinter der Steckdosenleiste 
steckt.
Also wie kommunizieren die Components untereinander? Oder hat die 
Steckdosenleiste auch eine Funktion (außer Verdrahtung).

Prinzipiell löst sowas aber ein Bussystem.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Schlumpf schrieb:
> So wie ich es verstanden habe, sind die Entities immer identisch. Es
> geht nur darum, die Anzahl der verwendeten Components (mit identischen
> Entities) variabel zu halten.

Also die Zahl der Instanzen? Das ging doch mit generate. (?)
Die Verdrahtung ist halt gfs ein Problem, weil man die Rücklesepfade 
irgendwie vereinen muss. Ein logisches Bussystem wäre da sicher das 
Einfachste.

Aber das macht ja das EDK-System mit dem AXI-Geraffel schon so.

von Schlumpf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Also die Zahl der Instanzen? Das ging doch mit generate. (?)

Vielleicht sind es auch mehrere Components mit identischen Entities..
Dann wären es nicht mehrere Instanzen.

Wir wissen es einfach nicht und daher ist das hier mehr oder weniger ein 
lustiges Rätselraten ;-)

von zwiepack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das ist aber auch schwierig zu erklären was ich vorhabe. :) Mich stört 
im Grunde, dass wenn ich ein neues Modul hinzufüge oder entferne, so 
viel am Code herumfummeln muss, bis wieder alles stimmt.

Also ganz grob. Ich hab ne Art Muxer aufgebaut, der n:1 Verbindungen auf 
eine Resource abbildet. Der Muxer selbst sucht sich raus, wer als 
nächstes von den Modulen reden darf. Die Module zeigen nur an, das sie 
reden wollen. Die Schnittstellen der Module sind immer gleich. Das 
Verhalten, wenn sie reden wollen auch.

Nun fängt der Spaß an. Angenommen ich will ein Modul hinzufügen, dann 
muss schon die Portliste des Muxes angepasst werden.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dann reicht Dir vielleicht das Blockdesign-System von Vivado. Da kann 
man records definieren und beim Platzieren von neuen Symbolen werden sie 
automatisch verdrahtet. Bei den AXI Bussen ist das so. Ist ein 
Mausklick.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zwiepack schrieb:
> Nun fängt der Spaß an. Angenommen ich will ein Modul hinzufügen, dann
> muss schon die Portliste des Muxes angepasst werden.

Klingt gerade mal nach einem Signal, aber: Wenn du das automatisieren 
willst, musst du vielleicht mit dem C Preprocessor tricksen (VHDL kann 
das nicht per Standard). Das kann man sich mit dem ursprünglichen 
linux-kconfig auch schön konfigurierbar stricken, siehe auch 
http://tech.section5.ch/news/?p=370.

Die komplexeren Sachen lassen sich mit XML-Tricks erschlagen, aber da 
öffnest du ein Fass (und das offene IP-XACT ist in der FPGA-Welt noch 
nicht wirklich gut adoptiert worden).

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht ob da der Aufwand lohnt, denn in irgendeiner Form muss 
dem System ja bekannt gemacht werden, was gebaut werden soll und das 
erhebt sich die Frage, an welcher Stelle man dem Designtool die Infos 
mitgibt und wie.

Ich kenne da ein System für Verdrahtung von Libraryies, Instanzen und 
Synthesekonstrukten mit DSPs und FPGA-Module, dass mal ein Kunde von mir 
entwickelt hat. Das lief so, daß man ein grafische Blöckchen hatte, das 
mit GEDA in einen Schaltplan gesteckt und und eine Auswahlliste an 
Verdrahtungsoptionen bot. Man nahm dann z.B. die Optionen A, F und X und 
er baute dann die Module in VHDL genau so hin, dass es passt, mit 
Busbreiten, Inferfaces zu den DSPs und allem möglichen. Ein richtig 
kleines SOPC System.

Das klappte wunderbar, lohnte aber nur bei den speziellen Strukturen 
dieses Kunden und verhinderte nur Routineverdrahtungsfehler, denn wann 
immer sich eine neue Option bot, eine neue CPU kam oder eine andere 
Prozessorgeneration mit anderen Ports und Speeds, mussten alle Module 
angepasst werden. Von neuen FPGAs ganz zu schweigen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.