Forum: FPGA, VHDL & Co. synchron / asynchron


von Marc (Gast)


Lesenswert?

Hi,
ich habe ein asynchrones Design in VHDL implementiert, welches zwar in 
der Simulation funktioniert, im FPGA jedoch nicht. Sieht so aus, dass 
ich um eine Synchronisierung nicht umhin komme. Das Problem dabei ist 
die Totzeit von bis zu einem Taktzyklus, die ich dadurch bekomme 
(deswegen habe ich es zuerst asynchron versucht).
Jetzt habe ich mir gedacht, dass ich einfach nen Ausgang mit nem Eingang 
verbinde und diesen dann im FPGA invertiere. Damit müsste ich doch dann 
den schnellstmöglichen Takt erhalten, auf den ich synchronisieren 
kann...
Kann man das so machen?

von na (Gast)


Lesenswert?

So richtig ist mir nicht klar, was du meinst. Kannst ja mal deinen Code 
(ausschnittsweise) zeigen?

von Tarzan (Gast)


Lesenswert?

Du must anders herum denken: Wenn Du in die Pfade Register einfügst, 
muss weniger "in einen Takt" hinein. Dann klappt as umso eher.

von Joerg W. (joergwolfram)


Lesenswert?

Oftmals hilft es auch, Signale die beim synchronen Design zu schnell 
wären, über eine Dummy-Pipeline (also eine Art Verzögerungsleitung) 
"abzubremsen", damit am Schluss wieder alles passt.
Ansonsten kann man natürlich auch einen Ausgang mit einem Takteingang 
verbinden, wobei es dann schwierig werden kann, Signale aus dem ersten 
Teil (vor der "Brücke") mit Signalen aus dem zweiten Teil zu verknüpfen 
ohne dass Mist rauskommt. Wenn der erste Teil zum Beispiel nur ein 
programmierbarer Vorteiler ist und noch Takteingänge frei sind, dann 
kann sich auf diese Weise eine Menge Logik einsparen lassen.

Gruß Jörg

von Falk (Gast)


Lesenswert?

@Marc

>der Simulation funktioniert, im FPGA jedoch nicht. Sieht so aus, dass
>ich um eine Synchronisierung nicht umhin komme. Das Problem dabei ist

Das ist praktisch immer so.

>die Totzeit von bis zu einem Taktzyklus, die ich dadurch bekomme

oder machmal auch zwei oder mehr.

>(deswegen habe ich es zuerst asynchron versucht).
>Jetzt habe ich mir gedacht, dass ich einfach nen Ausgang mit nem Eingang
>verbinde und diesen dann im FPGA invertiere. Damit müsste ich doch dann
>den schnellstmöglichen Takt erhalten, auf den ich synchronisieren
>kann...

Ahhhhhh. Lass es! Beschreibe dein Problem mal lieber genauer, dann kann 
man auch ne solide Lösung erarbeiten.

>Kann man das so machen?

Machs wie die Beatles, "Let it be, let it be . . . ;-)

MfG
Falk

von Marc (Gast)


Lesenswert?

