Es wird im Allgemeinen versucht die Flip Flops innerhalb der CLBs zu nutzen, um Speicher abzubilden, und die hängen meist direkt an Taktleitungen.
Richtig.
Nagut, kenn ich halt nicht so wirklich... und wenns richtig erkannt wird. Gut.
Ansonsten hat Thomas wohl das Problem auf den Punkt gebracht, was ich mit mini state machine meinte. das Signal dv wird nie zurückgesetzt oder? Und mit den Taktdomains hat er auch wieder Recht.
Am besten Du simulierst das erst noch mal ordentlich (auf mehreren Ebenen) durch und dann wirst Du den Fehler wohl schon finden.
Das kann ich mir gut vorstellen. Wie hast Du das Problem dann letzlich in den Griff bekommen? Mit etwa sovielen Timing-groups wie insegsamt Signale im Design waren?
Naja, stimmt schon. XST macht da ja auch 'nen FF mit async reset draus. Ich hatte mich nur irgendwie in der Hoffnung getragen, daß XST ausserdem noch ein Timing-constraint erzeugt, daß besagt, daß die Ausgabedaten *vor* doutvalid fertig ein müssen (deshalb habe ich ja "blocking assignments" verwendet). Wenn ich aber das Modul so wie's ist einfach ohne weitere Angaben auf ein Device mappe, dann werden IOB-FlipFlops verwendet, und "doutvalid" ist zufällig etwa mit dem frühesten Datenbussignal fertig. Das ist in diesem Fall irgendsowas bei 4 ns vor dem spätesten, und damit überhaupt nicht, was das doutvalid-Signal ja nun eigentlich bewirken soll.
Für FPGA-interne Benutzung sind natürlich die Laufzeitunterschiede zwischen Signalen seht viel kleiner, aber wenn ich dieses Modul wirklich benutzen wollen würde, ohne für jede vedammte Nutzung intensivst zu simulieren, dann müsste ich wohl, wie Eingangs beschrieben dafür jedesmal neue Timing-constraints tippen.
Ja, richtig, das Modul ist auch bei Überlegungen zum Zusammenschalten von Modulen verschiedener Taktfrequenzen (bzw. sogar mit "taktlosen" Modulen) entstanden. "Taktlos" meint, daß jeder Pipeline-level dem nachfolgenden "bescheid" sagt, sobald er fertig ist, dann wartet, bis er seine Daten abliefern kann, um erst dann mit dem nächsten Datum fortzufahren. Hätte natürlich den Vorteil geringer Latenzzeiten, scheitert nur leider an der Verfügbarkeit genauer delays.
Idee bei diesem Codeschnipsel war, daß eine Datenquelle das sample-signal zu einem beliebigen Zeitpunkt erzeugen sollte, sofern nicht "busy" (äquivalent zu "doutvalid or rst"), während das Zielmodul zu einem beliebigen Zeitpunkt die Daten lesen sollte (sofern doutvalid), um nach Abschluss des Lesevorgangs "rst" zu äussern.
Für den eigentlich gedachten konkreten Einsatzzweck habe ich allerdings nun 'ne andere Lösung gefunden, für die es egal ist, ob die Xilinx-Tools nun "blocking assignments" richtig vollständig interpretieren, oder nicht.
Ich habe mehrfach Teile vorplaziert und fixiert, dann die Automatik angeworfen und geschaut, wo es dieses mal klemmt. Timing Groups helfen wenn man verschiedenen Taktwelten hat, aber nicht, wenn man alle Register in der selben Taktwelt hat und nur tricksen muss ohne Ende, um IO Timing und gew=FCnschten Takt zu maximieren.
64 Bit Ripple Carry ist in vielen Designs dein Taktkiller. Da hilft dann auch kein Fast-Carry-Chain mehr.
so
Google mal nach Carry Look Ahead Adder, Ripple Carry Adder, Carry Skip, Carry Select, Carry Save (und alles wann damit noch hochkommt). Dann weisst du, das es mehr als nur einen Addierer in HW gibt. Dank Fast-Carry-Chain ist zwar der RCA =FCblicherweise die erste Wahl im FPGA, aber es gibt immer noch Gr=FCnde etwas anderes zu w=E4hlen.
*vor*
EIner von uns beiden versteht die "blocking assignments" falsch, nachdem ich nicht so firm in Verilog bin, kann das durchaus auch ich sein :). Aber AFAIK blockt so ein BA nur nachfolgende Operationen mit den selben Signalen. Und asynchrone Timing Anforderungen lassen sich in HDL nicht wirklich so modelieren, das normale Werkzeuge damit klarkommen.
Self timed logic ist etwas, das leider (noch?) nicht von (kommerziellen) Werkzeugen unterst=FCtzt wird. Hier bist du auf Handarbeit angewiesen. =20 bye Thomas
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.