mikrocontroller.net

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


Autor: Eric O. (eric_007)
Datum:

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

Autor: Jannulis Tembridis (tembridis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei so einem grossen Komparator wäre eine Möglichkeit Komparator und 
Inkrement zu entkoppeln.
if rising_edge(clk_i) then
  if rst_i  = '1' then         
     ....
  else

     if (s_d1 /=  s_d2) then   
       s_do_increment <= '1';
     else
       s_do_increment <= '0';
     end if;

     if (s_do_increment='1') then   
       s_count <=  s_count + 1;
     end if;

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ;)

Autor: Frank V. (scyx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche mal die Ungleichbedingugn durch eine Gleichheitsbedingung zu 
ersetzen.

mfg
 frank

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Eric O. (eric_007)
Datum:

Bewertung
0 lesenswert
nicht 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... ;-)

Autor: iulius (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ;)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.
Lowest7BitsAreEqual  <=  RAM0(s_d1(7 downto 0)   &  s_d2(7 downto 0));
:
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... ;-)

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Eric O. (eric_007)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Eric O. (eric_007)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Lothar, ein netter Trick das ganze.

lg
Matthias

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.