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.
:
Bearbeitet durch User
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.