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