"Höchstes" Bit finden

[Student (Gast)]

Hi,

ich mache gerade die zweiten Schritte in VHDL.

Ich versuche ein synthetisierbares Modul (für einen FPGA) zu basteln 
welches aus aus einem 64-Bit Wort die höchste besetzte Stelle ermittelt. 
Jetzt kann ich das natürlich mit einem floor(ld(X)) Algorithmus machen, 
oder ich gehe das ganze rein kombinatorisch an:

if ( x(63) = '1') then
  y <= 63;
elsif( x(62) ='1') then
  y <= 62;
...

Als Anfänger stellt sich mir jetzt die Frage: ist so eine lange Kette in 
der Realität noch sinnvoll? Ich kann mir natürlich denken, dass es von 
der Taktung und dem FPGA Modell abhängt. Was mich interessiert wäre, ob 
es so eine Art praktischen Richtwert gibt, ab wann man sich darüber 
Gedanken machen sollte, das Problem in mehreren Zyklen zu lösen. Oder 
reicht es, wenn der Logik-Simulator sein OK gibt? Habe leider weder 
Erfahrungswerte damit, noch die Hardware um es zu testen.

[Falk B. (falk)]

@  Student (Gast)

>Ich versuche ein synthetisierbares Modul (für einen FPGA) zu basteln
>welches aus aus einem 64-Bit Wort die höchste besetzte Stelle ermittelt.

Priority Encoder.

>if ( x(63) = '1') then
>  y <= 63;
>elsif( x(62) ='1') then
>  y <= 62;

>Als Anfänger stellt sich mir jetzt die Frage: ist so eine lange Kette in
>der Realität noch sinnvoll?

Nein. Warum fragst du nicht das Bit direkt ab? Lässt sich recht einfach 
mit ne Schleife hinschreiben. Und dürfte deutlich besser und kleiner 
synthetisierbar sein.

>der Taktung und dem FPGA Modell abhängt. Was mich interessiert wäre, ob
>es so eine Art praktischen Richtwert gibt, ab wann man sich darüber
>Gedanken machen sollte, das Problem in mehreren Zyklen zu lösen.

Wenn du deine gewünschte Taktfrequenz nicht mehr erreichst.

> Oder
>reicht es, wenn der Logik-Simulator sein OK gibt?

Jain.

>Habe leider weder
>Erfahrungswerte damit, noch die Hardware um es zu testen.

Brauchst du nicht, deine Tools spucken dir die mögliche Taktfrequenz bei 
sauberen synchronen Designs aus.

MFg
Falk

[Student (Gast)]

Ach ja, y wird natürlich im Anschluss synchron weiter verarbeitet. Der 
Punkt ist also: reicht bekomme ich das Signal zuverlässig in einem Takt 
durch die ganzen Gatter? Und reicht das Modell mit den Delta-Zyklen um 
die Frage mit dem Simulator zu beantworten?

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

Student schrieb:
> bekomme ich das Signal zuverlässig in einem Takt durch die ganzen Gatter?
Ja, klappt problemlos.
Du musst nur den Takt ausreichend langsam machen...

> Oder reicht es, wenn der Logik-Simulator sein OK gibt?
Der Simulator wird dir keine Angabe zur Hardware machen. Der weiß ja gar 
nichts davon!

Ich mach das so:
http://www.lothar-miller.de/s9y/archives/55-Finde-das-MSB.html

> Als Anfänger stellt sich mir jetzt die Frage: ist so eine lange Kette
> in der Realität noch sinnvoll?
Du kannst auch 2 Flipflops dahinterschalten und "Register-Balancing" 
anknipsen, dann wird das Design zwar nicht schneller, du kannst es aber 
höher takten...
Aber auch ein Multiple Clock Constraint, das angibt: "dieser Pfad darf 3 
Takte brauchen", hilft evtl. weiter.

[Student (Gast)]

So herum wird natürlich ein Schuh daraus! Alles schon mal in der 
Vorlesung gehört, aber wenn man dann davor steht weiß man nichts mehr. 
;-) Vielen Dank für die Auffrischung!

Der Link hat mir auch weiter geholfen. Aber was meinst du mit 
"Register-Balancing"? (Google gibt nicht viel her?)

Ich denke ich werde das ganze Problem mal auf mehrere Takte aufteilen, 
dann kann ich ja praktisch ein Optimum suchen zwischen Anzahl der Takte 
und Länge. Außerdem wird es im Schnitt weniger Zeit benötigen als beim 
Multiple Clock Constraint.

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

Student schrieb:
> Aber was meinst du mit "Register-Balancing"?
http://www.google.de/search?q=xilinx+register+balancing
Gleich der erste gefundene Beitrag zeigt eigentlich alles:
http://www.xilinx.com/support/answers/40089.htm

> Außerdem wird es im Schnitt weniger Zeit benötigen als beim
> Multiple Clock Constraint.
Die Berechnung wird durch das Einfügen von Flipflops langsamer, weil 
ja für jedes Flipflop noch die zusätzlichen tsu und th eingehalten 
werden müssen. Aber: das Design kann schneller getaktet werden.

Häh? Langsamer und schneller gleichzeitig?

Richtig: schneller wird das ganze Design, weil weniger Kombinatorik 
zwischen 2 Flipflops sitzt. Und langsamer wird die Berechnung, weil 
mehrere Takte zur Berechnung nötig sind.

Ein globaler Gewinn an Geschwindigkeit (das Design) wird durch Abstriche 
von lokalen Teilen (die einzelne Berechnung) erreicht.

[Krisu (Gast)]

Warum machst Du das nicht Mehrstufig?

64:16:4:1 wie es üblich ist?

Sind 21 Entscheider, klein schnell kompakt

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

Krisu schrieb:
> Warum machst Du das nicht Mehrstufig?
> 64:16:4:1 wie es üblich ist?
> Sind 21 Entscheider, klein schnell kompakt
Zeig mal ...

Insbesondere interessiert mich, wie dann mit 1 Bit die Position des 
MSB angegeben wird.