Erzeugen eines Differenzsignals mit Offset

[Michi (Gast)]

Hallo,
Aus einem ADC kommen über 2 Kanale 2 verschiedene Signale heraus. Der 
Datentyp der beiden Signal ist jeweils

std_logic_vector(7 downto 0)

Bisher war es so, dass einfach 1 Kanal zur Weiterverarbeitung 
herausgeschrieben worden ist.
Nun möchte ich aber stattdessen das Differenzsignal aus den beiden 
Kanälen ausgeben. Um auf ein Vorzeichen zu verzichten, möchte ich auf 
den Wert noch ein Offset aufaddieren.

Da diese 1-Byte-Vektoren aber vorzeichenlos sind, und ich nicht 
garantieren kann, dass einer der Kanäle immer grösser ist als der 
andere, bräuchte ich eigentlich eine Unterscheidung welcher wert grösser 
ist.
Leider lässt sich das aber ja nicht parallel realisieren. Gibt es eine 
Möglichkeit das irgendwie anders zu machen?
Ziel wäre also

if ch1 >= ch2 then
 result <= (ch1-ch2)+offset; 
else
 result <= (ch2-ch1)+offset;
end if

irgendwie parallel zu realisieren.

Danke schonmal.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michi schrieb:
> Ziel wäre also
> if ch1 >= ch2 then
>  result <= (ch1-ch2)+offset;
> else
>  result <= (ch2-ch1)+offset;
> end if
>
> irgendwie parallel zu realisieren.
Was soll da nicht gehen? Das sind 2 Rechenwerke und ein Mux. Das geht 
GARANTIERT. Dein Problem liegt woanders. Ich tippe auf eine fehlende 
Typkonvertierung...

[Michi (Gast)]

aber ich bekomme immer

parse error, unexpected IF

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michi schrieb:
> parse error, unexpected IF
Das if geht nur in einem Prozess.

Wenn du es Concurrent machen willst, dann brauchst du sowas:

result <= (ch1-ch2)+offset when (ch1>=ch2) else (ch2-ch1)+offset;

[Michi (Gast)]

Lothar Miller schrieb:
> Wenn du es Concurrent machen willst, dann brauchst du sowas:result

(ch1-ch2)+offset when (ch1>=ch2) else (ch2-ch1)+offset;

Danke erstmal, das hat mir schon sehr weitergeholfen. Jetzt hab ich noch 
eine Frage.. Bei der Verwendung dieser Zeile im Code treten sporadisch 
Werte auf, die kleiner als offset sind. Hat jemand eine Erklärung dafür?

[Patrick (Gast)]

Kommt auf Deinen restlichen Code an.

Merke: Das Konstrukt ist concurrent, d. h. nicht getaktet. Vergleicher 
und Muxer brauchen nunmal eine gewisse Zeit; daher sind Glitches 
unvermeidlich.

[Michi (Gast)]

Patrick schrieb:
> Kommt auf Deinen restlichen Code an.
>
> Merke: Das Konstrukt ist concurrent, d. h. nicht getaktet. Vergleicher
> und Muxer brauchen nunmal eine gewisse Zeit; daher sind Glitches
> unvermeidlich.

Und es wird wohl auch keine Möglichkeit geben, die Berechnung an der 
Stelle zu Realisieren und Glitches komplett zu verhindern, oder?

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Michi schrieb:
> Und es wird wohl auch keine Möglichkeit geben, die Berechnung an der
> Stelle zu Realisieren und Glitches komplett zu verhindern, oder?

Doch die gibt es. Dazu musst du deine Berechnungen in einen Prozess 
packen. Dann benötigst du einem Takt.

Tom

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas Reinemann schrieb:
> Doch die gibt es.
Nein. Die gibt es nicht.

> Dazu musst du deine Berechnungen in einen Prozess packen.
> Dann benötigst du einem Takt.
Ich kann das ganze auch concurrent mit Takt schreiben, aber das ist 
nicht das Problem...

Letztlich wird aus dieser Beschreibung IMMER (ob Prozess oder 
Nebenläufig) ein Rechenwerk und ein Mux generiert. Und diese Logik wird 
immer eine Laufzeit haben und solange glitchen, bis alle Pfade stabil 
sind. Das ist ganz einfach das Verhalten von Logik. Diese 
"Stabilisierungszeit" (Propagation Delay) bestimmt dann die maximale 
Taktfrequenz des Designs (fmax = 1/(tco+tpd+tsu) = Kehrwert von {Clock 
to Output-Zeit + Laufzeit von Registerausgang zum Registereingang + 
Setupzeit}).
Mit den "dahintergeschalteten" Registern wird dann praktisch nur naoch 
das Ergebnis weiterverwendet und mit (jetzt kommts) beim nächsten Takt 
nach aussen gegeben.
Wenn dort dann sowieso ein Register käme (man weiß das aus dieser 
Teil-Beschreibung noch nicht) dann wäre da einfach eine Registerstufe zu 
viel drin. Und das nennt sich dann Latency und bringt ganz andere 
lustige Effekte mit sich, weil alle Ergebnisse "irgendwie einen Takt 
später kommen"...

Michi schrieb:
>> Merke: Das Konstrukt ist concurrent, d. h. nicht getaktet. Vergleicher
>> und Muxer brauchen nunmal eine gewisse Zeit; daher sind Glitches
>> unvermeidlich.
>
> Und es wird wohl auch keine Möglichkeit geben, die Berechnung an der
> Stelle zu Realisieren und Glitches komplett zu verhindern, oder?
In jedem FPGA glitcht es nach einem Takt an allen Ecken und Enden. Diese 
Glitcherei muß aber rechtzeitig vor dem nächsten Takt fertig sein 
(konkret: um die Setupzeit tsu der beteiligten FFs früher). Das ist dann 
ein synchrones Design und kann vom Timing-Analyzer einfach berechnet 
werden. Auf dieser Grundlage wird dann auch die maximale Taktfrequenz 
angegeben...