Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
nach den letzten Paar Änderungen (eine FIFO mehr) in meiner VI ist die Kompilierzeit von einigen 10 Minuten gleich auf über eine Stunde explodiert. Zusätzlich gibt es jetzt einen Fehler beim Mappen.
Ich habe ein Schieberegister mit einem Integer. Abhängig von seinem aktuellen Wert, werden gewisse Code-Blöcke durchgeführt.
Es steht quasi fest, dass diese Blöcke nacheinander ausgeführt werden, aber es sollen einstellbare viele Leertakte dazwischen liegen können.
Habt ihr eine Idee, wie ich das optimieren kann? Oder sind 2 FIFOS sowieso vielzuviel?
Ich habe die FPGA PCI-7813R.
Viele Grüße,
Robert
Fehler beim Kompilieren:
ERROR:Pack:18 - The design is too large for the given device and package.
Please check the Design Summary section to see which resource requirement for
your design exceeds the resources available in the device.
If the slice count exceeds device resources you might try to disable register
ordering (-r). Also if your design contains AREA_GROUPs, you may be able to
improve density by adding COMPRESSION to your AREA_GROUPs if you haven't done
so already.
NOTE: An NCD file will still be generated to allow you to examine the mapped
design. This file is intended for evaluation use only, and will not process
successfully through PAR.
This mapped NCD file can be used to evaluate how the design's logic has been
mapped into FPGA logic resources. It can also be used to analyze
preliminary, logic-level (pre-route) timing with one of the Xilinx static
timing analysis tools (TRCE or Timing Analyzer).
Design Summary:
Number of errors: 1
Number of warnings: 152
Logic Utilization:
Number of Slice Flip Flops: 10,383 out of 28,672 36%
Number of 4 input LUTs: 26,914 out of 28,672 93%
Logic Distribution:
Number of occupied Slices: 79,538 out of 14,336 554% (OVERMAPPED)
Number of Slices containing only related logic: 76,374 out of 79,538 96%
Number of Slices containing unrelated logic: 3,164 out of 79,538 3%
*See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs: 158,127 out of 28,672 551% (OVERMAPPED)
Number used as logic: 26,914
Number used as a route-thru: 137
Number used for Dual Port RAMs: 131,072
(Two LUTs used per Dual Port RAM)
Number used as Shift registers: 4
Number of bonded IOBs: 94 out of 484 19%
IOB Flip Flops: 53
Number of Block RAMs: 32 out of 96 33%
Number of GCLKs: 2 out of 16 12%
Total equivalent gate count for design: 19,295,483
Additional JTAG gate count for IOBs: 4,512
Peak Memory Usage: 2027 MB
Hi Robert
LV 8.6.1 habe ich nicht mehr auf dem Rechner. Ich habe mir das VI mal in LV 2011 angesehen. Es fehlen einige SubVI's. Ich kann aber folgende Hinweise geben:
FIFO: Wie groß ist der FIFO Buffer? Kann er reduziert werden?
Int->Booelan-Array: Du solltest hier besser die boolschen Opratoren (Bit-Logik auf den Interger) anwenden als das Boolsche Array zu indizieren.
U64-Arrays sind echte Resourcen-Fresser. Du kannst die Array-Elemente auch in Block-RAM unterbringen. Die aktuellen Werte kannst Du bei Bedarf via Target->Host DMA zur Ansicht übertragen.
- Da fehlen 2 SubVIs.
- Wozu die ganzen lokalen Variablen? THINK Dataflow! Die beiden Histogramm-Arrays könntest du z.B. als Schieberegister ausführen.
- Braucht es wirklich U64 Arrays?
2 FIFOs sind nicht zuviel, sonst hättest du eine andere Fehlermeldung bekommen.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
(19.12.2011 17:03 )jg schrieb: - Da fehlen 2 SubVIs.
- Wozu die ganzen lokalen Variablen? THINK Dataflow! Die beiden Histogramm-Arrays könntest du z.B. als Schieberegister ausführen.
- Braucht es wirklich U64 Arrays?
2 FIFOs sind nicht zuviel, sonst hättest du eine andere Fehlermeldung bekommen.
Gruß, Jens
Vielen Dank für deine Hilfe!
Was heißt think Dataflow? Sind Schieberegister effizienter? Die Arrays könnte ich wens drauf ankommt, sogar weglassen. Die Zahlen, die darin gehalten sind, skalieren leider exponentiell. Um das abzudecken, habe ich eben U64 gewählt.
Die fehlenden SubVIs hänge ich hier noch an.
Für mich ist immernoch die Frage: Was ist es, dass so massiv Kapazitäten auf dem FPGA verbraucht. Ich verstehe leider nicht mal richtig, wo das Problem ist. Die Fehlermeldung sagt mir da nicht soo viel.
Versuch mal, die ganzen roten Punkte wegzubekommen. Das sind immer implizite Datenkonvertierungen.
Bsp: Dein fpga_mod_u8 VI:
Erst schiebst du eine U32-Eins x Bits nach links, um sie dann mit einem U8 zu verUnd/Odern und dann wieder in eine U8 zu schreiben. Besser gleich alles in U8, der Rest geht dir eh verloren.
Wobei du dir das Verschieben auch ganz sparen kannst. Schließ doch gleich das richtige Bitmuster bei "Position" an.
Also bei 0 ein 0x01, bei 1 ein 0x02, bei 2 ein 0x04, bei 3 ein 0x08 usw. usw.
Das VI fpga_mod_u8 wird, so wie du es eingebaut hast, niemals parallel ausgeführt. Du könntest also auf den Reentrant-Modus bei diesem VI verzichten, das spart Speicher, da es nicht an jeder Stelle eingefügt wird.
Deine FIFOs sind als U16 definiert, die brauchen aber nur U8 sein.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
ich hab mir mal dein VI angeschaut. Einige Zeit habe ich gebraucht, um zu verstehen, was diese "Zufalls-Zahlen-Geschichte" überhaupt soll. Hab dann ein wenig getestet und festgestellt dass die ersten 4 bits eh immer von der FIFO kommen. Also hab ich es ersetzt. Während dessen hab ich noch ein wenig umgeräumt und hier und da etwas vereinfacht, verallgemeinert, damit folgende Anpassungen einfacher sind.
Des Weiteren könnte man hier und da noch weitere SubVI's einbauen, um doppelten Code zu vermeiden, ist aber nicht tragisch hier.
Wäre schön, wenn du dir mal den Quellcode anschaust, ihn vllt sogar testest.
Zu dem Overmapping: Ich denke ein weiterer Grund für das Overmapping war das BitShift mit offenem y-Anschluss. Dadurch weiß der Compiler nicht wie groß das ShiftMuster werden kann und geht vom Worst-Case aus. Dazu kommt, dass dann diese Struktur gleich mehrfach vorhanden war.
Und ich gebe jg recht: müssen es wirklich U64-Variablen sein? Mit U32 kommt man auch schon weit...
Vielen Dank für eure Hilfe. Nachdem ich die Array-Größen verkleinert habe und die Integer verkleinert habe, hat sich die Kompilierzeit von >1h auf 4 Minuten reduziert. Das hat sich echt gelohnt!
@erik.brenncke
Dein Vorschlag kam, als ich mit meinen Anpassungen schon relativ weit war. Ich will aber nochmal zusehen, dass ich deine Vorschläge bei mir einarbeite.
es ist wirklich unfassbar, wie man aus meinem undurchsichtigen, komplizierten FPGA-Programm eine so simple, übersichtige Version machen kann. Ich habe probiert, mein Programm, welches zwischenzeitlich schon weiterentwickelt wurde, nach deiner Herangehensweise anzupassen. Das Auswählen der 4 Integer-Werte (Pool) aus den FIFO-Bits habe ich direkt von dir übernommen. Ebenfalls die Verwendung der Rückkopplung für die Histogramme. Rückkopplung kannte ich bis dahin noch gar nicht.
Jedoch ist dein Programm auch etwas einfacher, weil es eben nicht direkt das gleiche tut.
- Die Sub-VI set_eom_clock (oder so) darf in jedem Takt nur einmal aufgerufen werden. Bei dir gibt es einen Takt, wo es zweimal aufgerufen wird. Da das Sub-VI aber Schreib-Nodes für das FPGA enthält, funktioniert das eben nicht.
- In meiner Version gibt es in zweifacher Ausführung zwei Histogramme. In dem einen Histogramm werden die Daten über eine frei wählbare Anzahl an Zyklen n akkumuliert. Das andere Histogramm hält zu jedem Zeitpunkt (in jedem Zyklus) Daten für n Zyklen als eine Art Cache, der stets aktuell gehalten wird.
Beide Probleme ließen sich aber auch bei deiner Herangehensweise integrieren. Jedoch war es dann nicht mehr so einfach.
Ich kann das VI hier leider nicht hochladen. Wenn Interesse besteht (Erik?), schickt mir doch einfach noch einmal eine VI. Dann kann ich ggfs. eine individuelle Reglung finden.
freut mich, dass du was mit meiner FPGA-Programmierung anfangen konntest! Das es DIR geholfen hat, ist das Wichtigste; dazu ist das Forum ja da.
Kennst du das "Glücksprinzip" ? "Pay it forward", heißt das Motto: Also dank es mir, in dem du 3 anderen hilfst!
/
Pack-Error FPGA zu Klein: Wie optimieren?
