Fazit:
Funktioniert super und tut in der Simulation genau das was ich möchte...
...inklusive Timing Violation bei der Implementierung...
Frage:
Wie bekomme ich das "Teil" schneller?
Wanted: "Ken Chapman" Lösung! ;-)
Danke für alle Denkanstöße und Gruß
Eric
Wenn möglich: Pipeline. Du speichert das Ergebnis des Vergleichs in
einem 1-bit-Register und erledigst das bedingte Hochzählen des Counters
im nächsten Takt. Dadurch hinkt natürlich der Zählerstand immer zurück,
aber das kann man abhängig vom Kontext anderweitig ausgleichen. Deshalb
ist das ganze auch erstmal nur ein Ansatz, keine fertige Lösung ;)
Woher kommen sd_1 und sd_2?
Können die sich tatsächlich in jedem Takt beliebig ändern, oder könntest
du Teile davon quasi langsam(er) vergleichen? Dann hättest du die
Möglichkeit auf einen Multi-Cycle auszuweichen...
Das mit der Trennung von Komparator und Counter werde ich mal
testen...mit dem clk-cycle delay könnte ich leben...
sd_1 kommt vom SRAM-data Breite, wird mit sd_2 verglichen (FPGA interner
Generator, der verschieden Testpattern erzeugt und diese gegen den SRAM
Inhalt vergleicht). Das ganze ist ein HW SRAM Tester...da ich
verschiedene Tespattern habe, kann sich in der Tat in jedem Clock-cycle
das datum ändern...
Ich sammel' jetzt ein paar Ideen und werde das in ein paar Tage testen.
Habe das Thema hier erst einmal zum "grübeln" gepostet um in der Zeit
doku zu machen :-((
Danke... (und macht' ruhig weiter... ;-)
6er Lut - baumstruktur :
3 inputs ram
3 inputs fpga
wenn paarweise ungleich -> 1 output high sonst 1 output low.
gepipelined läuft das ganze in 4 takten durch und so groß ist der
ressourcenverbrauch auch nicht.
Erreichbarer Takt im Virtex 6 wohl um die 400 mhz.
zwar affig für so einen simplen Vergleich, aber schneller(Taktrate)
dürfte es nicht möglich sein.
Weiss jetzt nicht, wie schnell die Blockrams im V6 sind, aber man könnte
mit zwei 36K-Blockrams (laut Datenblatt als 64kx1 "without any
additional logic" kaskadierbar) im DPR-Mode schon mal 16 Bit auf einen
Rutsch vergleichen. D.h. man bräuchte nur 8 BRAMs und ein LUT zum
Zusammenfassen.
288kbit SRAM für einen Vergleich, schon fast spätrömische Dekadenz ;)
Macht mich weise bitte, wie kann ich mit einem Dual Port Block RAM zwei
Werte miteinander vergleichen? Geht mir gerade nicht auf, wie das gehen
soll.
lg
Matthias
> Macht mich weise bitte, wie kann ich mit einem Dual Port Block RAM zwei> Werte miteinander vergleichen? Geht mir gerade nicht auf, wie das gehen> soll.
Als Tipp: untere und obere Adresshälfte...
> schon mal 16 Bit auf einen Rutsch vergleichen.
Wenn die beiden Adressen gleich sind, dann sollte an dieser
(Gesamt-)Adresse eine '1' im Speicher stehen, sonst nur Nullen. Die
64kBit Speicher wären also ziemlich leer, fast alles null, nur 256 von
den 1-en sind gesetzt. Und zwar an den Adressen
x"0000"
x"0101"
x"0202"
x"0303"
:
x"ffff"
Wobei das DPRAM dann wohl eher als ROM ausgeführt werden würde... ;-)
Frank V. schrieb:
> Versuche mal die Ungleichbedingugn durch eine Gleichheitsbedingung zu> ersetzen.
Das wird keinen Unterschied machen. /= und = brauchen genau die gleiche
Menge an Logik. Einzig > und < können (müssen aber nicht) wesentlich
mehr Resourcen verbrauchen.
Das ganze mit einer riesigen Lookup-Tabelle zu erschlagen ist definitiv
auch Overkill.
> sd_1 kommt vom SRAM-data
Ich nehme an, das ist ein interner BRAM? Da haben wir das Problem. Der
Ausgang des Speichers ist recht langsam, ungefähr 2 ns (habe die genaue
Zahl gerade nicht im Kopf) nach der Taktflanke sind die Daten erst da -
damit ist dein Takt aber schon zur Hälfte rum. Abhilfe: BlockRAM mit
Output-Register generieren oder von Hand die Daten zuerst registrieren.
Ein 64bit-Gleichheit und ein 32bit Counter sollten für einen Virtex 6
noch im Bereich des möglichen liegen bei 200 MHz.
Wenn das nicht hilft, zeig uns bitte mal die genaue Meldung aus dem
timing Report, welcher Pfad da genau das Problem verursacht.
Jan M. schrieb:
> Ich nehme an, das ist ein interner BRAM?
...eben nicht. Ich vermute stark dass ich mit dem internen BRAM bei
200MHz und Virtex-6 fein raus wäre.
--> externer SRAM
Gerade eben (obwohl ich doku schreiben sollte...;-) habe ich beim
überprüfen der constraints gesehen, dass ich meine MMCM (ohne viel zu
überlagen) vor ein paar Tagen aufgrund von MAP/PAR-Warnings falsch
umgestellt hatte und dadurch das timing constraint von 200MHz auf 400MHz
hochgezogen wurde - obwohl mein Eingangs-clk constraint ungeändert bei
1/4 clk-Ausgang blieb. Ich hätte bei der Timing-Vialotion wohl zwei
Sekunden länger gucken sollen, dann wär's mir gleich aufgefallen.
However, da mir mein Komparator trotzdem nicht wirklich gefällt (64bit
/= 64bit Vergleich), probiere ich mal eure o.g. Optimierungen aus.
Danke an euch!