Forum: FPGA, VHDL & Co. Problem beim Synthesieren


von VHDL-Rookie (Gast)


Angehängte Dateien:

Lesenswert?

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

von Morin (Gast)


Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

Du darfst jedes Signal nur in einem einzigen Prozess zuweisen. Immer 
daran denken: "Hardware ist parallel", alle Prozesse werden also immer 
und gleichzeitig ausgefuehrt!

von VHDL-Rookie (Gast)


Lesenswert?

Hallo Morin,

vielen Dank für die schnelle Antwort. Könntest du mir vielleicht sagen, 
wie ich das verhindern kann?

Danke nochmal!

von VHDL-Rookie (Gast)


Lesenswert?

Danke Jan und Morin,

ich habe das Problem gelöst und vielen Dank für eure Hilfe. Ihr habt mir 
weitergeholfen.

von jetztnicht (Gast)


Lesenswert?

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

von Morin (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von jetztnicht (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

@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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

@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.

von Matthias G. (mgottke)


Lesenswert?

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.

von jetztnicht (Gast)


Lesenswert?

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

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

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.

von jetztnicht (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.