Hallo, ich habe wenig Erfahrung mit Verilog/VHDL und den Entwicklungstools. Daher eine Frage an die Experten: Angenommen man hat die Quelldateien für bestimmte Komponenten (z.B. Schnittstellen) die man nutzen möchte in Verilog vorliegen, möchte aber im Projekt bei VHDL bleiben. Ist es möglich beide Sprachen in einem Projekt zu mischen? Kann man von der einen Sprache in die andere automatisch Übersetzen lassen? Ist eine solche Übersetzung eindeutig, frei von Fehlern? Oder würde man immer empfehlen die Übersetzung manuell durchzuführen, wenn die Anwendung hohen Sicherheitsansprüchen genügen muss? Danke und Gruß Haydar
Gast
#5640656
hi, nimm die Sourcen wie sie sind. Mir ist keine automatischen Tool zur Konvertierung bekannt und frei von Fehlern würde das sicherlich auch nicht sein. Das übliche Vorgehen wäre, einfache einen VHDL Wrapper (Komponentenbeschreibung und Instanziierung) schreiben und im VHDL-Projekt verwenden. Die Synthese-Tools kommen damit i.d.R klar. Einzig Simulatoren könnten zicken, da sie das als Mixed-Language Simulation sehen und dafür eine extra/zusätzliche Lizenz verlangen (z.B. Modelsim). grüße
Gast
#5640669
Haydar B. schrieb: > Ist es möglich beide Sprachen in einem Projekt zu mischen? Ist die Frage, ob der benutzte Simulator (bspw modelsim ) und das Synthesetool "mixed Language" unterstütz oder nicht. Und das hängt nicht selten von der Lizenz ab. In der Regel ist eine Umwandlung unnötig.
C. A. Rotwang schrieb: > Haydar B. schrieb: >> Ist es möglich beide Sprachen in einem Projekt zu mischen? > > Ist die Frage, ob der benutzte Simulator (bspw modelsim ) und das > Synthesetool "mixed Language" unterstütz oder nicht. Und das hängt nicht > selten von der Lizenz ab. In der Regel ist eine Umwandlung unnötig. Simulatoren sind überbewertet ... imho^^ Simulation spare ich mir meist komplett ... Aber falls ich doch mal simulieren muss, verwende ich immer GHDL ... Glaub das kann kein Verilog, oder?
Gast
#5640756
Wenn deine Tools den Mixedlanguage-Mode unterstützen, dann lass die Sourcecodes so wie sie sind. In größeren Projekten ist es völlig normal, dass Module aus beiden Sprachen zusammengelinkt werden. Ich habe fast kein Projekt gemacht, wo es anders ist. Was die Tools angeht: GHDL kann nur VHDL. Modelsim PE (Student Edition) kann beides, aber nicht beides gleichzeitig - ein Witz. Die Vollversion von Modelsim kann alles (auch SystemC und SystemVerilog), kostet aber richtig Asche. Die Synthesetools von Vivado unterstützen hingegen schon in der freien Webpack-Version den Mixedlanguage-Mode. Automatische Konverter sind mir nicht bekannt. Du kannst aber z.B. mit einem geeigneten Synthesetool aus dem Original-Sourcecode eine HDL-Netzliste erzeugen lassen. Die ist dann zwar nicht mehr so einfach human-readable, aber du kannst sie zumindest mitsimulieren. Ich hab allerdings noch nicht ausprobiert, ob man eine VHDL-Netzliste aus einem Verilog-Sourcecode erzeugen kann bzw. umgekehrt. Interessante Frage, müsste ich mal die Kollegen nerven. Falls das alles nicht geht, musst du manuell übersetzen. Das ist natürlich fehleranfällig und mit viel Arbeit verbunden, und du musst beide Sprachen beherrschen - was übrigens ohnehin nicht dumm ist. Es ist immer ein großer Fehler, alle Probleme in seiner jeweiligen Lieblingssprache lösen zu wollen. Gegenstand endloser Diskussionen hier im Forum.
Gast
#5640766
Wenn die Lizenzen der Tools stimmen, kann man wie gesagt beide Sprachen mischen. Es gibt einige wenige Stolpersteine, die aber schnell auffallen und für die es workarounds gibt. Z.B ist Verilog case sensitive und VHDL nicht, d.h. wenn bei einem Verilog Modul jemand die geniale Implementierungsidee hatte mehrere Interfacesignale gleichen Namens mit unterschiedlicher Schreibweise (groß/klein) zu nutzen oder ein parameter (generic in VHDL) gleich zu nennen wie ein interface wire (signal in VHDL), nur mit anderer Schreibweise, dann kann man das nicht einfach so in VHDL instanziieren, sondern ein wrapper muss her.
Vancouver schrieb: > Automatische Konverter sind mir nicht bekannt. Du kannst aber z.B. mit > einem geeigneten Synthesetool aus dem Original-Sourcecode eine > HDL-Netzliste erzeugen lassen. Die ist dann zwar nicht mehr so einfach > human-readable, aber du kannst sie zumindest mitsimulieren. Ich hab > allerdings noch nicht ausprobiert, ob man eine VHDL-Netzliste aus einem > Verilog-Sourcecode erzeugen kann bzw. umgekehrt. Interessante Frage, > müsste ich mal die Kollegen nerven. Die X* und L*-Tools können das zumindest, aber bei X war man mit Verstümmelungen schon einfallsreich, damit es nicht mit allen VHDL-strikten Simulatoren geht. Heisst beim X 'Generate Post-Map Simulation model', geht auch in 'post PAR'. Was Konvertierung angeht, mit icarus verilog kann man bisschen was machen, klappt aber auch nicht immer, und man muss mim Editor ran. Siehe dazu auch: https://github.com/ghdl/ghdl/issues/711
Vielen Dank für die Antworten, das hat mir schon mal geholfen. Gruß Haydar
Gast
#5644800
@Martin S. Post-PAR ist aber dann doch ein Timing-Simulationsmodell mit Delays, oder? Kann man nach PAR auch noch ein rein funktionales Modell erzeugen?
Vancouver schrieb: > @Martin S. > > Post-PAR ist aber dann doch ein Timing-Simulationsmodell mit Delays, > oder? Kann man nach PAR auch noch ein rein funktionales Modell erzeugen? Nee, so richtig funktional ist es schon nach dem Mappen nicht mehr, da die HDL aus der bereits vom Synthesetool gemappten Netzliste (mit allfällig instanzierten FPGA-Primitiven) generiert wird. Wenn von den Primitiven die Simulationsmodelle nicht oder für den entsprechenden Simulator nicht lesbar (IEEE 1735 sei Dank) vorliegen, kommt man so schon mal nicht weiter. Dementsprechend läuft die Simulation auch sehr langsam ab, oder macht Macken, wenn der Simulator mit VITAL-Kram nicht klarkommt. Das kann derart zum Showstopper werden, dass man sich eine andere FPGA-Plattform suchen muss, wenn durchgängige Verifikation ein Muss ist.
Gast
#5645286
Mit rein funktional meinte ich ohne Timing, d.h. kombinatorische Logik hat eine Delay von Null im Simulationsmodell. Technologieabhängige Primitive sind da natürlich drin, das ist schon klar. Aber abgesehen davon, dass sie die Simulation verlangsamen und auf einigen Simulatoren nicht funktionieren, haben sie keine weiteren Auswirkungen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.