XST: entity/architecture paar

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. ;-)