Hallo Ihr VHDL-Profis, ich habe ein Problem beim Synthesieren der angefügten VHDL Code. Die genaue Fehlermeldung lautet: Multi-source in Unit <mem_interface> on signal <mem_stall_out_ren> not replaced by logic Sources are: mem_stall_out:Q, mem_stall_out_ren:Q ERROR:Xst:415 - Synthesis failed CPU : 17.87 / 18.51 s | Elapsed : 18.00 / 18.00 s Bitte helft mir, dieses Problem zu beheben, da ich auf dem Schlauch stehe. Besten Dank vorab! Martin
Das Signal mem_stall_out wird von mehreren Prozessen getrieben (zugewiesen). Wenn das synthetisieren würde, dann würden im realen FPGA die Treiber kurzgeschlossen und der Chip eingeschmolzen.
Du darfst jedes Signal nur in einem einzigen Prozess zuweisen. Immer daran denken: "Hardware ist parallel", alle Prozesse werden also immer und gleichzeitig ausgefuehrt!
Hallo Morin, vielen Dank für die schnelle Antwort. Könntest du mir vielleicht sagen, wie ich das verhindern kann? Danke nochmal!
Danke Jan und Morin, ich habe das Problem gelöst und vielen Dank für eure Hilfe. Ihr habt mir weitergeholfen.
ps, als rule-of-thumb sollte im VHDL gelten, dass nur "unresolved" datatypes benutzt werden. das waeren zb. ulogic, std_ulogic_vector etc. Damit prueft der vhdl compiler zur compile zeit, dass ein signal nur eine quelle hat - doppelte treiber werden damit nicht erst zur laufzeit oder dem board gefunden. btw: natuerlich sind resolved types auch ok - aber sollten nur eingesetzt werden, wenn es wirklich etwas zu resolven gibt. tristates, etc. mfg /uwe
> als rule-of-thumb sollte im VHDL gelten, dass nur "unresolved" datatypes > benutzt werden. das waeren zb. ulogic, std_ulogic_vector etc. Damit > prueft der vhdl compiler zur compile zeit, dass ein signal nur eine > quelle hat - doppelte treiber werden damit nicht erst zur laufzeit oder > dem board gefunden. Verstehe nicht ganz, worauf du raus willst: Der Typ war resolved, aber der Fehler wurde zur Compile-Zeit gefunden.
> dass nur "unresolved" datatypes benutzt werden.
Das hilft ausschließlich der Simulation:
die ist schneller, wenn keine Datentypen aufgelöst werden müssen.
Für die Synthese gibt die Verwendung der u... Typen keinen Vorteil.
hi, >Für die Synthese gibt die Verwendung der u... Typen keinen Vorteil. klar, ich sehe zwei vorteile: 1. unresolved ist schneller (ist ein netter nebeneffekt) 2. resolved types werden nur an wenigen stellen benoetigt. im rest des chips sind doppelte treiber nicht das was man braucht. nutzt man nun resolved types fallen doppelte treiber (unerwunschte!) nur in der simulation auf (wenn's denn dann ein 'x' gibt). signals of unresolved types werden vom kompiler zur kompilezeit geprueft, dass keine doppelten treiber auftreten. ich finde, dass der ausschluss von doppelten treibern auf einfache art schon etwas ist. (- ja die synthese wird nicht besser, aber u.U. lassen sich design fehler einfach ausschliessen. die kosten auch zeit) >Verstehe nicht ganz, worauf du raus willst: Der Typ war resolved, aber >der Fehler wurde zur Compile-Zeit gefunden. vhdl kompiler & synthese sind schon unterschiedliche sachen :-) ein vhdl kompiler zur simulation sollte (bzw. muss lt lrm) doppelte treiber von unresolved signals unterbinden. keine ahnung ob das synthesetool dies hier nicht will, oder ob die technologie beschraenkungen hat.) /mfg
@jetztnicht Du irrst Dich. Unresolved signale sind nach der Synthese weder schneller, noch muß der Compiler (der für die Synthese) irgendwelche Treiber anlegen/erzeugen. Deshalb gibt es auch keine doppelten Treiber bei resolved Signalen. Auch deine rule-of-thumb Regel wird in der Praxis nicht angewendet. Alle Welt verwendet std_logic. Der Grund liegt wahrscheinlich daran, dass bei bidirektionalen Bussen zwischen Design und Testbench die resolved Signale einfach gebraucht werden.
@jetztnicht
> 1. unresolved ist schneller (ist ein netter nebeneffekt)
Wobei? Kannst du ein Beispiel liefern?
Es geht um die Synthese. Dass nicht aufgelöste Datentypen in der
Simulation schneller sind, steht außer Frage. Aus diesem Grund werden an
(Hoch-)Schulen gerne (noch) die unresolved Typen verwendet.
In FPGAs und CPLDs gibt es keine bidirektionale Signale - sprich Tristate. Diese sind stehen nur an den IO-Pins (IO-Buffer) zur Verfügung. Deshalb können die auch nicht synthetisiert werden. Deshalb sollten Tristate-Signale nur im Top-Level des Designs als Schnittstelle zur FPGA-Außenwelt auftauchen. In der Testbench sind bidirektionale Signale erlaubt. Meine Empfehlung ist aber die auch nur dort zu verwenden, wo am FPGA später Tristate-IO-Buffer verwendet werden. Ansonsten ulogic möglichst nicht verwenden. Es gibt dafür keinen triftigen Grund warum man die verwenden müsste.
hi, > 1. unresolved ist schneller (ist ein netter nebeneffekt) >Wobei? Kannst du ein Beispiel liefern? habe mich da zweideutig ausgedrueckt: in der synthese kommt natuerlich das gleiche raus. in der simulation ist es evtl schneller :-) (ob das erheblich ist haengt vom design ab, da nur die n-fachen treiber auf resolvte signale zu resolven sind. >Deshalb gibt es auch keine doppelten Treiber bei resolved Signalen. das verstehe ich nicht? resolvte signale (die wirklich resolved werden muessen, wg. mehrfachen treibern) habe nun mal wie modellierst du tristate busse?? N-treiber auf einem signal (N-1)*Z+1*(0|1) mit resolved signalen "kann!" man mehrfache treiber auf ein signal modellieren. sind keine doppelten treiber da, sind ulogic und logic gleich. d.h. um auszuschliessen (und zwar von anfang an) das ich keine doppelten treiber einbaue, nehme ich ulogic. >Auch deine rule-of-thumb Regel wird in der Praxis nicht angewendet. Alle Welt verwendet std_logic. tja, ich jedenfalls will bei einem groesseren asic nicht erst in der synthese feststellen, dass da ein doppelter treiber drin ist. evtl. stellt es ja auch jemand anders fest. >Der Grund liegt wahrscheinlich daran, dass bei bidirektionalen Bussen zwischen Design und Testbench die resolved Signale einfach gebraucht werden. klar dort werden resolved sachen benoetigt - aber eigentlich wirklich NUR dort wo wirklich etwas zu "resolven" ist. >In FPGAs und CPLDs gibt es keine bidirektionale Signale - sprich Tristate. tja im asic geht das (obwohl es nicht gerade die bevorzugt onchip loesung ist). >Ansonsten ulogic möglichst nicht verwenden. Es gibt dafür keinen triftigen Grund warum man die verwenden müsste. doch,nochmal: der wesentliche punkt fuer die benutzung von ulogic ist, dass ich doppelte treiber schon bei der entwicklung ausschliesse (coding+simulation). /mfg
Ich gebe dir recht, std_ulogic würde oft mehr Sinn ergeben. Es hat sich aber nun mal so eingebürgert für fast alles std_logic zu verwenden. Ist unschön, aber kein wirklicher Nachteil, da die Synthesetools doppelte Treiber problemlos erkennen können.
hi,
>Ist unschön, aber kein wirklicher Nachteil, da die Synthesetools doppelte
Treiber problemlos erkennen können.
das "unschoen" wird zum problem schon bei mittleren projekten, wenn
coding/simulation/synthese nicht in einer hand liegt ...
ich jedenfalls moechte nicht jedesmal von der synthese oder -versuchen
wieder zum entry und der re-simulation/re-regression gehen muessen.
iterationen aus diesem grund sind unnoetig, zudem vhdl die mittel bietet
es zu vermeiden
regards
/mfg
Bitte 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.