Problem beim Synthesieren

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.

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.

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

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

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