VHDL Error "cannot index the result of a type conversion"

[X. X. (chrissu)]

Hallo,

Ich habe folgenden VHDL Code, Übersetzung mit dem ALTIUM-Compiler...

Soll:
( RCYC_S_FrequValOut(23..0) * 244140 ) / 2^20 )
Division über Indexierung... = Bitshift...


RCYC_STAT_REG_RO und RCYC_S_FrequValOut sind vom Typ (IS ARRAY OF) 
STD_LOGIC_VECTOR()


Mit Altium Designer 14 war dies kein Problem.
Compiliert ohne Fehlermeldung, gerechnet ohne Fehler.

--..AAD14, OK // AD16 Fehlermelddung...
RCYC_STAT_REG_RO(8)(31 DOWNTO 0) <= "0000000000" & (       
    STD_LOGIC_VECTOR(
        (UNSIGNED(RCYC_S_FrequValOut(23 DOWNTO 0)))
         *244140
    )
    (41 DOWNTO 20));

Nun, mit AD16 bekomme ich die Fehlermeldung:
"cannot index the result of a type conversion"
?


Ich habe nun versucht noch den Qualifier für die Länge zu nutzen, aber 
ohne Erfolg... gleiche Fehlermeldung bleibt in AD16:

--AD16 Fehlermeldung...
RCYC_STAT_REG_RO(8)(31 DOWNTO 0) <= "0000000000" & (
    STD_LOGIC_VECTOR(
        resize(
            ((UNSIGNED(RCYC_S_FrequValOut(23 DOWNTO 0)))
            *244140),
            42
            )
        )
        (41 DOWNTO 20));

Mache ich was falsch? Bzw. was kann ich hier noch tun?
Ich sehe eigentlich nichts, warum das nicht indizierbar sein soll...

Besten Dank für Hilfe.

[Klakx (Gast)]

STD_LOGIC_VECTOR(<irgendwas>)(41 DOWNTO 20));

scheint AD16 wohl nicht zu unterstützen, probier mal diese Zeile 
aufzuteilen. z.b.

temp_slv <= STD_LOGIC_VECTOR(<irgendwas>)
RCYC_STAT_REG_RO(8)(31 DOWNTO 0) <= temp_slv(41 DOWNTO 20);

[X. X. (chrissu)]

Hallo,

Ja, mit Aufteilung funktioniert es schon...
Auch ohne das "resize" wieder... Sehe ich auch nicht für nötig an.

Aber trotzdem sollte mein ursprüngliches Konstrukt doch konformes VHDL 
sein, und entsprechend auch vom Compiler unterstützt werden... Oder?

Ich habe mal noch einen AD-Support-Case eröffnet...

Weil ich habe dass an ca. 30 weiteren Stellen so...

Zur Info:
Fehler tritt schon beim Wechsel von AD14->AD15 (nicht AD16) auf.

[Duke Scarring (Gast)]

Chriss X. schrieb:
> Aber trotzdem sollte mein ursprüngliches Konstrukt doch konformes VHDL
> sein, und entsprechend auch vom Compiler unterstützt werden... Oder?
Willkommen in der wunderbaren Welt der Realität...

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

Chriss X. schrieb:
> Aber trotzdem sollte mein ursprüngliches Konstrukt doch konformes VHDL
> sein, und entsprechend auch vom Compiler unterstützt werden... Oder?
VHDL "kann" viel mehr als der Synthesizer. Was der Synthesizer/Compiler 
vom defnierten Sprachumfang tatsächlich umsetzen kann, das steht in 
seinem Handbuch.

Denn die Synthese scheitert ja schon an allereinfachsten Konstrukten. 
Nicht mal sowas Simples bekommt sie ins FPGA:
blinker <= not blinker after 500 ms;

Oder sowas hier:
http://www.lothar-miller.de/s9y/archives/79-use_new_parser-YES.html

> Zur Info:
> Fehler tritt schon beim Wechsel von AD14->AD15 (nicht AD16) auf.
Ich kenne auch 2 Synthesizer, die das nicht können...

> Ich habe mal noch einen AD-Support-Case eröffnet...
Lass hören, was rauskommt... ;-)

[X. X. (chrissu)]

Ja, das ist mir so schon klar, dass der Sprachumfang größer ist, als der 
Synthesizer/Compiler kann...

Aber es ging ja mal, mit einer früheren Version des Compilers... und 
jetzt nicht mehr...

Hat jemand noch vielleicht noch eine andere Idee für den indizerten 
Cast, als hierzu eine Hilsvariable(Hilfssignal :-)) zu nutzen?

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

Chriss X. schrieb:
> Hat jemand noch vielleicht noch eine andere Idee für den indizerten
> Cast, als hierzu eine Hilsvariable(Hilfssignal :-)) zu nutzen?
Wie gesagt: bisher konnte das keiner meiner Synthesizer, ich habe mich 
mit der "Zwischensignal" Lösung abgefunden...  :-/

Du könntest evtl. eine Funktion schreiben und der den Indexbereich 
mitgeben.

[X. X. (chrissu)]

Oder ich könnte natürlich die Division vor dem Cast ausschreiben 
(/2^20)... anstatt die Indizierung...

Und hoffen dass der Compiler schlau genug ist, und nicht wirklich 
dividiert...

[Duke Scarring (Gast)]

Chriss X. schrieb:
> Und hoffen dass der Compiler schlau genug ist, und nicht wirklich
> dividiert...
Bei den üblichen Verdächtigen wird die Division mit 2^n wie erwartet 
durch abschneiden optimiert.

Duke