Anscheinend habe ich mich ein wenig unglücklich ausgedrückt, daher 
nochmal:
Also, ich brauche sehr schnelle Reaktionszeiten. Deshalb währe mir ein 
asynchrones Design, bei dem auf Eingangsänderungen unmittelbar reagiert 
würde am liebsten. Da sich das aber so leider nicht implementieren lässt 
habe ich das ganze notgedrungen synchronisiert. Nun möchte ich aber 
wenigstens die schnellstmögliche Zykluszeit haben. Da habe ich mir 
gedacht, dass man vielleicht auf einen Quarz verzichten könnte und den 
Takt durch eine Rückkopplung von FPGA-Ausgang auf den Clock-Eingang 
generieren könnte. Dazu müsste der Ausgang dann einfach auf "NOT CLK" 
gesetzt werden. Dieser Takt währe doch dann automatisch so schnell, wie 
der FPGA sein kann. Möglicherweise müsste man in den extern Signalpfad 
auch noch eine Verzögerung mittels Logikgatter aufbauen. Es handelt sich 
also hier um eine Grundsätzliche frage.
Also, kann man das so machen? Was muss man beachten? Was passiert z.B. 
wenn dieser Takt dann schneller währe, als die Durchlaufzeit des 
längsten Signalpfades meiner Implementierung? Wie bekomme ich diese max. 
Durchlaufzeit heraus? Dieser längste Pfad wird ja möglicherweise nur 
unter ganz bestimmten Konditionen durchlaufen...
Das ist mein erstes FPGA Projekt und ich habe von dem ganzen Kram (auch 
VHDL) noch überhaupt keine Ahnung, deshalb frage ich hier so naiv.
Die Schaltung läuft übrigens trotzdem schon, jetzt synchron und mit 
Quarz. Das ist mir aber noch nicht schnell genug, ich will also alles 
rausholen was nur geht!!

Viele Grüße,
Marc


Ach ja, kann mir jemand eine Quelle empfehlen, wo das alles anschaulich 
erklärt wird? Am liebsten nicht allzu wissenschaftlich und mit 
Schwerpunkt auf sauberes Schaltungsdesign in VHDL. (Gerne auch in 
Buchform)

von Joerg W. (joergwolfram)


Lesenswert?

Ich denke, das wird nicht gehen, da einerseits die Signalpfade von 
verschiedenen Signalen unterschiedlich lang sein können (da helfen 
Timing-Constraints) zund zum zweiten gibt es Toleranzen in den 
Laufzeiten, bei 20 Grad kann es gehen, bei 30 nicht und beim nächsten 
FPGA/CPLD zucken die Ausgänge nur noch ein bisschen. CPLD's habe ich 
solche "ungewollten" Taktgeneratoren schon zum abrauchen gebracht, da 
die Umschaltverluste immens ansteigen. Ein ordentlicher Taktgenerator 
ist MUSS, bei einem CPLD kann man getrost auch ein bisschen asynchrone 
Logik mit reinbauen. Aber nur, wenn man weiß was man tut...

Gruß Jörg

von Falk (Gast)


Lesenswert?

@Marc

>Anscheinend habe ich mich ein wenig unglücklich ausgedrückt, daher
>nochmal:
>Also, ich brauche sehr schnelle Reaktionszeiten. Deshalb währe mir ein
>asynchrones Design, bei dem auf Eingangsänderungen unmittelbar reagiert
>würde am liebsten. Da sich das aber so leider nicht implementieren lä

Aaaaaaa, bitte mal die Wortwahl prüfen. Auch synchrone Schaltungen sind 
SEHR schnell. Und wenn du Eingangssignale ohne Abtastung verwendest 
heisst das noch lange nicht, dass die Schaltung asynchron ist. Das sind 
kombinatorische Eingänge. Das Wort "asynchron" wird sowieso viel zu oft 
viel zu undefiniert benutzt.

>habe ich das ganze notgedrungen synchronisiert. Nun möchte ich aber

Das glaube ich nicht.

wenigstens die schnellstmögliche Zykluszeit haben. Da habe ich mir
>gedacht, dass man vielleicht auf einen Quarz verzichten könnte und den
>Takt durch eine Rückkopplung von FPGA-Ausgang auf den Clock-Eingang
>generieren könnte. Dazu müsste der Ausgang dann einfach auf "NOT CLK"
Du hast noch nicht wirklich verstanden, wie synchrone digitale 
Schaltungen funktionieren und warum man sie verwendet.

>gesetzt werden. Dieser Takt währe doch dann automatisch so schnell, wie
>der FPGA sein kann. Möglicherweise müsste man in den extern Signalpfad

Und? Was willst du mit einem 500 MHz Takt?

