Forum: FPGA, VHDL & Co. Eine Zahl in Einsen convertieren

Alex schrieb:
> Ich habe es schon gelöst aber ich würde gerne
> wissen ob es eine elegantere Möglichkeit gibt?

> Es geht eher um Platz. Mein FPGA ist schon ziemlich voll und ich
> versuche überall wo es nur geht den Code zu optimieren.

> Kann man das ganze evtl ohne schleifen lösen? Also Resourcen sparender?

Komplett falscher Ansatz - eine FPGA-Optimierung über die 
"Schein-Methode "Elegante VHDL-Programmierung" zu versuchen.

Abgesehen davon, das das Verhältnis zwischen "Elegante Programmierung" 
und "Softwareengineering" so etwas das selbe ist wie zwischen 
"Astrologie" und "Astronomie", beginnt jede Optimierung mit eine 
Aufstellung der verfügbaren Ressourcen auf der einen Seite (welcher 
FPGA-Typ, Auslastungsgrad bezogen auf die einzelnenenSubkomponenten 
(M-Slic, L-Slice,BRAM, FF, IO, DSEP48, ..) auf der einen Seite und den 
Anforderungen/Requirements auf der anderen Seite.

Dann überlegt man kurz mit welchen Grundtypen man die Funktion 
relisieren könnte (NAND, MUX,PROM-LUT) und schaut dann, ob die 
Optimierungstools  aktiviert sind und nicht durch hier unnötige 
constraints (bspw. rst am Shiftregister) be-/verhindert werden. (bspw.: 
https://docs.xilinx.com/v/u/en-US/wp275 )

Anschließend beschreibt man die Funktion vollständig und lässt die tools 
die Arbeit machen. Dann schafft ein Quine–McCluskey aus einer dicken 
Wahrheitstabelle eine schnuckelige kleine Realisierung aus wenigen 
LUT's/CarryChain/MUX7F Primitiven.

Und natürlich kann man statt auf die Details, auch aufs "grosse Ganze" 
schauen. Also hat man das PCB passend zu den "package footprint 
migration path" gebaut, kann ma einfach einen größeren Typ draufsetzen.
Oderman taucht u.U. Teile des Designs während der Laufzeit aus (partial 
Reconfiguration). Oder eben "Doing more by doing less", alles weglassen, 
was man nicht braucht.

Es kommt halt darauf an, die FPGA-Technologie zu kennen und zu 
beherrschen; "schönes Coden in Verilog/VHDL/PupsHDL" ist dabei 
nebensächlich.
Wer auf "elegante VHDL-Programmierung" pocht, impliziert eigentlich, das 
er hinsichtlich FPGA-Realität reichlich ahnungslos ist.

--
Ich geh davon aus, das es egal ist, ob die Konvertierung in 10 
nanosekunden oder einer mikrosekunden abgeschlossen ist und deshalb mit 
einer Realisierung als Shiftregister mitLSB-Eingang auf '1' 
(valid-bytes) und Zählersteuerung (data) ansetzen. Aber nur wenn eine 
Alternative zu Beitrag "Re: Eine Zahl in Einsen convertieren" 
nötig ist.

Frank E. schrieb:

> b) mit gleicher Methodik die führenden Nullen auffüllen

OMG, noch nie was von 'FF-Reset' gehört, das man denkt hier müsse mensch 
die Tasse mit '0'- oder mit '1'-Kaffee "auffüllen" ...

> c) fertig
>
> Keine Schleifen, keine "höhere" Mathematik, im Idealfall nur zwei
> Befehle ...

Es gibt keine Befhle im FPGA, nicht bevor die nicht an FPGA-Entwickler 
implementiert hat.

Frank E. schrieb:
>> OMG, noch nie was von 'FF-Reset' gehört, das man denkt hier müsse mensch
>> die Tasse mit '0'- oder mit '1'-Kaffee "auffüllen" ...
>
> Oh, FPGA - dann hast du natürlich recht, hatte ich nicht gelesen,
> dachte, es geht um C, C++, Java, Basic, Python ...
>
> Hab' den Beitrag über "Forum" allgemein gefunden, nicht die Sparte dazu
> wahrgenommen.

Ja, da wäre es besser gewesen, der TO hätte die Beweggründe für seine 
Anfrage (Zitat: "Mein FPGA ist schon ziemlich voll ") in den 
Threadtitel, oder wenigstens in seine Eröffnungsbeitrag beschrieben.

Mglw. hat aber auch das Screendesign von Browser und Forum seinen Anteil 
daran, das hier Themengebiete wild verwechselt werden und der Diskurs 
"quer über die Landschaft galoppiert".

--
Vielleicht sollte man die Forumsanmeldung mit einen kleine 
Einführungskurs (durch-click.schulung) aka "Wie erkenne ich, das mein 
Beitrag deppern platziert und scheisse geschrieben ist" verbinden ...

Val D. schrieb:
> Alex schrieb:
>> ein Signal, dass beispielsweise den Wert 4 enthält.
> Auch, wenn die Aufgabe noch künstlich und völlig nicht nachvollziehbar
> erscheint, ist eine Schleife um die einz. Bits nötig.

Nö. Alternativen:
-manualles loop unrolling im behavourial code
-niederschrift als array (LUT)
-niederschrift als condidional signal assignment
-direkte Instanziierung vom Hardware Componenten (i.e. Block-speicher)
...

Wemm das zuviel V-HDL tipperei ist, kann ja auch einen Coregenerator als 
script (tcl, python) schreiben. Und in einem solchen script wird man die 
benutzung von Schleifenkonstrukten nicht vwemeiden wollen.

Alex schrieb:
> Das weiss ich selber nicht warum ich das denke :D Das ist mir an manchen
> Stellen in der Vergangenheit so aufgefallen, dass Schleifen viel LUT's
> fressen insbesondere wenn man darin noch komplexe if Abfragen hat.

Wenn die Komplexität das hergibt, wird die sich durch die Schleife 
bildende HW eben so umfangreich. Die Verzeigungen sind ja parallel 
implementiert. Wäre die Frage, ob man die Multiplexer restrukturieren 
lassen kann.