Obwohl die Variable "Index" also offensichtlich niemals größer werden
kann als "ArrSize - 1" und damit immer innerhalb meines Arrays liegt,
haut mir die Synthese folgenden Fehler raus:
ERROR:Xst:1535 - Index value is not in Range of array.
Warum tut sie das? Gibt es dafür einen plausiblen Grund? Wenn nicht,
kann ich diese Fehlermeldung irgendwie ignorieren? Wie stelle ich das
ein?
Die Simulation läuft natürlich einwandfrei.
Grüße
Steffen
> Warum tut sie das?
Weil es schwer bis (im allgemeinen) unmöglich ist, solche Eigenschaften
per Codeanalyse rauszufinden, siehe Halteproblem. Deine Beschreibung
sieht zwar offensichtlich aus, aber das könnte man beliebig
verkomplizieren. Wo zieht man dann die Grenze der korrekten Erkennung?
Du solltes deinen Index einfach als Integerrange mit der passenden
Arraygrösse definieren. Dann darf aber auch kein Wert darüber hinaus
zugewiesen werden, weil sonst die Simulation einen Fehler wirft. D.h.
der Code muss evtl. etwas umgeschrieben werden.
BTW: Wenn du alle Regeln eingehalten hast, dass xst da ein RAM erkennen
kann ist das gut. Ansonsten werden solche Konstrukte mit grösserem
Indexumfang ziemlich dick und lahm.
Steffen Hausinger schrieb:> Warum tut sie das?
Das sieht man an den geposteten Zeilen nicht.
> Gibt es dafür einen plausiblen Grund?
Vermutlich ja, aber das sieht man an den geposteten Zeilen nicht.
Denn diese Zeilen sind offenbar aus einem Prozess, und da fehlt jetzt
noch das ganze drumrum. Insbesondere mit Variablen die auf dem Prozess
wieder ein Rückwirkung haben.
Ich würde vermuten, du weißt nicht wirklich, was du hier gerade machst.
Denn dieser Programmierstil sieht mir sehr nach Softwareentwicklung und
der entsprechenden Denkweise aus. Für VHDL mußt du in Hardware denken
und diese in VHDL beschreiben...
Ja, da ist noch eine Menge drumherum. Aber der wesentliche Punkt ist
doch folgender:
Obwohl ich unmittelbar vor der Array-Abfrage in der While-Loop den Index
überprüfe, sagt mir die Synthese, dass er ungültig sei. Von daher ist
das ganze Drumherum doch völlig egal! Selbst wenn der Index undefiniert
sein sollte - in der if-Überprüfung stelle ich sicher, dass er gültig
wird!
Lothar Miller schrieb:> Ich würde vermuten, du weißt nicht wirklich, was du hier gerade machst.> Denn dieser Programmierstil sieht mir sehr nach Softwareentwicklung und> der entsprechenden Denkweise aus. Für VHDL mußt du in Hardware denken> und diese in VHDL beschreiben...
So ist das, wenn man aus der Software-Ecke kommt ;-) Nur - ich bekomme
von meiner Protokollschnittstelle mehrere Daten. Diese muss ich zu einem
bestimmten Event beantworten. Dazu muss ich die Daten durchsuchen. Wie,
wenn nicht in einer While-Loop, soll ich die Suche anstellen?
Georg A, schrieb:> Du solltes deinen Index einfach als Integerrange mit der passenden> Arraygrösse definieren. Dann darf aber auch kein Wert darüber hinaus> zugewiesen werden, weil sonst die Simulation einen Fehler wirft. D.h.> der Code muss evtl. etwas umgeschrieben werden.
Das habe ich eben ausprobiert. Leider ändert es nichts an dem Verhalten.
Die Fehlermeldung erscheint weiterhin :-(
Georg A, schrieb:> Wo zieht man dann die Grenze der korrekten Erkennung?
Wenn ISE das nicht beurteilen kann, dann soll es mir meinetwegen eine
Warnung ausspucken, aber nicht mit einem Fehler abbrechen. Denn wenn
meine Betrachtung richtig ist, und davon gehe ich jetzt einmal aus,
blockiert mich jetzt eine unnütze Fehlermeldung!
Lothar Miller schrieb:> Denn diese Zeilen sind offenbar aus einem Prozess, und da fehlt jetzt> noch das ganze drumrum.
Den würde ich gerne posten, nur ist er etwas umfangreicher. Ist das ok?
Grüße
Steffen
> Dazu muss ich die Daten durchsuchen. Wie, wenn nicht in einer> While-Loop, soll ich die Suche anstellen?
Jetzt hast du dich aber fett als SWler geoutet ;) while-loops mit nicht
konstanten Abbruchbedingungen sind grundsätzlich nicht synthetisierbar.
Deine ist so eine, weil da der nicht vorhersehbare Inhalt des Arrays
auftaucht.
Der Grund entgeht SWlern gerne: Das while steckt in einem Prozess, der
mit einem Event getriggert wird, zB. einer Taktflanke. D.h. du forderst
also, dass die gesamte while-Schleife mit unvorhersehbaren Durchläufen
IN EINEM TAKT ausgeführt wird.
Entweder machst du eine for-loop mit festem Index-Bereich, darfst dich
aber dann nicht wundern, wenn das bei >10 so langsam deinen Chip
sprengt.
Oder du machst das Durchsuchen mit einer Art Statemachine, die jeden
Takt einen Index weiter geht. So wie es eine normale CPU ja auch auch
aus einen analogen C-Konstrukt deiner Schleifer ausführen würde.
Georg A, schrieb:> while-loops mit nicht> konstanten Abbruchbedingungen sind grundsätzlich nicht synthetisierbar.> Deine ist so eine, weil da der nicht vorhersehbare Inhalt des Arrays> auftaucht.
Ok, das habe ich nicht gewusst. Deine Begründung, dass mehrere
Schleifendurchläufe nicht innerhalb eines einzigen Takts funktionieren
können, ist mir dabei schon klar. Ich bin aber davon ausgegangen, dass
er die Suche parallel aufbaut.
Wozu gibt es denn sonst überhaupt While-Loops? Man könnte sich einfach
auf For-Schleifen beschränken. Bei denen es übrigens auch wiederum ein
"exit"-Statement gibt. Ist das alles nur für die Simulation?
Georg A, schrieb:> Jetzt hast du dich aber fett als SWler geoutet ;)
So isses ;-) (Steht aber auch schon weiter oben.) Das ist ja auch erst
der Grund, weshalb ich mit VHDL andauernd in Schwierigkeiten reinlaufe.
> Ich bin aber davon ausgegangen, dass er die Suche parallel aufbaut.
Jaja, genau das macht for, weil man da zur Synthesezeit durch den
konstanten Bereich weiss, wieviele Berechnungen parallel sein müssen.
Bei while ist das aber im Allgemeinen unbekannt und sich selbst
"on-demand" erzeugende HW gibts noch nicht.
> Wozu gibt es denn sonst überhaupt While-Loops?VHDL ist vom Design her zunächst eine Beschreibungssprache, das DoD
wollte von den Zulieferern einfach nur eine formalisierte Beschreibung
der Vorgänge in der HW statt Prosa/Gekritzel. Da will man alle
Annehmlichkeiten einer Hochsprache haben. Gibt ja auch Pointer, File-IO,
etc. Mit dem pck_fio-Package gibt es sogar ein printf-Äquivalent. Den
Kram kann man wunderbar in der Testbench oder einem ersten Modell einer
HW-Beschreibung hernehmen.
Für die Synthese gibt es aber nur ein Subset. Es gibt zwar auch
Behavioral Compiler, die sich bemühen, mehr zu verstehen. Das Ergebnis
ist dann aber meistens auch "bemüht" und nicht wirklich produktiv
nutzbar. Den erhofften Durchbruch haben die jedenfalls trotz viel Hype
nicht geschafft. Der Turing lässt grüssen...
Ich vermute, dass xst irgendwie versucht, die while-Schleife aufzulösen
(wenn der Fehler überhaupt in der Zeile ist...) und dann auf die Nase
fällt. Xilinx hat schon immer versucht, mit dem xst mehr Intelligenz als
die anderen Synthese-Tools in die Erkennung von so Konstrukten zu
stecken. Wenn man z.B. alles richtig beschreibt (siehe xst-Guide),
können prinzipiell mit Index-Zugriffen auch die HW-RAMs im Chip genutzt
werden. Nur eine falsche Bedingung (zB. expliziter Reset des Inhalts)
und es geht nicht mehr...
> weshalb ich mit VHDL andauernd in Schwierigkeiten reinlaufe.
Gibt sich. Denk einfach in Takten und einzelnen kleinen Operationen. Bei
Schleifen läuft es fast immer auf eine Art von Statemachine raus, selbst
wenn der Zustand einfach nur der Schleifenindex ist. Jede
Zustandsweiterschaltung geht dann nur mit dem allgegenwärtigen Takt.
Hallo Georg,
ja, ich verstehe, was Du schreibst. Ich bin mit meiner While-Loop eh
schon in einer StateMachine, die werde ich jetzt erweitern, damit er pro
Takt nur einen Vergleich machen muss und im nächsten dann den Index
verschiebt.
Allerdings hätte ich mir von ISE erhofft, dass er mir Probleme bei der
Synthese meldet. Und nicht erzählt, der Index-Wert sei ausserhalb seiner
Gültigkeit. Das lässt sich dann wohl auf den Versuch zurückführen, dass
ISE trotz allem eine Synthese versucht.
Vielen Dank für Deine ausführliche Antwort! Jetzt komme ich wieder
weiter :-)
Grüße
Steffen
Lothar Miller schrieb:> Vergiss sowohl das eine (while) wie auch das andere (for)> VHDL-Syntaxelement für das erste halbe VHDL-Jahr gleich mal komplett.
Das halbe Jahr ist jetzt ungefähr rum und ich habe lediglich einmal eine
for-Schleife benutzt. Später habe ich sie dann aber doch wieder
rausgenommen. Jetzt verwende ich sie einmal und bekomme gleich Probleme
- aufgehoben ist eben nicht aufgeschoben ;-)
Ich habe meine Aufgabe jetzt innerhalb der schon vorher vorhandenen
State-Machine gelöst. Das ging sehr einfach und sehr sauber mit einer
if-else-Abfrage. Im if-Zweig (Suchergebnis negativ) wiederholt er den
Schritt erneut und im else-Zweig (Suchergebnis positiv) führt er meine
Funktion aus und wechselt in den nächsten Schritt.
Nochmals Danke für Eure Hilfe!
Steffen