>auch noch eine Verzögerung mittels Logikgatter aufbauen. Es handelt sich
>also hier um eine Grundsätzliche frage.

Ja, nämlich dein fehlendes Verständnis für die Grundlagen der 
(synchronen) Schaltungstechnik.

>Also, kann man das so machen? Was muss man beachten? Was passiert z.B
Nicht wirklich. Ich wiederhole mich. Sag lieber mal WAS du machen 
willst, dann können wir dir sagen WIE du es machen kannst.

>Das ist mein erstes FPGA Projekt und ich habe von dem ganzen Kram (auch
>VHDL) noch überhaupt keine Ahnung, deshalb frage ich hier so naiv.

Das merkt man (nicht böse gemeint). Deshalb mein Rat. Vergiss diesen 
planlosen, auf 1/17 Wissen basierenden Murks und schau dir die 
Grundlagen an.

>Die Schaltung läuft übrigens trotzdem schon, jetzt synchron und mit

Jaja, genauso wie UARTS mit internen RC-Oszillatoren laufen etc. etc.
Die Frage ist nur wie stabil und solide das ganze ist.

>Quarz. Das ist mir aber noch nicht schnell genug, ich will also allesrausholen 
was nur geht!!

Sag worum es geht!

>Schwerpunkt auf sauberes Schaltungsdesign in VHDL. (Gerne auch in
>Buchform)

Google mal nach VHDL cookbook.

MfG
Falk

von Agamemnon (Gast)


Lesenswert?

Statt Zurechtweisungen schon mal daran Gedacht, auch jemandem zu helfen?

von Falk (Gast)


Lesenswert?

@Agamemnon

>Statt Zurechtweisungen schon mal daran Gedacht, auch jemandem zu helfen?

Ach schau an, der Herr Oberlehrer auch hier. Ich meine mich deutlich 
ausgedrückt zu haben.

a) er soll sich die Grundlagen anschauen.
b) er so direkt sagen was er machen will und nicht um den heissen Brei 
reden

MfG
Falk

von Volker (Gast)


Lesenswert?

Wolfram wrote

>>Ein ordentlicher Taktgenerator
>>ist MUSS, bei einem CPLD kann man getrost auch ein bisschen asynchrone
>>Logik mit reinbauen. Aber nur, wenn man weiß was man tut...

Wieso kann man bei einem CPLD ein bisschen asynchrone Logik einbauen, 
hier wäre vielleicht ein Beispiel angebracht.

Gruß

Volker

von Joerg W. (joergwolfram)


Lesenswert?

Kleines Beispiel ist die Abhängigkeit eines Signals von zwei Flanken, 
ohne dass man einen Takt braucht:
1
--Flanke 1
2
process (input1,outsig) is
3
begin
4
   if (outsig='1') then
5
      flanke1 <= '0';
6
   elsif (rising_edge(input1)) then
7
      flanke1 <= '1';
8
   end if;
9
end process;
10
11
--Flanke 2
12
process (input2,outsig) is
13
begin
14
   if (outsig='0') then
15
      flanke2 <= '0';
16
   elsif (rising_edge(input2)) then
17
      flanke2 <= '1';
18
   end if;
19
end process;
20
21
--Ausgangssignal
22
process (flanke1,flanke2) is
23
begin
24
   if (flanke1='1') then
25
      outsig <= '1';
26
   elsif (flanke12='1') then
27
      outsig <= '0';
28
   end if;
29
end process;
Das erzeugt zwei D-FlipFlops und ein RS-FF. Die beiden Zwischensignale 
flanke1 und flanke2 werden asynchron zurückgesetzt, wenn das 
Ausgangssignal umgeschaltet hat. (Ich hoffe, ich hab jetzt nicht in der 
Eile zu viele Fehler reingemacht...)

von Volker (Gast)


Lesenswert?

ok danke, muss ich mir heute abend mal näher betrachten.

