Vielleicht konnte er es nicht anders. Ich hatte da auch mal was in die
Richtung:
Beitrag "Re: Beschreibungsformen VHDL"
Aber vielleicht ist das auch eine ganz trickreiche Sache, die hinter dem
manuell instantiierten AND steckt...
Lothar Miller schrieb:> Aber vielleicht ist das auch eine ganz trickreiche Sache, die hinter dem>> manuell instantiierten AND steckt...
Xilinx nutzt die ausdrücklich Instanziierung eigentlich immer dann, wenn
sie mit dem Coregen, der ISe oder anderen Themen Probleme haben oder
dann, wenn sie gezielt Xilinx-Code erzeugen wollen.
Wenn bei einem AND, welches mittels LUT realisiert ist, ein
Eingang auf Null liegt, kann während einer Änderung des anderen
Eingangs ein 1-Glitch auftreten, weil der sich ändernde Eingang
eine Umschaltung von einer Zeile der Wahrheitstabelle in eine
andere Zeile bewirkt. (Das habe ich nicht gelesen, sondern mir
so überlegt.) Vielleicht geht es um dieses Glitch-Problem?
L. schrieb:> Lange Rede, kurzer Sinn, was steckt hinter der "MULT_AND" component?> Darf man hier einsehen? Vielleicht würde das alles erklären!
Ist ein kleiner Standard-Xilinx-IpCore mit der Funktion "UND", der laut
Anleitung besonders zum Aufbau von Multipliziern geeignet ist, aber auch
allgemein genutzt werden darf:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/spartan3_hdl.pdf
naja, da steht: "The design element is an AND component located within
the slice where the two inputs are shared with the 4-input LUT and the
output drivers into the carry logic."
Es ist also ein Gatter, dessen Ausgang direkt in die Carry Chain geht,
also nicht in das "Interconnect Netzwerk". Somit hat man hier eine
schnellere Verbindung zur nächsten LUT. Die Logik kann dadurch
performanter werden.
L. schrieb:> The design element is an AND component
Ein echtes AND-Gatter ist glitchfrei, im Gegensatz zur
AND-Realisierung mittels LUT, siehe mein Beitrag oben.
Pako schrieb:> Ich konnte keinen speziellen Grund dafür finden.> Macht das Sinn? Wäre es nicht sinnvoller, einfach>
1
>a<=bandc;
2
>
> hinzuschreiben und es der ISE zu überlassen, wie sie das UND in der> Hardware abbilden will?
Die Umsetzung VHDL -> Netzliste macht nicht "die ISE" sondern das
Synthese-tool bspw. XST, Synplify, etc. Eventuell kann Map da noch was
umbauen, das muss aber dann "wichtige Gründe erkennen" aus eine LUT2
durch MUL_AND zu ersetzen.
Der Hauptgrund sind hohe timing-Anforderungen. die über die timing
constraints vermittelt werden. Der Synthese werden oft keine
timing-constraints mitgegeben und klassischerweise arbeit das
synthesetool architecturunabhängig muss also MUL_AND nicht kennen. Dem
Mapper muss gesagt werden das der timing driven arbeiten soll (z.B.
command-line Option) und selbst dann ist nicht garantiert, das er eine
solche standradcell verwendet. Und diese Optimierungen treiben die
Toolchain Zeiten kräftig in die Höhe. Falls also ein Bottleneck im
Logigpfad exestiert kann eine solche Handinstanzierung das timing
problem schneller und reproduzierbar lösen.
Andere Gründe können sein:
-die LUT wird für andere schnelle Logig benötigt (distributed RAM,
FIFO,SR)
-der Router kann ketten von Logik besser verdrahten als "Sterne"
(Xilinx White Paper 274)
MfG,
Josef G. schrieb:> Ein echtes AND-Gatter ist glitchfrei, im Gegensatz zur> AND-Realisierung mittels LUT, siehe mein Beitrag oben.
Antwort von Xilinx auf eine solche Frage:
Good question, often asked:
No glitch, and that behavior is guaranteed by the decoding
structure.
Further, if you change two pins, and you know that the output is
identical for all 4 permutations of these 2 bits, there also is no
glitch.
And you can stretch that to 3 pins, where all 8 permutations must give
identical results to avoid a glitch, although this last one may be an
unrealisticl situation.
I have answered this particular question many times over the past 15
years.
Peter Alfke, Xilinx Applications
http://compgroups.net/comp.arch.fpga/xilinx-lut-behavior-question/463872
Lattice User schrieb:> I have answered this particular question> many times over the past 15 years.
Danke für die sehr interessante Information.
Das Thema hat mich sehr beschäftigt. Merkwürdig, dass Xilinx die
Sache nur in einem Forum behandelt und nicht in der Dokumentation
(jedenfalls habe ich dazu nichts gefunden).