www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Sind kleiner-bzw größer-Relationen synthetisierbar?


Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich möchte einen Trigger Programmieren. Ich habe mir die 
Zustandsmaschine so überlegt: (für positive Flanke)

Zustand1:
wenn gemessenes_level>trigger_level dann nächster_zustand=1
wenn gemessenes_level<trigger_level dann nächster_zustand=2

Zustand2:
wenn gemessenes_level<trigger_level dann nächster_zustand=2
wenn gemessenes_level>trigger_level dann 
nächster_zustand=jetzt_wurde_getriggert_zustand

Bevor ich jetzt Anfange das in Code umzusetzen wollte ich mal fragen ob 
etwas wie:

if (level>trigger) begin
   next_state=1;
end else begin
   next_state=1;
end

überhaupt synthetisierbar ist. Wenn nein: gibt es andere Möglichkeiten 
einen trigger zu programmieren?

Viele Grüße,
Christian

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Größer und kleiner sind ohne Probleme synthetisierbar, aber ein größerer 
Wertebereich (je mehr Bits zur Darstellung) macht das ganze langsamer.

Ein Vergleich ist im Prinzip nur eine Subtraktion.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was bedeutet hierbei langsamer? Taktzyklen? Oder wird der maximale Takt 
dann durch höhere Signallaufzeiten eingeschränkt? Ich habe 8-Bit Daten. 
Wie stark wirkt sich das dabei aus?

Ich sollte vielleicht mal dabei sagen, dass das ganze in ein XC9572XL 
CPLD soll. In FPGAs kann man sicher komplexere und andere Dinge 
synthetisieren als in CPLDs?

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibts nen Artikel, in dem bahauptet wird, dass > und < zu vermeiden 
sind und statt dessen auf = geprüft werden soll (zumindest bei Zählern). 
Allerdings wird das Design unter Umständen durch die FSM zur Erzeugung 
der Ausgangssignale wieder aufgebläht. Zumindest bei dem von mir 
eingesetzten Cyclone 2 ist > und < kleiner und auch schneller als = mit 
FSM.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ab einer gewissen Bitbreite für den Vergleich braucht es im CPLD 
zusätzliche Makrozellen für "Zwischenergebnisse", da die Logik mit 
wachsender Bitbreite recht schnell komplex wird. Diese zusätzlichen 
Makrozellen bewirken eine Verzögerung, die das Ganze dann langsamer 
macht. Ausserdem können dadurch kurzzeitig falsche Ergebnisse am Ausgang 
des Vergleichers liegen, was eine getaktete Auswertung unbedingt 
erforderlich macht.
Wie schnell die Logik wächst, kann man feststellen, wenn man den 
Vergleicher "von Hand" implementiert:
-- 1 Bit grösser:

Y <= A and not(B);                                     -- pterm 1

-- 2 Bit grösser:
Y <= (A(1) and not(B(1)))                              -- pterm 1
     or
     (not(A(1)) and not(B(1)) and A(0) and not(B(0)))  -- pterm 2
     or
     (A(1) and B(1) and A(0) and not(B(0)));           -- pterm 3

-- 3 Bit grösser:
Y <= (A(2) and not(B(2)))                              -- pterm 1
     or
     (not(A(2)) and not(B(2)) and A(1) and not(B(1)))  -- pterm 2
     or
     (A(2) and B(2) and A(1) and not(B(1)))            -- pterm 3
     or
     (not(A(2)) and not(B(2)) and not(A(1)) and not(B(1))
     and A(0) and not(B(0)))                           -- pterm 4
     or
     (not(A(2)) and not(B(2)) and A(1) and B(1)
     and A(0) and not(B(0)))                           -- pterm 5
     or
     (A(2) and B(2) and not(A(1)) and not(B(1))
     and A(0) and not(B(0)))                           -- pterm 6
     or
     (A(2) and B(2) and A(1) and B(1)
     and A(0) and not(B(0)))                           -- pterm 7

Man bräuchte also (2^n)-1 Produktterme und das für eine einzige 
Makrozelle.

Gruß Jörg

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, Probieren geht über Studieren. Ich habe es einfach mal versucht zu 
implementieren:

    input [7:0] in1;
    input [7:0] in2;
    output out;
    input clock;


  reg out;
  reg next_out;

always @ (in1,in2) begin
  if (in1>in2) begin
    next_out=1;
  end else begin
    next_out=0;
  end
end

always @ (posedge clock) begin
  out<=next_out;
end

Ergebnis:

3 Makrozellen und 28 P-Terms gebraucht. Soweit in Ordnung, auch wenn es 
mich irritiert, dass es nicht mit Jörgs Formel übereinstimmt.

Was mir allerdings wirklich sorgen macht ist folgendes:
Setup to Clock at the Pad (tSU) 18.300 ns.

Die Schaltung soll nachher mit 50MHz laufen, also ist das schon hart an 
der Grenze. Eigentlich wäre es nicht schlimm wenn der Trigger mit ein 
paar Takten Verzögerung ausgelöst wird (solange die Zahl konstant ist). 
Sollte ich vielleicht pipelinen? Gibt es eine automatisierte Möglichkeit 
oder muss ich das dann komplett von Hand implementieren?
Oder wäre es klüger das Ganze in ein anderes CPLD auszulagern? 
Eigentlich wäre noch genug Platz.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es jetzt so gelöst:

trig_a<=(ein[7:4]>trigger_level[7:4]);
trig_b<=(ein[3:0]>trigger_level[3:0]);
trig_e<=ein[7:4]==trigger_level[7:4];
trigger<=trig_a|(trig_b && trig_e);

Scheint ganz gut zu funktionieren. Für Kritik wäre ich trotzdem dankbar.

Autor: FPGA Spezialist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liegt da noch ein Takt zwsichen dem letzten Vergleich? Dann bekommst Du 
nämlich die erhoffte erhöhte Frequenzreserve.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie ich es verstanden habe ja. Ich meine die sequentiellen 
Zuweisungen werden doch alle gleichzeitig aufgerufen. Dann sollte doch 
die letzte zuweisung als Eingabe haben was noch von der letzten 
Zuweisung in den FFs steht.
Auf jeden fall sagt die Timing-Analyse so das 109MHz möglich sind. Wenn 
ich direkt
trigger<=(ein[7:0]>trigger_level[7:0]);
programmiere meldet die Timing-Analyse was von 42MHz.
Oder habe ich was übersehen?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das in einem getakteten Prozess steht, dann passt das schon so.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK das tut es.
Vielen Dank an alle!

Autor: FPGA Spezialist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am Besten ist, man stopft erstmal alles in einen getakteten Prozess und 
lagert dann die offensichtlich kürstesten Kombinatorischen wieder aus. 
Anders herum kann man alle kombinatorisch schreiben und der Sysmthese 
die Registeroptimierung überlassen.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie mache ich so eine automatische Registeroptimierung? Das muss man 
sicher irgendwo einstellen? Was muss ich beim schreiben des Codes 
beachten, damit es nachher auch wirklich funktioniert? Gilt das für CPLD 
und FPGA oder nur für eins von beiden?

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.