VHDL array mit ISE 13.4

[spartan6 (Gast)]

Hallo zusammen,

ich wundere mich gerade mal wieder über ISE 13.4, bzw. frage ich mich, 
ob ich selbst an dem Problem schuld bin.

Ich brauche ein mehrdimensionales Array, was ich auch mit

type wfs_sum_32 is array (natural range <>,natural range <>) of integer range 0 to 2**31-1;

definieren kann.

Jedoch sehe ich bei der Synthese folgende Meldungen:

    Found 1-bit register for signal <sumData<13><5><20>>.
    Found 1-bit register for signal <sumData<13><5><19>>.
    Found 1-bit register for signal <sumData<13><5><18>>.
    Found 1-bit register for signal <sumData<13><5><17>>.
    Found 1-bit register for signal <sumData<13><5><16>>.
    Found 1-bit register for signal <sumData<13><5><15>>.
    Found 1-bit register for signal <sumData<13><5><14>>.
    Found 1-bit register for signal <sumData<13><5><13>>.
    Found 1-bit register for signal <sumData<13><5><12>>.
    Found 1-bit register for signal <sumData<13><5><11>>.
    Found 1-bit register for signal <sumData<13><5><10>>.

wobei ich das Signal wie folgt definiert habe:

signal sumData : wfs_sum_32(13 downto 0, 13 downto 0);

Eigentlich würde ich erwarten, dass die Synthese 14-bit Register findet.
Kann mir erstens jemand erklären, wodurch das zu stande kommt und ob das 
eigentlich ein Problem ist.

Mir kommt es so vor, dass dadurch die Synthese unheimlich langsam wird.
Von Hand die Signale definieren geht zwar, ist jedoch sehr copy and 
paste lastig, was ich nicht möchte.

Danke.

[spartan6 (Gast)]

nun, eine Lösung habe ich gefunden und zwar wenn ich anstelle von 
integer unsigned verwende, dann bekomme ich die größeren Register und 
die Synthese wird deutlich schneller (Faktor 10 bestimmt!)

Kann das Verhalten jemand mir erläutern?

Danke.

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

spartan6 schrieb:
> Ich brauche ein mehrdimensionales Array
Wie greifst du auf dieses Array zu? Soll das ein RAM sein?

[Theo Termistor (Gast)]

spartan6 schrieb:
> Eigentlich würde ich erwarten, dass die Synthese 14-bit Register findet.

IMHO definierst Du mit

type wfs_sum_32 is array (natural range <>,natural range <>) of integer range 0 to 2**31-1;

und

signal sumData : wfs_sum_32(13 downto 0, 13 downto 0);

 14 Blöcke a 14 Wörter a 31 bit.

also keine 14 bit register.

MfG,

[spartan6 (Gast)]

Ups, da hatte ich mich verschrieben, meinte natürlich 32-bit register.

Mit unsigned kommt das auch bei der Synthese raus, die Implementierung 
läuft gerade noch :(

@Lothar Miller
Ich muss ein Bild in 14x14 Einzelbilder zerteilen und von jedem den 
Schwerpunkt bestimmen. Ich kann das ganze natürlich sparsamer 
realisieren, aber es gibt Gründe wieso ich 14x14 a 32 Bit brauche, die 
projekttechnische Gründe haben.
Also ja eigentlich sollte es ein RAM sein. Geht das effizienter :-) 
bestimmt oder?

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

Ein RAM wäre am effizientesten, allerdings darfst du dann pro Takt immer 
nur auf 1 Element zugreifen (so sind RAMs aufgebaut). Deshalb meine 
Frage nach der Zugriffsweise.

[spartan6 (Gast)]

Hmm, das mit nem bram wäre schon das beste und effizienteste.

Mein Denkproblem dabei ist momentan:

Nehmen wir an, ich habe ein Bild mit 32x32 Pixel und und zerteile das in 
vier gleich große Teilstücke. Dann hätte ein Teilbild 16 Pixel und wenn 
ein Pixel 8 Bit Information hat, würde ich 8+log2(16*16)+log2(32) Bit 
maximal brauchen für den gewichteten Mittelwert in x-Richtung.
Für die normale Summe würde ich 8+log2(16*16) Bit maximal brauchen.

Bekomme ich nun die Pixel Zeile für Zeile, muss ich beim Übergang von 
Pixel 15 auf 16 die Werte ins bram schreiben und bei der zweiten Zeile 
müsste ich sowohl bei Pixel 0 als auch Pixel 16 den alten Wert aus dem 
bram für die weitere Summe zuerst lesen.

Ich müsste also immer sobald ich eine neue Zeile bekomme oder in dem 
Beispiel von Pixel 15 auf 16 komme, das bram an der passenden Stelle 
gelesen haben und diesen in ein temporäres Register schreiben und damit 
die Berechnungen soweit durchführen.
Das könnte klappen ohne den Takt verdoppeln zu müssen :-)

Ist das ein passabler Ansatz oder was würdet ihr hierfür vorschlagen?

[Paebbels (Gast)]

Hallo,

ein alternativer Ansatz zu diesen Arrays könnten geschachtelte 
FOR..GENERATE Blöcke sein.

Meine Erfahrung zeigt das ISE aber meist auch diese Konstrukte recht gut 
versteht, solange man 3 Dinge beachtet:
- den lesenden Zugriffsweg auf die Elemente
- den schreibenden Zugriffsweg auf die Elemente
- das Resetverhalten

Zum Reset:
Wenn du z.B. die Daten nicht im BRAM sondern im LUT-RAM halten möchtest, 
dann darf deine Beschreibung kein Reset enthalten, da LUT-RAMs das nicht 
haben

[Duke Scarring (Gast)]

Paebbels schrieb:
> Zum Reset:
> Wenn du z.B. die Daten nicht im BRAM sondern im LUT-RAM halten möchtest,
> dann darf deine Beschreibung kein Reset enthalten, da LUT-RAMs das nicht
> haben
BRAMs haben auch keinen Reset...

Duke