Ich habe ein File, in dem zu einer Entity mehrere Modellierungsvarianten in Form mehrerer Architectures enthalten sind. Wie kann ich dem Synthesetool XST von Xilinx beibringen, dass er meinetwegen die 1. Architecture synthetisiert? Im Moment analysiert er alle und synthetisiert aber nur die letzte. Ich würde gerne auswählen um danach vergleichen zu können (Flächenunterschiede usw.) Ich weiss, dass ich ein File schreiben könnte, indem ich die Architectures per component & configuration auswählen kann, das wollte ich mir eigentlich ersparen. Da muss es doch eine Kommandozeilenoption für geben, bei Synopsys gibt es sowas wohl laut meinem Buch hier... T.M. ============================= http://editthis.info/freefpga =============================
Ich löse es jetzt im Moment erstmal mit den Direktiven -- translate off -- translate on Damit kommentiere ich halt immer den Part aus, den ich nicht brauche.
1) Ich kann das Problem mit meinen Erfahrungen bestätigen, XST nimmt die letzte architecture. Eventuell ist das immer so bei der VHDL-Synthese, auch ein anderes synthesetool (synopsy fpga_compiler(?)) reagierte so und warf auch die Info aus das mehrer architectures nicht unterstütz werden. 2) ich habe auch eine configuration getestet, ohne Erfolg. XST hats eingelsen aich aber wie gehabt verhalten. Vielleicht war auch die configuration falsch, hier mal die Reste davon zum selberschrauben: --choose which architecture use by out commenting -- inly one FOR|END For assignment should be active CONFIGURATION cfg_inrange OF in_range IS -- FOR arch_caro_einfach -- END FOR; FOR arch_mux_for_1_equal_comp END FOR; -- FOR arch_mask_unused -- END FOR; END CONFIGURATION cfg_inrange; in_range ist der name der entity. 3) als workaround empfiehlt sich eine combo aus Generic und generate. Dann hast nur eine architecture in dem man den aktiven code auswählen kann. Kurz als skizze: entity Entity_with_several_arch is Generic( G_arch_to_use: integer :=1); .... architecture only_one_arch_workaround of entity_with_several_arch is .... begin if g_arch_to_use = 1 generate --code for variant 1 end generate; if g_arch_to_use = 2 generate --code for varaiant 2 end generate; end architecture; Jetzt ist nur das Generic zu änderen. so kannst du auch alle varianten gleichzeitig testet und dem di entity mehrmals instanzieierst und die generic map für jede instanz entsprechend der gewünschten architecture anpasst. Bis jetzt kenne ich keine XST commandlineoptions um zwischen architectures umzuschalten.
Das mit generate wäre natürlich eine Lösung, nur hab ich dann einen gesamten Synthesereport für alle Architectures nehm ich mal an. Wenn ich aber vergleichen will, würde mir das ni soviel nützen... Generics kann man ja auch nicht per Kommandozeile übergeben, hab zumindestens nichts gefunden. Das wäre ja auch gängig, indem man nur die Architecture instanziiert, die man haben will. Aber danke für den Hinweis :-)
Naja du kannst ja auch mehrmals mit anderen generics synthetisieren dann hast du jeweils einen komplettreport für jeder architecture variante. und IMHO gibt es im synthesereport eine auflistung der erkannten Register,comperator etc für jede Instanz einzeln. Du könntest also mit einer synthese alle Implementierungen vergleichen, da jede seperat gelistet wird. -> Aber das ist nur das Syntheseergebnis, den Platzbedarf und die max. Taktfrequenz würde ich erst nach einem kompletten Paltz und route glauben. Auch zählt der erwähnte synthesereport Grundmacros (n-bit counter|comperator|adder etc.) nicht slices. Da kann sich durch Zusammenfassen von unrelated logic durch map ( LUT und FFin einem slice genutzt auch wenn keine signale von dieser LUT in dieses FF geht) noch einiges verkleineren. Generics in Kommandozeile wurden IMHO von Xilinx offiziell als nicht unterstützt deklariert.
Mhm...danke. Ich werd mal die generic Variante auch mal ausprobieren... Dass die Ergebnisse für Takt nicht entgültig sind, ist klar. Mir geht es aber erstmal nur um die Gatterverzögerungen, die sind ja erstmal statisch. Routing Delays sind natürlich eher mit Vorsicht zu genießen. Ich möchte erstmal nur verschiedene Implementierungen prinzipiell vergleichen. Zum Bleistift verschiedene Komparatoren oder Komparatoren im Vergleich zu Equalcheckers. Da kann man anhand der benutzten LUTs und etweiger Carry Logic schon erkennen, wie eine Funktion erstmal in die Logik des FPGAs abgebildet wird. Und wie man welche Funktion am platzsparendsten / "taktschnellsten" realisiert. Meiner Meinung nach hat der Synthesereport auch die Slices angezeigt, die sich aus der Realisierung in LUTs & Carry Logik ergeben. Ein erkannter Komparator wird ja auch in LUTs abgebildet, die standen dann auch in dem Report wenn ich mich nicht irre. Die Werte für die Ressourcen ergaben insgesamt schon einen Sinn. Das XST ist da ja wohl in der Beziehung mit Übergabe von VHDL-Constraints ziemlich dürftig, ich könnte wetten, mit Leonardo Spectrum im Institut geht das besser :-/ T.M. ============================= http://editthis.info/freefpga =============================
Mir fällt grad noch ne ganz "dirty" Lösung ein: Ich schreib nen Perl Skript, was die Änderungen im VHDL-Code vor jeder Synthese macht. Meinetwegen 3 Architectures, also 3 Durchläufe. Draussen herum eine Foreach Schleife, die den Generic jedes Mal an die jeweilige Architecture anpasst. ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.