|
Anzeige
|
Sinn von "MULT_AND"
Gast
#2744871
Hallo, ich habe hier ein Spartan3-Projekt eines Kollegen, der eine UND-Verknüpfung explizit über "MULT_AND" macht.
Ich konnte keinen speziellen Grund dafür finden. Macht das Sinn? Wäre es nicht sinnvoller, einfach
hinzuschreiben und es der ISE zu überlassen, wie sie das UND in der Hardware abbilden will?
Gast
#2745019
das macht zb bei ASICs sinn 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...
Gast
#2747022
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?
Gast
#2747192
Lange Rede, kurzer Sinn, was steckt hinter der "MULT_AND" component? Darf man hier einsehen? Vielleicht würde das alles erklären!
Gast
#2747889
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
Gast
#2748476
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. Wenn die Toolchain das kapiert. Oder, wenn der Rest vom Slice auch manuell instantiiert ist... 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 >
> 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,
Gast
#2749213
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). Antwort schreiben |
Anzeige
|