Aber warum soll das im CPLD funktionieren und im FPGA nicht?

Gruß Volker

von Falk (Gast)


Lesenswert?

@Joerg Wolfram

>Kleines Beispiel ist die Abhängigkeit eines Signals von zwei Flanken,
>ohne dass man einen Takt braucht:--Flanke 1

Und welchen Sinn soll das Ganze haben? Mir ist schon klar dass man auch 
FPGAs irgendwelche asynchrone Sachen machen kann, wenn man WIRKLICH 
weiss was man tut sogar zuverlässig. ABER!
Für 99% aller Designaufgaben ist das schlicht nicht notwendig und 
falsch.

MFG
Falk

von Joerg W. (joergwolfram)


Lesenswert?

@Volker
Im CPLD kann man das Taktsignal jeder Makrozelle mit einem beliebigen 
Eingang oder Signal verbinden. Bei einem FPGA habe ich nur eine recht 
begrenzte Auswahl an Taktsignalen. Für synchrone Designs gibt es bei den 
CPLDs natürlich auch globale Takteingänge.

@Falk
Bei einem FPGA und auch bei einem CPLD, welches eine in sich 
geschlossene Funktion hat, mag das stimmen. Wenn es aber z.B. darum 
geht, einfach nur ein "TTL-Grab" zu ersetzen in dem womöglich noch ein 
paar RC-Differenzierglieder mit eingebaut sind, spricht nichts gegen 
eine asynchrone Lösung. Was ich geschrieben hatte, sollte ja auch nur 
ein Beispiel für asynchrone Logik sein.  Die Benutzung von globalen 
Variablen in C-Unterprogrammen könnte man dann auch einfach als falsch 
bezeichnen...

Gruß Jörg

von Klaus F. (kfalser)


Lesenswert?

Im CPLD wie im FPGA gibt es spezielle Resourcen zur Verteilung des 
Takts.
Beim XC9500 sind es 2-3 GCLK Pins, die auch intern an dedizierte 
Leitungen gehen und in bezug auf Skew optimiert sind.
Beim FPGA sind es ein paar mehr.

Man kann aber im FPGA wie im CPLD jedes beliebige Signal mit dem 
Takteingang eines FF's verbinden. In dieser Hinsicht gibt es zwischen 
FPGA und CPLD keinen Unterschied. Das wäre ansonsten eine zu arge 
Einschränkung.

Einen beliebigen Eingang als Takt an ein FF zu legen sollte man sich 
immer genau überlegen, und man muß sicher sein daß diese Signale 
garantiert glitchfrei sind, und die Rise- und Falltimes einhalten 
werden.

Klaus

von Falk (Gast)


Lesenswert?

@Joerg Wolfram

>geht, einfach nur ein "TTL-Grab" zu ersetzen in dem womöglich noch ein
>paar RC-Differenzierglieder mit eingebaut sind, spricht nichts gegen
>eine asynchrone Lösung.

Ohhhh doch! Ein CPLD ist um EINIGES schneller als die guten alten 
TTL-Gräber. Das geht mal ganz fix danaben!
Zum Bleistift

http://www.geocities.com/jacquesmartini/digital/glitch/glitch.html

(jaja, ist hier mit nem FPGA getestet worden, das Problem ist bei CPLDs 
aber das gleiche; Die Compileroption WYSIWUY (What you see is what you 
get) ist so ein Überbleibsel aus den asynchronen Murksdesignzeiten der 
TTL Ära)

>Was ich geschrieben hatte, sollte ja auch nur
>ein Beispiel für asynchrone Logik sein.

Die zu 99% niemand braucht und nur die Murksprogrammierung fördert.

>Die Benutzung von globalen
>Variablen in C-Unterprogrammen könnte man dann auch einfach als falsch
bezeichnen...

Nöö, sie sind für bestimmte Dinge schlicht notwendig (z.B. Interrupts).

MfG
Falk

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.