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?
So richtig ist mir nicht klar, was du meinst. Kannst ja mal deinen Code (ausschnittsweise) zeigen?
Du must anders herum denken: Wenn Du in die Pfade Register einfügst, muss weniger "in einen Takt" hinein. Dann klappt as umso eher.
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
@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
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)
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
@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
@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
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
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...)
ok danke, muss ich mir heute abend mal näher betrachten. Aber warum soll das im CPLD funktionieren und im FPGA nicht? Gruß Volker
@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
@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
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
@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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.