mikrocontroller.net

Forum: FPGA, VHDL & Co. Problem beim Synthesieren


Autor: VHDL-Rookie (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: VHDL-Rookie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Morin,

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

Danke nochmal!

Autor: VHDL-Rookie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Jan und Morin,

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

Autor: jetztnicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: jetztnicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: jetztnicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: jetztnicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.