Probleme mit shared

[Hans-werner M. (hanswerner)]

Ich habe Probleme damit eine shared variable zu verwenden.
Bitte nicht auf Signale verweisen. Ich muss von verschiedenen Prozessen 
darauf zugreifen. Ist eine Übung zur Umsetzung eines C-Programmes in 
VHDL nach dem Motto eines Kochrezeptes (Man nehme ...). Jede Prozedur 
bzw. Funktion soll auf einen entsprechenden Prozess in VHDL umgesetzt 
werden.
Ist leider nicht ganz einfach. Als nächstes erfolgt dann als weitere 
Übung die Umsetzung von rekursiven Funktionen in VHDL.

-- Elemente und Index des Heaps bzw. des Dualport-RAM's
  subtype element is std_logic_vector (data_width_heap - 1 downto 0);
  subtype index is std_logic_vector (address_width_heap - 1 downto 0);
-- n wird laut Vorlage in C nur in sort gesetzt (Anzahl der Elemente des Heaps)
  -- Alle anderen Prozesse greifen nur lesend auf n zu; deshalb sollte man
  -- ohne Probleme shared verwenden können
  shared variable n : index;

Code ist etwas zu lang zum posten; mehr als 900 Zeilen.

Trotz Definition als shared erhalte ich die allgemein bekannte Meldung:

Multi-source in Unit <heapsort> on signal <n<7>>; this signal is 
connected to multiple drivers.

Wo ist der Denkfehler ?
An irgendwelchen Einstellungen in Xilinx ISE kann es wohl nicht liegen ?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Multi-source in Unit <heapsort> on signal <n<7>>; this signal
> is connected to multiple drivers.
> Wo ist der Denkfehler ?
Der Fehler ist, zu denken, der Fehler wäre in der Definition von n ;-)

Betrifft das nur n(7)?

> Code ist etwas zu lang zum posten; mehr als 900 Zeilen.
Auch wenn das 900 Zeilen sind, als Dateianhang wäre das nicht zu 
umfangreich.

[Hans-werner M. (hanswerner)]

Habe es jetzt mal geändert. Wollte vorher das RAM selber deklarieren.
Jetzt überlasse ich es ISE.
Lustigerweise (Ha, ha) erhalte ich jetzt folgende Fehlermeldung.
Xst:2073 - Unexpected use of shared variable <heap>.
Fragt sich was hier warum "unexpected" ist ?
An n wird momentan nicht rumgemeckert.

-- Elemente und Index des Heaps bzw. des Dualport-RAM's
  subtype element is std_logic_vector (data_width_heap - 1 downto 0);
  subtype index is natural range 0 to address_width_heap - 1;
  type ram is array(index) of element;
  shared variable heap : ram;
  shared variable n : index;

[Hans-werner M. (hanswerner)]

Hier der Dateianhang.
Der Name ist quatsch. Da ist nichts parallel.

[Hans-werner M. (hanswerner)]

Hier noch einmal das Ganze.
Hatte vorher ein paar Zuweisungen an n ausgeklammert, da ich auf der 
Suche nach dem folgenden Fehler war:

line 479: Multi-source on Integers in Concurrent Assignment.

Wahrscheinlich ist n gemeint.
In Zeile 479 steht folgendes: process_heapsort : process (clock_heap)
Es wird also nicht die Zeile mit dem Fehler, sondern nur der Prozess 
angegeben.

Buuuuhhhhhhhhhh, Heul

[Jan M. (mueschel)]

Ehrlich gesagt sehe ich da weder einen Grund, eine Variable zu benutzen, 
und noch weniger eine shared variable.

Das Problem ist wohl, dass nicht sicher ist, dass n nicht in beiden 
Prozessen im gleichen Takt zugewiesen wird. Deine Logik sieht das zwar 
vor, aber solch komplizierte Zusammenhänge erkennt xst wahrscheinlich 
nicht.

PS: Du solltest states aus unterschiedlichen types nicht mit den 
gleichen Namen versehen. xst akzeptiert das zwar, synplify aber 
beispielsweise nicht!

[Hans-werner M. (hanswerner)]

Siehe Beispiel in C. Hier ist der Heap und die Anzahl der Elemente 
Global.
n ist die Anzahl der eingelesenen Elemente.
Hat nichts zu tun mit den Generics.
Was ist die Alternative wenn man versucht die Prozeduren und Funktionen 
in C auf Prozesse in VHDL abzubilden ?
"aber solch komplizierte Zusammenhänge erkennt xst wahrscheinlich
nicht" Willst du hier protected ansprechen ? Der Zugriff auf Shared 
Variablen ist im VHDL93 Standard noch nicht geregelt.
Du meinst also das ISE nicht mit Shared Variablen umgehen kann ?

P.S.: 1. Ich benutze kein Synplify. 2. Das hat nichts mit dem Problem 
der Shared Variablen zu tun. 3. Das kann man immer noch ändern.

[Jan M. (mueschel)]

Solange ein C Programm einen klar strukturierten Ablauf hat, also 
beispielsweise keine Interrupts benutzt, kann man immer völlig ohne 
globale Variablen auskommen. Man kann die ganzen Variablen einfach als 
Parameter übergeben und wieder zurückbekommen.
Genau diesen Ansatz solltest du auch in deiner VHDL-Übersetzung 
verfolgen.

[Andreas S. (andreas) (Admin)]

Hans-werner M. wrote:
> Siehe Beispiel in C. Hier ist der Heap und die Anzahl der Elemente
> Global.
> n ist die Anzahl der eingelesenen Elemente.
> Hat nichts zu tun mit den Generics.
> Was ist die Alternative wenn man versucht die Prozeduren und Funktionen
> in C auf Prozesse in VHDL abzubilden ?

Das geht im Allgemeinen nicht. C ist eine sequentiell ausgeführte 
Programmiersprache, du willst mit VHDL aber Hardware beschreiben.

> "aber solch komplizierte Zusammenhänge erkennt xst wahrscheinlich
> nicht" Willst du hier protected ansprechen ? Der Zugriff auf Shared
> Variablen ist im VHDL93 Standard noch nicht geregelt.
> Du meinst also das ISE nicht mit Shared Variablen umgehen kann ?

Du kannst nicht beliebigen Code in VHDL schreiben und erwarten dass er 
in Hardware umgesetzt werden kann. Du musst dich an bestimmte Strukturen 
halten die der Synthesizer kennt. Siehe 
http://www.mikrocontroller.net/articles/VHDL#VHDL_als_Hardwarebeschreibungssprache. 
ISE kennt shared variables nur für die Beschreibung von Dual Port RAMs. 
Wie das genau aussehen muss steht im XST User Guide (xst.pdf).