Comparator, /=, loop, XOR etc Was für Kenner und Könner!

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;

Versuche mal die Ungleichbedingugn durch eine Gleichheitsbedingung zu 
ersetzen.

mfg
 frank

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

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

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!