Hallo, ich hab ein sehr merkwürdiges Problem und hoffe, dass es jemand gibt der mir ein Erklärung liefern kann, bzw. gar ein Lösung. Ich arbeite mit der XILINX ISE Webpack 12.3 und habe für CPLD XC95108 Code erzeugt, der auch funktioniert. Damit ich die versch. Entwicklungsstufen mal nachvollziehen kann, hab ich in Abständen Kopien des Projektes angelegt. Dabei habe ich jeweils die *.JED, *.VHD und *.UCF Datei in ein Zip-File gesichert. Soweit so gut. Nun habe ich aber mal eine solche "Sicherung" gebraucht und die *.VHD und *.UCF Datei zurückgespielt und die JED Datei erzeugt, die aber plötzlich NICHT mehr funktioniert ! Sie ist auch von der Kopie komplett anders. Um das zu verifizieren, hab ich mal ein neues Projekt mit diesen Dateien erstellt und dort den gleichen Effekt. Was mach ich falsch, oder wo könnte das Problem liegen? Danke Euch ! Gruß Ralph PS: Das ich die Hardware nicht geändert hab ist logisch !
Ralph H. schrieb: > Nun habe ich aber mal eine solche "Sicherung" gebraucht und die *.VHD > und *.UCF Datei zurückgespielt und die JED Datei erzeugt, die aber > plötzlich NICHT mehr funktioniert ! Du hast noch einige Optionen, die in den Projekteinstellungen versteckt sind. Und die können durchaus (insbesondere bei asynchronen Designs) über Erfolg und Misserfolg entscheiden...
Lothar Miller schrieb: > über Erfolg und Misserfolg entscheiden... und ob mein lieber Lothar :) !! Du hast mal wieder vollkommen Recht ! In einer nächtlichen Sitzung hab ich herausgefunden, woran es liegt und konnte nun die JED Datei wieder exakt identisch herstellen! :-) Es war die Einstellung im Fitter die Zellen im LOW Power Modus zu betreiben! Leider ist genau dadurch das nächste Problem entstanden. Im Power Mode LOW funzt mein Design, im STD Mode nicht !! Hast Du ne Idee worin der Unterschied der beiden Modi beim CPLD XC95108 liegt ? Und noch ne Frage dazu... welche Dateien im Projekt muss ich sichern, wenn ich z.B. einem Nachbauer meine Sourcen geben möchte, damit er NICHT in diese gemeine Falle tappt ? Danke sagt Ralph
Ralph H. schrieb: > welche Dateien im Projekt muss ich sichern, Ich mach das hart&herzlich: Cleanup Project Files und dann das ganze Verzeichnis gesichert. Klaus Falser schrieb: > Low Power ist langsamer! Das ist mein Verdacht... >> insbesondere bei asynchronen Designs
Lothar Miller schrieb: > Ralph H. schrieb: >> welche Dateien im Projekt muss ich sichern, > Ich mach das hart&herzlich: > Cleanup Project Files und dann das ganze Verzeichnis gesichert. Gute Idee ! das werd ich auch in Zukunft tun, aber noch die JED Datei sichern :-) > Klaus Falser schrieb: >> Low Power ist langsamer! > Das ist mein Verdacht... >>> insbesondere bei asynchronen Designs Hm.. ich denk mir auch sowas, weiß aber echt nicht wo mein Problem liegt. Bitte seid so lieb und schaut mal über das Design. Ich habe hier eine real existierende Schaltung 1:1 nachgebildet. Das funktioniert auch gut, wenn es im POWER Mode LOW läuft. Bei POWER Mode STD spinnen die beiden FlipFlops für die Synchronimpulserzeugung und ich meine fast sie schwingen total unregelmäßig?! Bitte schaut mal über den Code ob ich da nen groben Schnitzer drin hab. Er ist für einen CPLD XC95108 und es existiert noch eine UCF Datei dafür. Vielen Dank sagt Ralph
> ich meine fast sie schwingen total unregelmäßig?!
Hmmm...
Wie sieht denn die Stromversorung und insbesondere die Entkopplung aus?
Im Standard-Modus hast du natürlich auch höhere Umschaltströme...
Naja ich hab die üblichen Abblock C's drin und zwar an jedem Vcc Pin. Hab grad mal den Oszi drangehalten.. nicht eine einzige Zacke zu sehen. Gruß Ralph
Ralph H. schrieb: > Bitte schaut mal über den Code ob ich da nen groben Schnitzer drin hab. Ja, z.B. abgeleitete Takte wie z.B. TaktD41. So etwas macht man mit Clock Enable.
OK und warum sind abgeleitete Takte nun grobe Schnitzer ? Bitte seid so lieb und versucht es mir auch irgendwie verständlich zu erklären und nicht nur draufhaun, ok ?! Ich weiß das ihr Profis alles gern synchron haben wollt, aber wenn ich als Newbie ne logische Schaltung nachbilde, dann sieht das so aus. Gern werd ich mit Euch zusammen das ganze auf gute Füße und synchrone Füße stellen, nur wie ?
Ralph H. schrieb: > Bitte seid so lieb und versucht es mir auch irgendwie verständlich zu > erklären und nicht nur draufhaun, ok ?! Draufloshauen wollte ich nicht, aber solche Dinge wurden hier doch schon oft besprochen, und Du hast sie anscheinend auch schon gehört. FPGAs und CPLDs haben spezielle, interne Resourcen für die Taktverteilung. Diese sind notwendig, damit z.B. bei einem 16 Bit Zähler wirklich alle Bits "gleichzeitig" schalten. a) Bei abgeleiteten Takten werden diese Taktnetze nicht immer verwendet, besonders in Deinem Fall wo Du 4 oder mehr Takte hast. b) Verknüpft man Signale, die aus FFs mit abgeleitetem Takt kommen, wieder mit anderen Signalen, die vom Originaltakt stammen, dann kommt es zu Glitches usw, und die Tool können die Einhaltung des Timings nicht mehr kontrollieren. c) FFs mit abgeleitete Takte werden nicht auf Einhalten der Setup- und Holdzeit kontrolliert. > Ich weiß das ihr Profis alles gern synchron haben wollt, aber wenn ich > als Newbie ne logische Schaltung nachbilde, dann sieht das so aus. Nicht die Profis wollen es so, aber eine zuverlässige Schaltung möchte es so ...
Klaus Falser schrieb: > Ralph H. schrieb: > a) Bei abgeleiteten Takten werden diese Taktnetze nicht immer verwendet, > besonders in Deinem Fall wo Du 4 oder mehr Takte hast. > b) Verknüpft man Signale, die aus FFs mit abgeleitetem Takt kommen, > wieder mit anderen Signalen, die vom Originaltakt stammen, dann kommt es > zu Glitches usw, und die Tool können die Einhaltung des Timings nicht > mehr kontrollieren. > c) FFs mit abgeleitete Takte werden nicht auf Einhalten der Setup- und > Holdzeit kontrolliert. Das war etwas was ich verstehen kann Falk ! Insbesonder b) wird wohl bei den FlipFlops für die Synchronimpulse genau das Problem sein. Also lass mich das Projekt richtig machen und wir fangen mal bei den ersten beiden Zählern DG19 und QD41_42 an. DG 19 muss bis 6 zählen und dann neu bei 0 beginnen, der Übertrag muss QD41_42, der bis 84, zählt weiterschalten. Wie löse ich das synchron ? Ein einfaches Beispiel würde mir erstmal genügen, ich mach das dann fertig und schaut wieder drüber, können wir das so machen ? Danke sag ich schon mal vorab :-)
Ralph H. schrieb: > Wie löse ich das synchron ? Du brauchst den einen einzigen Systemtakt, den du in deiner Anwendung aber nicht so ohne weiteres hast... Diese schöne reproduzierbare reine Lehre vom synchronen Design findet in CPLDs sehr schnell ein Ende :-( Aber dies hier (und ähnliches) geht garantiert (früher oder später) schief:
1 | process(VDCLK) -- Basis ist VDCLK Takt der durch 6 geteilt wird |
2 | begin
|
3 | if rising_edge(VDCLK) then QD19 <= QD19 + 1 ; end if ; --zählen.. |
4 | if QD19 = 6 then QD19 <= "000" ; end if ; --max. bis 6 !!! falsch !!! die Hardware zählt nur 0...5, bei 6 kommt ein kombinatorischer Reset |
5 | end process; |
6 | TaktD41 <= '1' when QD19 = 0 Else '0' ; -- Takt aus Kombinatorik (Vergleicher) --> der kleinste Glitch kann takten |
Und da fällt mir gerade noch was auf: deine Sensitivliste ist unvollständig, die Simulation ist falsch, da müsste eigentlich noch QD19 rein... Denk mal drüber nach. Und viel schlimmer: du hast einen asynchronen (Bäh), kombinatorischen (Bäbäh) Reset eingefügt und den auch noch als Taktsignal (Igittigitt) genommen... Wenn schon, dann sollte das mindestens noch durch ein FF gehen (so du genug hast), damit kein Glitch auftreten kann:
1 | process(VDCLK) -- Basis ist VDCLK Takt der durch 6 geteilt wird |
2 | begin
|
3 | if rising_edge(VDCLK) then |
4 | if QD19 < 6 then -- zählt 0..5 |
5 | QD19 <= QD19 + 1 |
6 | TaktD41 <= '0'; |
7 | else
|
8 | QD19 <= "000"; |
9 | TaktD41 <= '1'; |
10 | end if ; |
11 | end if; |
12 | end process; |
>> Klaus Falser schrieb: ... > Das war etwas was ich verstehen kann Falk ! Wie, wer, wo, was?
Lothar Miller schrieb: > Und da fällt mir gerade noch was auf: deine Sensitivliste ist > unvollständig, die Simulation ist falsch, da müsste eigentlich noch QD19 > rein... > Denk mal drüber nach. Gut mach ich mal :) und werd das ganze mal überarbeiten. > Wenn schon, dann sollte das mindestens noch durch ein FF gehen (so du > genug hast), damit kein Glitch auftreten kann: Hm.. Danke Dir ! aaber ne Frage dazu, ich hab mal gelesen, dass ich möglichst KEINE Größer oder Kleiner als Operationen verwenden soll. >>> Klaus Falser schrieb: ... >> Das war etwas was ich verstehen kann Falk ! > Wie, wer, wo, was? Upps da war ich einfach auf den falschen Tasten. Sorry
Hm.. nun hab ich zumindest mal die Zähler umgebaut und es geht garnichts mehr :-(, dabei habe ich zuerst D19 geändert --> ging noch :-) dann D41_42 und schon war es aus mit der Freude. :-( Also hab ich alle Zähler mal so aufgebaut, aber das änderte auch nichts. Die Zähler scheinen falsch zu zählen.
So, ich möchte mich nach längerer Zeit mal wieder melden. Hab meinen Code überarbeitet und bitte um Eure Hinweise, Kritik oder auch Bestätigung. Ich denke jetzt meine Zähler schön synchron zu haben, sodass ich ohne Glitches zu beführchten, verschiedene Zählerstände mit FlipFlips auswerten kann, oder ? LG Ralph PS: Hatte grad die falsche Datei hochgeladen und deshalb den Beitrag nochmal gelöscht ! Sorry
Lothar Miller schrieb: > Diese schöne reproduzierbare reine Lehre vom synchronen Design findet in > CPLDs sehr schnell ein Ende :-( warum? ich hatte bis jetzt nur mit spartan3 zu tun. zu wenige FF?
Ralph H. schrieb: > Bitte seid so lieb und versucht es mir auch irgendwie verständlich zu > erklären und nicht nur draufhaun, ok ?! > Ich weiß das ihr Profis alles gern synchron haben wollt, aber wenn ich > als Newbie ne logische Schaltung nachbilde, dann sieht das so aus. eigentlich nur deswegen weil der Takt - Event der ansteigenden Flanke - durch die Logik "verschmiert" wird. Google nach clock skew. Das Problem dabei ist, dass die Tools die clock skew "überwachen" dadurch verwirrt werden und nicht mehr garantieren, dass es keine setup-violentions gibt. clock enable hingegen ist normales Signal und mischt nicht in die clock Analyse hinein. So, das war meine unprofessionele Erklärung, da ich nur gelegentlich damit zu tun habe.
zusatz: from the top of my head ... also wenn du clock gatest, beispielsweise durch ein Freigabesignal, das zusammen mit clock und-verknüpft wird, erfährt ein delay .. in ca 2ns Grösse. (LUT delay) Gleichzeitig garantiert dir clock-tree in einem FPGA (Datenblatt) ebenfalls max. clock skew von 2ns(Grössenordnung). Worst case von FF zu FF können sich 4ns Taktversatz ergeben! Wenn die jetzt Daten austauschen .. das schreit nach Problemen.
@Daniel... hm.. was willst Du mit Deinen Beiträgen sagen ? Aus meiner Sicht liegen die doch glatt neben meinen Fragen zum Check des Codes, oder?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.