Hallo Leute! Ich versuche gerade einen IP-Core an ein Microblaze-Prozessor zu hängen. Über den OPB-Bus. Den IP-Core habe ich selbst unter VHDl-entwickelt (Mein Erster.). Die Simulationen unter Modelsim verliefen erfolgreich. Der VHDL-Code, der den IP-Core darstellen soll funktioniert. Ich habe auch eine Post-Place & Rout Simulation durchgeführt. Alles funktionierte. Der IP-Core besitzt 2 Ausgangspins: Enable, CLK Und einen bidirektionalen Pin, der zwischen Eingang und Ausgang schaltet: Data In das File User-Logic habe ich mein VHDL-Model instantiiert. Hab dort auch entsprechende Port deklariert. Wenn ich jetzt einen Bit-Stream unter XPS generieren möchte, damit das Prozessorsystem entsprechend synthetisiert wird, dann schreibt mir das Programm folgende Fehler raus: bus_0_wrapper (bus_0) - C:\test\System.mhs line 170 - Running XST synthesis ERROR:Xst:2585 - Port <ssdata_I> of instance <bus_0> does not exist in definition <bus>. ERROR:Xst:2585 - Port <ssdata_O> of instance <bus_0> does not exist in definition <bus>. ERROR:Xst:2585 - Port <ssdata_T> of instance <bus_0> does not exist in definition <bus>. ERROR:Xst - Unexpected error found while building hierarchy. ERROR:MDT - HDL synthesis failed! INFO:MDT - Refer to Nur der bidirektionale Pin macht anscheinend Probleme? Was mache ich falsch? Danke im Voraus für eure Antworten Profis. Tschüss Martin
> Nur der bidirektionale Pin macht anscheinend Probleme? Das hört sich für mich so an, als würdest du im FPGA Tristate-Signale verwenden wollen. Das funktioniert nicht, weil Tristate nur mit richtigen Ein- und Ausgangspins funktioniert. Mein Tipp :-) Mfg Thomas Pototschnig
Es handelt sich um einen bidirektionalen Pin. Sobald das VHDL-Model auf den PIN geschrieben hat, wird dem PIN ein Z zugewiesen und dann sollte er als Eingangspin fungieren. Tschüss Martin
Aber es ist schon ein richtiger, physikalischer Pin am FPGA den du bidirektional verwenden willst? Wenn ja, dann weiß ich leider auch keine Antwort :-( Mfg Thomas Pototschnig
Das EDK bekommt das mit den Tristate Pins so nicht gebacken. Ich glaube, dass das daran liegt, dass man intern im FPGA (Spartan3e bei mir, weiß nicht was die Virtexte da machen) keine Tristate Signale routen kann. Die Tristate Signale werden erst im Porttreiber zusammengeführt. Du musst daher einen Trick anwenden, damit deine userlogic das kann. Du musst dein Signal 3 Mal deklarieren mit folgendem Schema: Wenn das Signal "SIGNAL" heißt, dann deklarierst du in der Entity SIGNAL_I SIGNAL_O SIGNAL_T _I ist ein Input, _O und _T ein Output. Wenn du dem _T Signal logisch eins zuweist, dann geht der Ausgang auf Tristate. Ansonsten kannst du über die anderen beiden signale den pin setzen/lesen. Vergiss nicht, den Port auch in der .mpd datei entsprechend zu deklarieren, wenn er an einen externen Pin soll: PORT SIGNAL = "", DIR = IO Ich hatte das Problem auch schon und da muss man erstmal drauf kommen. Ich hoffe, dass dir das hilft Gruß, Thomas
Hallo Breti! Das hört sich extrem interessant an. Dies ist sicher der Fehler. Ich bin mir jetzt jedoch nicht ganz sicher, wie ich vorgehen muss. Vielleicht darf ich dir meine Architektur kurz erklären: Ich habe ein VHDL-Model erstellt, welches einfach im Model-Sim zu testen ist. Sobald das Startregister beschrieben wird, schickt das Model die Daten ab. Dann habe ich das VHDL-Model mittel Entity-Instantiation in die User-Logic reingeholt. Diese User-Logic wird wiederrum in den Hauptblock instantiiert, der am OPB-Bus hängt. Muss ich jetzt diese drei Deklarationen schon in der untersten Ebene durchführen (also beim VHDL-Model) oder erst im File User-Logic? Danke für deine Hilfe. Tschüss Martin
Leider habe ich bisher nur wenig Erfahrung mit der Simulation und dem "importieren" von einem Model, wie du es beschreibst. Du musst deine Userlogic auf jeden Fall erstmal so umschreiben, dass sie in der entity die drei Signale enthält und natürlich den VHDL Code so abändern, dass er in der Userlogic diese 3 Signale anstatt des bisherigen Tristate Signales bedient. Dazu kommt dann noch das toplevel vhdl file deines cores, welches im gleichen verzeichnis liegt. auch dort müssen die signale geändert werden. das sollte es dann aber eigentlich gewesen sein. Gruß, Thomas
Das klingt ja extrem seltsam. Normalerweise werden tristate Signale intern zu einer Multiplexer Struktur. Wenn der Xilinx Synthesizer das nicht kann, würde es mich wundern. Leider habe ich mit Xilinx noch keine Erfahrungen gemacht und kann folglich nicht mehr beitragen.
das Problem ist die Synthese in mehreren Schritten durchs EDK. Es werden nämlich im ersten Schritt Netzlisten synthetisiert für alle Peripheriekomponenten. Hatte das Problem auch bei meiner selbstgebauten perihperiekomponente mit Tristate Ports. Lösen lässt sich das genau so wie es Breti beschrieben hat: Im eigenen Design nur die drei Signale Port_I, Port_O, Port_T verwenden. Alle Port = 'Z' werden im Prinzip durch Port_T <= '1' ersetzt usw. im mpd File das die Peripheriekomponenten beschreibt, müssen dann sowohl die Port_I usw. Signale rein als auch das tatsächliche Port Signal. Und nur das letzte verbindet man dann über die GUI mit einem tatsächlihcen Pin -> fertig. Es gibt auch noch eine Option für das .mpd File das die direkte Verwendung von IO Ports ohne die Aufteilung erlaubt. Wie das heißt müsste man aber erst in der Doku nachschauen. Und bei mir hats leider auch nich funktioniert. Hab mein Design dann umgebaut (ging letztendlich auch sehr schnell) für die 3 Einzelnsignale und dann gings. Einen ähnlihcen Stolperstein gibts übrigens noch wenn man in einer Peripheriekomponente IPCores verwendet. Da muss man dann noch ein Block-Box Definition File schreiben (.bbd), das .xco File in den passenden Ordner legen und irgendwo style auf mixed stellen.
Hallo Matthias und Thomas! Ich danke euch recht herzlich für eure geniale Hilfe. Es hat gleich auf Anhieb geklappt. Ich mach jetzt dann ein Fass auf. Danke nochmals. Tschüss Martin
Hallo Leutz! Dieser Post hän gt hier zwar schon ne Weile ich hoffe dennoch, dass mir von Euch jemand helfen kann. Ich habe genau das selbe Problem mit dem Tristate-Treiber auf einem VirtexII Board. Zu Matthias Post: "Alle Port = 'Z' werden im Prinzip durch Port_T <= '1' ersetzt usw" Ist es nicht so, dass der Tristate Zustand mit Port_T <='0' gesetzt wird. Ich meine Damit der Output für Port_O hochomig wird? Port_T <= '1' legt doch das an Port_O anliegende Signal auf den Bus? Genau mit diesem Problem kämpfe ich gerade. Hat einer von Euch ne Antwort??? Da Xilinx aus einem Tri-State eh eine M ultiplexer Lösung macht, habe ich schon überlegt den Bidirektionalen Bus selber als Mux zu coden. Hat jemand von Euch solch eine Lösung schon einmal in Betracht gezogen? Gruß Sven
Also meiner Meinung nach wird Port_T <= '1' als auf hochohmig setzen interpretiert. Eventuell mal in der Dokumentation der externen Tri State Treiber, die man ja auch direkt instantiieren kann, nachschauen. Bei mir hats jedenfalls so funktioniert, wie ichs oben beschrieben habe.
@Matthias: Die Beschreibung von Dir stimmt. Habs eben testen können. Hochomig mit Port_T <= '1'. Thnx for the answer
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.