ich habe folgende Frage. Ich habe ein Signal, dass beispielsweise den Wert 4 enthält. Diesen Wert möchte ich in 4 "Einsen" umwandeln. Also quasi so: 4 ->"00001111". Ich habe es schon gelöst aber ich würde gerne wissen ob es eine elegantere Möglichkeit gibt? Ich zeig euch mal meinen Weg:
valid_bytes soll hier die Anzahl an "Einsen" bekommen die in data als Wert ausgerechnet wurden. data hat immer ein ganzzahliges vielfaches von 8.
Kann man das ganze evtl ohne schleifen lösen? Also Resourcen sparender?
Geschwindigkeit oder Platz?
8 Byte Array und Index wenn es schnell gehen muss.
Es geht eher um Platz. Mein FPGA ist schon ziemlich voll und ich versuche überall wo es nur geht den Code zu optimieren.
Die idee klingt interessant. Ich probiers mal aus danke
Mein FPGA ist schon ziemlich voll und ich versuche überall wo es nur
geht den Code zu optimieren.
Du musst nicht "den Code optimieren", sondern die Logik verkleinern. Aber letztlich wird da in jedem Fall irgendwie ein Multiplexer herauskommen. Sogar die Lösung mit dem RAM ist im Grunde nur ein Multiplexer.
Es sieht aber so aus, als ob es genausoviele Resourcen braucht wie meine
vorherige Lösung.
Kann man im Report nachschauen. Wenn man ein kleines Dreizeiler-Projekt nur mit diesem Codeschnipsel macht, sieht man das recht deutlich.
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.
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 ...
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.
Kann man das ganze evtl ohne schleifen lösen? Also Resourcen sparender?
Wieso braucht diese Lösung viele Ressourcen? Warum nimmst du an, dass
eine Schleife viele Ressourcen braucht?
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.
valid_bytes soll hier die Anzahl an "Einsen" bekommen die in data als
Wert ausgerechnet wurden.
Ich würde das so machen:
1
>process(input)
2
>variablex:std_logic_vector(...);
3
>begin
4
>x:=(others=>'0');
5
>x(to_integer(unsigned(input))):='1';
6
>valid_bytes<=x-1;
7
>endprocess;
8
>
Danke für den Lösungsvorschlag. Das ist auch eine interessante Idee.
Danke auch an alle anderen Beiträge.
Ok Sorry, nächstes mal versuche ich die Überschrift besser zu wählen. :)
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.
Ich würde das so machen:process (input)
variable x : std_logic_vector(...);
begin
x := (others=>'0');
x(to_integer(unsigned(input))) := '1';
valid_bytes <= x-1;
end process;
