ISE erzeugt immerwieder andere JED Datei

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:
> Im Power Mode LOW funzt mein Design, im STD Mode nicht

Low Power ist langsamer!

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?