Resourcenverbrauch im FPGA

[verilog (Gast)]

Hi,
In einem Register mit der Länge n wird eine Zahl mit der Basis 2 
abgelegt.
Danach wird die eine bitposition ermittelt, welche die 1 beinhaltet. 
Diese wird auf 0 gesetzt und alle anderen kleinerwertigen Bitpositionen 
auf 1 gesetzt.

Also wenn die Zahl z.b. 2^3 ist, dann soll am Ende 7 im Register stehn.

Welcher Ansatz ist im FPGA hinsichtlich Resourcenverbrauch und 
Performance besser?:

z.b. zahl = 2^3;  n= 32;

einfach dekrementieren?
register_n <= 2^3 - 1;


oder mit logik und schiebeoperationen?:
Takt1:  register_n <=  {n{1'b1}};
Takt2:  register_n <=  register_n << 3;
Takt3:  register_n <=  {n{1'b1}} ^ register_n;

[EndiMö (Gast)]

Probier es doch auch aus, das ist doch wahrlich schnell hingeschrieben.

Wobei es auch noch weitere Varianten gibt, bspw. ROM-Feld aus 32 
Vectoren jeweils 32 bit lang. Bei vielen FPGA's hat man solche embeded 
Ressourcen züsätzlich zu den Logihresoeurcen also quasi geschenkt. Oder 
die Logic-Resourcen (LUT's werden zu Speicher umkonfiguriert (Xilinx 
distributed RAM).

Abgesehen davon scheint die Decrementvariante sparsamer gegenüber der 
Shift-Variante.

[J. S. (engineer)]

EndiMö schrieb:
> Abgesehen davon scheint die Decrementvariante sparsamer gegenüber der
> Shift-Variante.

Das hängt davon ab, ob diese Operation, also das Suchen und Setzen 
sequenziell erfolgen darf oder ob man das als pipeline braucht. Die 
beiden Schaltungen sind im direkten Vergleich ja funktionell nicht 100% 
gleichwertig, daher ist die Frage nach einem Resourcenverbrauch ohne 
weitere Randbedingungen nicht vollständig zu beantworten.

[Andi (Gast)]

Beide Ansätze sind falsch.
In Verilog wird der ^ Operator für EXOR Verknüpfung verwendet, und nicht 
zum potenzieren. 2^3 - 1 ergibt also 0.

Ich würde schreiben:
register_n <= (1<<3) - 1;
oder
register_n <=  {3{1'b1}};

aber da das alles Konstanten sind wird die Synthese einfach den 
konstanten Wert 7 generieren und zuweisen.
Anders sieht es aus wenn die Bitposition variable ist, dann lohnt es 
sich verschiedene Wege auszuprobieren. Was am resourcenschonendsten ist, 
hängt auch vom Synthesetool und vom FPGA Aufbau ab.

Andi

[Hermann K. (r2d2)]

Evtl. solltest du dir auch noch überlegen was im Fehlerfall passiert. 
Also was möchtest du als Ausgabe wenn - warum auch immer - nicht 8 
sondern 9 als Input anliegt. Da unterscheiden sich die Methoden dann 
nochmal.

[Vancouver (Gast)]

Die Frage nach "den Ressourcen" ist beim FPGA immer etwas schwammig. Es 
gibt viele verschiedene Typen von Ressourcen, die Frage ist, welche Du 
einsparen willst.

Die Decrementerlösung wird sehr effizient sein, denn Addierer (nicht 
anderes ist ein Dekrementer) sind hochgradig optimiert in den meisten 
FPGA.
Andererseits hast Du eine logische Funktion, die nur eine winzige 
Teilmenge aller möglichen 32Bit-Operanden zulässt und ansonsten 
undefined ist. Da kann bei der Logiksynthese wahrscheinlich massiv 
optimiert werden, sodass noch etwas schlankeres herauskommt als ein 
Addierer. Dazu würde ich das ganze einfach mal als ein Switch-Statement 
mit 33 Branches hinschreiben und schauen, was die Synthese daraus 
zaubert.

Die ROM-Variante wäre auch möglich, allerdings brauchst Du dann einen 
Decoder, der dein 32Bit-Wort erstmal in eine 5Bit-Adresse umrechnet, 
sonst wird der ROM etwas sperrig.

Zusammenfassung: Versuch macht kluch.

[Batzi (Gast)]

Vancouver schrieb:
> Die Decrementerlösung wird sehr effizient sein, denn Addierer (nicht
> anderes ist ein Dekrementer) sind hochgradig optimiert in den meisten
> FPGA.

Sind das hardware-elemente? Meines Wissens sind das auch nut LUTs, die 
entsprechend schlau verschaltet werden. Oder täusche ich mich da?