Forum: FPGA, VHDL & Co. Comparator, /=, loop, XOR etc Was für Kenner und Könner!


von Eric O. (eric_007)


Lesenswert?

Rahmenbedingung:
device: Virtex-6
clk: 200MHz
s_d1 und s_d2 [63 downto 0]
s_count[31 downto 0]
1
if rising_edge(clk_i) then
2
  if rst_i  = '1' then         
3
     ....
4
  else
5
     if  s_d1 /=  s_d2 then   
6
       s_count <=  s_count + 1;
7
     end if;
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

von Jannulis T. (tembridis)


Lesenswert?

Bei so einem grossen Komparator wäre eine Möglichkeit Komparator und 
Inkrement zu entkoppeln.
1
if rising_edge(clk_i) then
2
  if rst_i  = '1' then         
3
     ....
4
  else
5
6
     if (s_d1 /=  s_d2) then   
7
       s_do_increment <= '1';
8
     else
9
       s_do_increment <= '0';
10
     end if;
11
12
     if (s_do_increment='1') then   
13
       s_count <=  s_count + 1;
14
     end if;

von Morin (Gast)


Lesenswert?

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

von Frank V. (scyx)


Lesenswert?

Versuche mal die Ungleichbedingugn durch eine Gleichheitsbedingung zu 
ersetzen.

mfg
 frank

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Eric O. (eric_007)


Lesenswert?

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

von iulius (Gast)


Lesenswert?

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.

von Georg A. (Gast)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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.
1
Lowest7BitsAreEqual  <=  RAM0(s_d1(7 downto 0)   &  s_d2(7 downto 0));
2
:
3
Highest7BitsAreEqual <=  RAM7(s_d1(63 downto 56) &  s_d2(63 downto 56));
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... ;-)

von Jan M. (mueschel)


Lesenswert?

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.

von Eric O. (eric_007)


Lesenswert?

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

von Eric O. (eric_007)


Lesenswert?

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!

von Matthias (Gast)


Lesenswert?

Danke Lothar, ein netter Trick das ganze.

lg
Matthias

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.