Frage zu DCM und "schrägem" Takt

Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen 
Takt dann eine DDS:

   http://de.wikipedia.org/wiki/Direct_Digital_Synthesis

Das geht natürlich auch digital, ohne DA-Wandler (einfach das MSB vom 
Phasen-Akku verwenden), hat aber bei Deinen Größenverhältnissen einen 
kräftigen Jitter.

> Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen
> Takt dann eine DDS

Hm, DDS hatte ich so abgelegt, dass das Verfahren zur Erzeugung einer 
beliebigen, konstanten Signalform ungleich dem Rechteck wäre, nicht aber 
für Rechtecksignale.

Aber egal, selbst wenn ich den Accu auf 1 begrenze, erreiche ich damit 
(sofern ich das Prinzip verstanden habe) nur 2**n Teilverhältnisse. 
Selbst wenn ich die 50 MHz auf 200 oder 250 MHz aufpeppe, wüßte ich 
trotzdem nicht, wie ich zu Frequenzen komme, die nicht durch ganzzahlige 
Teiler erreicht werden können.

>> Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen.
> Die Konterfrage lautet: wozu?

Die 57,6 MHz waren nur ein Beispiel, es könnten auch 75.396 Hz sein.
Zum einen geht es mir ums Verständnis und zum Anderen darum, eine 
gegebene Spezifikation einzuhalten.

> Warum kommst du mit deinen 50MHz nicht aus?

Weil ich nicht weiß, wie ...

> Wie genau müssen die 57,6MHz erreicht werden?

Nominell auf 2 Herz genau, aber praktisch natürlich mit den gleichen 
Toleranzen, die ein Quarz auch mitbringt (20-50ppm?) - Klar, je genauer 
desto besser.
Ist natürlich auch eine Frage des Aufwandes.

Wenn es einen Weg gibt, eine beliebige (einstellbare) Frequenz außerhalb 
des FPGAs mit vertretbarem Aufwand zu erreichen, wäre ich zu einer 
solchen Variante auch nicht abgeneigt. Ich könnte den Takt ja auch über 
die SMA-Buchse, oder LVDS-Leitungen zuführen.

mit DDS/NCO kannst du beliebig genaue frequenzen erzeugen,
aber es bleibt der jitter, der dann maximal eine clk von
dem NCO takt sind. mit hoch pumpten NCO clock ist es dann
weniger aber immer da.

fur S3E gibt es eine reference design, das den DCM in
"clock dither" modus betreibt, da wird eine DCM mit
NCO generated clock angespeist, und DCM macht den
jitter weniger, such die S3E starter kit reference designs
da ist es, der "frequency generator mit picoblaze" da drinne

Antti

> Dann wirst du einen Quarz kaufen müssen.

Yepp - da wird es wohl darauf hinaus laufen.

Ich habe mir mal eine Matrix mit den möglichen DCM-Werten bei gegebener 
Eingangsfrequenz gemacht. Da geht zwar einiges, aber so richtig 
befriedigend ist es nicht.

> Du hast die Frage nach dem Jitter noch nicht beantwortet.

War das in einem anderen Thread? Oder meinst Du die implizite Frage?

Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen:
Ich hätte gern so wenig wie möglich :)

Konkret erarbeite ich mir gerade einen Bustreiber für den SPI-Bus. Wenn 
ich davon ausgehe, dass jeder Busbenutzer andere Forderungen an den Bus 
hat, ist das (für mich) nicht ganz einfach unter einen Hut zu bekommen. 
Wenn ich davon ausgehe, dass der FPGA jeweils der Master ist, geht das 
ja noch halbwegs, weil der SPI-Takt dann mit dem Systemtakt zusammen 
hängt. Bleibt immer noch die Frage, wie ich eine geforderte Frequenz 
eines SPI-Slave-Chips erzeuge.

Interessanter wird der Busmaster, wenn er den FPGA (auch) im Slave-Modus 
betreiben soll, oder für den SPI-Bus ein externer Takt verwendet wird, 
der keinen Bezug mehr zum Systemtakt hat.

Wenn ich mir das jetzt unter dem Jitter-Aspekt anschaue, dann sollen die 
SPI-Signale und deren Verarbeitung/Weiterreichung mit SPI-Takt erfolgen, 
die Verwaltung des Busses und die Verarbeitung der parallisierten Daten 
mit Systemtakt des FPGA erfolgen. An irgendeiner Schnittstelle wird sich 
der Jitter sicher nicht vermeiden lassen.
Bleibt für mich die Frage, ob die Integrität der Daten darunter zu 
leiden hat.

Schließlich soll der Rest des FPGA ja mit seinem "normalen" Systemtakt 
laufen.

>> Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen:
>> Ich hätte gern so wenig wie möglich :)
> Bitte Zeit- und Toleranzangaben nicht qualitativ (schnell, klein, kurz,
> lang...) sondern gleich quantitativ.

Nun, bei der Frequenz hatte ich doch quantitativ geantwortet.
Auf 2 Herz genau - wenn ich das bei 100 Mhz umsetzen würde, wäre das 
eine Genauigkeit von 0,00002 Promille - also völlig utopisch.

Deshalb habe ich geschrieben, es sollte der Genauigkeit von Quarzen 
entsprechen. 100ppm dürfte dort wohl "normal" sein, 20ppm sind dann wohl 
die besseren.

> Du kannst alle mir bekannten SPI-Slaves auch langsamer als mit der
> maximalen Taktfrequenz anfahren.

Logisch! - Aber wenn man gewisse Protokolle fahren will, gibt es dort 
spezielle Vorgaben. Nur um mal ein Beispiel zu nennen: Bei ner CD sind 
44.100 KHz Standard. Ich weiß nicht, ob man hören kann, wenn eine CD mit 
44.105 oder 44.095 kHz abgetastet wird - jedenfalls wäre es schon 
nominell nicht mehr konform. Die Fehler der ganzen Signalkette kommen ja 
noch dazu - es ist eher unwahrscheinlich, dass sich Fehler gegenseitig 
aufheben.
Genauso ist es ja auch mit den 12,5 MHz von Ethernet. Keine Ahnung, wie 
dort die Toleranzen sind, aber wenn man nicht versucht, den nominell 
geforderten Wert zu erreichen, kann man seine Arbeit nicht als 
"standardkonform" bezeichnen.

Mir ist schon klar, dass ich solange ich mich innerhalb des 
Entwicklungsboards befinde, mich einen feuchten um Standards kümmern 
kann.
Das sieht aber anders aus, wenn ich Anschluss suche und/oder meine Daten 
anderweitig verwenden will.

Allerdings ist mir auch bewusst, dass selbst wenn ich eine Frequenz auf 
die letzte Stelle exakt produzieren könnte immer noch die Toleranz des 
Quarzes reinspielt, der den Takt für den FPGA erzeugt.

> Sieh dir mal das an:
Im Moment mag ich nicht :)
Ich will ja nicht immer nur abschreiben, sondern auch mal was verstehen, 
bzw. selbst hinbekommen. Da die Grundlagen noch nicht sitzen, muss ich 
schon genug nachschlagen.
Wenn's klemmt oder ich fertsch bin, melde ich mich sowieso.

> BTW:
> Urig, dass du auf die wichtigste Frage keine Antwort gefunden hast:
>>> Warum kommst du mit deinen 50MHz nicht aus?
>> Weil ich nicht weiß, wie ...

Öhm, könntest Du das bitte etwas erläutern?

>> Sieh dir mal das an:
>Im Moment mag ich nicht :)

solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen 
wegen krummer Takte hast: SPI ist sowieso total asynchron, ein SPI 
Master kann auch mal einen Moment laenger mit dem Takt aussetzen. Und 
damit hast du ein komplett asynchrones I/F und must es eben auch 
entsprechend in deiner Logik behandeln.

Und wenn du Outputs generierst, die eine gewisse, krumme, Taktfrequenz 
benoetigen, dann brauchst du einen externen Quartz/Oszillator und musst 
den halt evtl. mit einem DCM hinzwiebeln.

Also ich glaube auch, du verstehst dein eigentliches Problem noch nicht 
ganz...

>@  berndl
>> SPI ist sowieso total asynchron
>SPI ist in sich absolut synchron.

aber nur senderseitig gesehen! Am Slave musst du mit jedem Worst-Case, 
der unterwegs auftauchen kann, rechnen...

> Allerdings hörst du keinen Unterschied, ob die CD mit 44.105
> oder 44.100 kHz abgetastet wird.

Naja, sag das nicht den Hifi-Fetischisten...

Davon abgesehen: Mit einem 24 Bit Phasen-Akku bei 50 MHz 
Eingangsfrequenz und 44,1 kHz Ausgangsfrequenz, hat man schon eine 
Auflösung von unter 70 ppm, bezogen auf den 44,1 kHz, bei 32 Bits sind 
es in dieser Konstellation schon rund 0,25 ppm...

Was bleibt, ist der Phasenjitter. Bei 50 MHz zu 44,1 kHz wären das rund 
800 ppm. Darum die Eingangsfrequenz per DCM hoch jubbeln oder wie oben 
erwähnt, den Jitter der Ausgangsfrequenz direkt reduzieren.

Schade, aber die letzten beiden Antworten finde ich eher bedauerlich.

> solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen
> wegen krummer Takte hast ...

In diesem Thread schrieb ich nix davon, dass ich mir Sorgen um einen 
krummen Takt mache. Ich denke, ich habe einen Weg gefunden, 2 
Taktdomaine unter einen Hut zu bekommen. In diesem Thread wollte ich 
wissen, wie ich einen krummen Takt erzeugen, bzw. definieren kann/muss.

Klar weiß ich, dass die Abtastung der CD nix mit SPI zu tun hat.
Ich wollte lediglich ein allgemein bekanntes Beispiel verwenden, bei dem 
Frequenzen vorgegeben sind. Aber sich über jemand anderen lächerlich zu 
machen ist ja leichter, als auf die Frage einzugehen.

> SPI ist sowieso total asynchron, ein SPI Master kann auch mal einen Moment
> laenger mit dem Takt aussetzen.

Das mag im Audiobereich ja angehen. Schätze aber wenn ich in den 
Grenzbereich der IO-Frequenzen des FPGA komme, wird es schwierig werden, 
einen verlorenen Takt wieder einzuholen.

>> du verstehst dein eigentliches Problem noch nicht ganz...
> Da muss ich berndl recht geben: das glaube ich auch...

Das mag wohl sein. Will ich auch überhaupt nicht in Abrede stellen.
Ist das aber ein Grund, sich deshalb über die Beispiele lustig zu 
machen, anstatt beim Kernproblem, bzw. der eigentlichen Frage zu 
bleiben?
Ich bezeichne mich schließlich nicht umsonst als Anfänger.

Wünsche Euch noch einen schönen Sonntag

davon mal abgesehen, oben ging es im konkreten Bsp um SPI: Empfangen des 
SPI signals ist kein Problem, solange dein FPGA schneller laeuft als die 
SCK. Latenz fuer die Daten die rausgehen ist dann schonmal ein anderes 
Thema, verschlimmbessert durch z.B. Laufzeit auf der 
Uebertragungsstrecke. Da muss man evtl. schon mal tricksen...

Beim Beispiel 44,1kHz fuer .wav Uebertragung: Dann baue ich mir halt 
einen Quartz/Oszillator dazu und clocke mit dem meine Daten raus. Ob 
25ns frueher oder spaeter ist ja nicht das Problem. Hauptsache genau 
genug! Und bei 4Byte bei 44,1kHz, das ist ja nu auch nicht das 
Problem...

Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave' 
(SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht 
biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel 
schneller, kann also mit '(Over)sampling' das ganze loesen.

Und ja, Lothar, natuerlich hast du recht, SPI ist senderseitig synchron. 
Aber Empfaengerseitig halt nicht, selbst wenn du den gleichen 
Oszillator-Eingang am FPGA verwendendest wie der Sender. Deine 
Phasenlage kann eben nun mal 'worst-case' sein, darum ging es mir.

>Schade, aber die letzten beiden Antworten finde ich eher bedauerlich.

Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach 
gefragt :o)

Worum es hier geht, ist der Punkt, dass du beim FPGA Design 'genau' 
wissen musst, was deine Anforderungen sind. Ob du jetzt ein guter oder 
schlechter Logic-Designer bist, das zu beurteilen steht mir nicht zu und 
ich hab' auch gar keine Lust dazu!

Also bitte nicht auf den Schlips getreten fuehlen, jeder von uns 
'hardies' hat so seine eigenen Vorstellungen. Schilder doch dann nochmal 
konkret dein Problem, hier gibt's genuegend Leute, die die mit 
positiven/negativen Erfahrungen vlt. weiter helfen koennen.

Ich versteh die ganze Diskussion um die 57,6MHz nicht.

Einmal schreibt der OP, dass er sie genau einhalten muss. Ein anderes 
mal schreibt er, dass es nur um krumme Frequenzen geht und dass es ja 
auch "75.396 Hz" sein könnten.

Dann heißt es, er hat SPI und vergleicht es mit Audio und 44,1kHz oder 
mit den 12,5MHz von Ethernet. Beides kriegt man übrigens exakt von der 
Frequenz hin.

Das macht alles keinen Sinn ...

Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst.

Wie andere schon angesprochen haben, kann man normalerweise SPI immer 
mit weniger als der maximalen Frequenz fahren. Aber Informationen will 
er sich auch keine Anschauen.

Bei einem SPI-Analog-Digitalwandler geht das übrigens auch ... Da wird 
der SPI-Clock für den SAR-Converter verwendet.

Was ist es denn für eine Peripherie, die exakt 57,6MHz benötigt und über 
SPI angebunden wird?

Grüße
Gast

Oups - gerade gemerkt, dass während des Schreibens meines letzten 
Beitrages hier weiter diskutiert wurde - was ich garnicht mitbekam. 
Insofern sind die Referenzen (letzten beiden) natürlich falsch.

Ich möchte 2 Zitate loswerden:
- alles ist schwierig, bevor es einfach wird
- jetzt wo ich weiß, wie es geht, weiß ich auch, wie ich hätte fragen 
können

Der Punkt ist doch, dass ich noch nicht genug weiß, um mein Problem klar 
umreißen zu können, ja dass ich nichtmal weiß, ob das, was ich als 
Problem empfinde überhaupt eines ist. Wenn ich es könnte, bräuchte ich 
vielleicht garnicht mehr fragen.

> Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach
> gefragt :o)

Die ganze Diskussion um Jitter und Co hat mir einen neuen Aspekt 
eröffnet, über den ich mir bislang keine Gedanken gemacht habe. Deshalb 
hatte ich etwas weiter ausgeholt.

Im Spartan-Handbuch ist ein Bild, welches die Situation recht gut 
veranschaulicht. Nur sind auf dem Bild alle 3 Daten-/Logikpfade 
isolierte Inseln.

Auf dem Dev-Board hat es z.B. ein DAC, ein ADC und einen "Verstärker" 
für die ADC-Eingänge, wobei DAC und ADC mit 50 MHz angefahren werden 
dürfen, der Verstärker nur mit 1,5 MHz. Die Frequenzen sind gut aus dem 
Systemtakt erzeugbar.

Jetzt habe ich aber auch noch externe Komponenten, die ich auch noch 
ansteuern möchte. Die verwenden unterschiedliche Taktraten. Deshalb habe 
ich über div. externe Taktquellen angefangen nachzudenken.

> Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst.

Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu 
haben, die sich aus dem Systemtakt nicht erzeugen lässt.
Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides 
nur Beispiele.

> Dass der SPI-Takt natürlich vollkommen asynchron zum FPGA-Takt ist,
> steht auf einem anderen Blatt.

So, jetzt kommen wir auf den Punkt.
Von der Voraussetzung bin ich auch ausgegangen. Ich bin davon 
ausgegangen, dass jedes FPGA-Modul, welches mit einem externen 
SPI-Baustein kommuniziert, einen völlig anderen Takt (und evtl. auch 
andere SPI-Modi) haben kann.

Wenn ich nun eine Instanz haben will, die den Zugriff auf den SPI-Bus 
regelt, dann muss die mit dem FPGA-Systemtakt laufen, da sie ja keinen 
SPI-Takt kennt.

Um die Signale vom SPI-Bus an das richtige Modul zu routen, braucht also 
der Busmaster einen Teil, der mit dem jeweiligen SPI-Takt läuft und 
einen anderen Teil, der mit dem FPGA-Systemtakt läuft. Je nach 
Parallelschnittstelle brauchen die FPGA-Module, die mit den 
SPI-Bausteinen kommunizieren nix vom FPGA-Systemtakt zu wissen.

> Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave'
> (SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht
> biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel
> schneller, kann also mit '(Over)sampling' das ganze loesen.

Ja, berndl, damit hast Du völlig recht! Genau das habe ich auch gedacht, 
bzw. denke es immer noch. Das (Over)sampling funzt ja, wenn der 
Frequenzunterschied hinreichend ist, bzw. die Frequenzen in einem festen 
Verhältnis stehen. Wenn allerdings die Frequenzen durch verschiedene 
Taktquellen erzeugt werden, kann es doch zu Datenfehlern beim Samplen 
kommen - oder irre ich mich da?

> Aber Informationen will er sich auch keine Anschauen.

Woraus entnimmst Du das?
- Weil ich die vorgefertigte Lösung von Lothar nicht verwenden will?
Das eine hat mit dem anderen nix zu tun.
Ich habe von allen Bausteinen, die ich ansprechen will die Datenblätter 
- und glaub mir, ich kann unterscheiden zwischen Maximal- und 
Nominalwert.

Ich lese gerne, wenn es der Wissensbildung dient.
Abschreiben ist für mich eher ein Akt der Faulheit. Unter lernen 
verstehe ich was anderes.

Vom (meinem) Ansatz her habe ich ein SPI-Modul, welches die Schiebung 
veranstaltet, dann habe ich ein Modul zur Ansteuerung des DAC, eines für 
den ADC und eines für den Verstärker. Zwischen dem SPI-Modul und den 
anderen soll ein Busmaster den Zugriff regeln. Das SPI-Modul bezieht 
seinen Takt mal vom DAC-, mal vom ADC- und mal vom Verstärkermodul...

> Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu
> haben, die sich aus dem Systemtakt nicht erzeugen lässt.
> Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides
> nur Beispiele.

Vermutlich war genau das der Fehler der Fragestellung ... Oft ist es 
sinnvoll eine genaue Spezifikationen zu einem Problem zu haben, weil das 
die Bandbreite an möglichen Problemlösungen stark eingrenzt. Oft machen 
es sich die Anfänger einfach zu kompliziert und wollten etwas erreichen, 
was mit der entsprechenden Fachkenntnis überhaupt kein Thema ist, weil 
z.B. in einer Applikation eingebettet es evtl. garnicht so genau geht 
oder es andere Vereinfachungen gibt, die trotzdem zu einem richtigen 
Ergebnis führen.

Daher auch das permanente hinterfragen nach der Anwendung, weil 
Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit 
Fachkenntnis und jede Problemlösung auch vom Problem abhängt.

Nur so eine Anmerkung ...

Hallo zusammen,

> Daher auch das permanente hinterfragen nach der Anwendung, weil
> Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit
> Fachkenntnis und jede Problemlösung auch vom Problem abhängt.

Das mag in vielen Fällen ja auch richtig sein. Aber nicht wenn es um das 
Verständnis geht. Dann ist die konkrete HW Schall und Rauch.
Ich kann nur sagen - für meinen Geschmack wird nicht alles in den 
Büchern hinreichend erklärt, sodass ich es ohne zusätzliche Erklärung 
verstehen könnte.
Manchmal tauchen in einer Diskussion auch neue Aspekte auf, die ich auch 
gerne verstehen würde. Beispiele machen anschaulich und in dem Fall ist 
es mir wurscht, ob sie einen konkreten HW-Bezug haben.
In so einem Fall bringt mich das permanente Bohren nach konkreten Chips 
nicht weiter.

> Wenn ein SPI-Slave für seine Funktion einen Takt braucht
> (z.B. der Netzwerk-Chip ENC28J60), dann hat er einen dedizierten
> Takteingang.

Das ist korrekt. Mein externer ADC hat einen Systemtakt-Eingang. Dazu 
einige Konfigurationspins, über die man ihn als Master oder Slave 
betreiben kann. Einige Spielarten sind nur verfügbar, wenn man das 
Steinchen im Master-Modus betreibt. Master-Modus heißt für mich, dass 
der ADC den SPI-Takt erzeugt (deshalb habe ich ihn als gegeben 
eingestuft).

Selbst wenn ich den ADC im Slave-Modus betreiben will, ist die Spanne, 
die mein SPI-Takt variieren darf nicht sehr groß, denn der Wert sollte 
abgeholt sein, bevor ein neuer zur Verfügung gestellt wird. Deshalb habe 
ich über asynchronen Takt bezogen auf den externen ADC garnicht 
nachgedacht.

> Es bringt daher nichts, sich mit aller Gewalt einen externen asynchronen
> Takt einzuhandeln, nur um die Kommunikationsschnittstelle der Bausteine
> an der oberen Übertragungsgrenze zu fahren.

Das war nie meine Absicht. Nur wenn ich mit dem ADC eine vorgegebene (!) 
Samplerate einhalten will, ergeben sich die Taktraten von alleine. Das 
hat nix mit ausreizen zu tun, sondern mir geht es um Einhaltung einer 
Spezifikation.

>> Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom
>> Verstärkermodul...
> Hier liegt der Hund begraben.
> Diesen Ansatz solltest du nochmal überdenken, das macht die Sache
> unnötig umständlich  :-/

Nun, nicht jeder Takt läßt sich aus dem Systemtakt erzeugen. Also muss 
ich schon mal die Möglichkeit eines externen Taktes in Betracht ziehen. 
Dann habe ich ein paar Versuche gemacht, mit einem eigenen 
"Taktmultiplexer" die unterschiedlichen Takte zu erzeugen. Selbst mit 
der CE-Technik komme ich nicht auf die Zeiten, die ein DCM bietet.
Um jetzt 50 MHz, 12,5 MHz und 1,5 MHz gleichzeitig zur Auswahl zu haben, 
war das bislang beste Resultat 2 geschachtelte DCMs, wobei ich für die 
1,5 MHz noch einen separaten Teiler brauche (die DCMs lassen sich nicht 
so langsam konfigurieren).

Die ganzen Anforderungen sprengen den Rahmen dessen, was ein SPI-Master 
verwalten kann. Das hat mich zu dem Entwurf gebracht, dass ich den Takt 
entweder in den FPGA-Modulen erzeuge, oder in der Top-Entität durch 
Routing der entsprechenden Taktleitung.

Mit meiner Variante ist das SPI-Modul so flexibel, dass es als Master 
und als Slave arbeiten kann, ohne das es weiß, ob es Master oder Slave 
ist.

Die Speicherschnittstelle habe ich auch angedacht (war ein anderer 
Thread), wird vielleicht nicht so knackig wie Deine Variante, aber 
bislang bin ich mit meinem Entwurf zufrieden.

Etwas was mir ganz wichtig ist (um angesichts meines eingeschränkten 
Könnens trotzdem was zu erreichen), ist die Reduzierung der Komplexität 
schon beim Entwurf. Mag sein, dass ein Profi da mehr rausholen könnte - 
damit kann ich im Moment gut leben.
Ich habe mir einen Plan mit den zu erstellenden Modulen gemacht und da 
gehe ich jetzt eins nach dem anderen an.

Auf den asynchronen Takt, bzw. die Grenzen zwischen Taktdomainen bin ich 
jetzt von verschiedenen Seiten gestoßen und deshalb ist es nach wie vor 
ein Thema für mich.
Ich kann nicht behaupten, dass ich den Umgang mit unterschiedlichen 
Takten inzwischen kapiert hätte, noch kann ich mögliche Fehlerquellen im 
späteren Betreib ein- oder abschätzen.

Kann also durchaus sein, dass ich das nochmal wieder zum Thema machen 
muss.

> Es lag nie in meiner Absicht, dass du irgendwas abschreibst oder
> herkopierst.

Habe ich Dir ja auch nicht zum Vorwurf gemacht. Ich bin sehr froh und 
dankbar für Deine Seiten und habe schon viel von Dir gelernt und 
abgeschaut. Aber manchmal muss ich mich auch durchbeißen. Nur dann finde 
ich meine Verständnislücken.
Inzwischen habe ich es mir angeschaut - und festgestellt, dass es nicht 
in mein Konzept passt.
Wenn ich es richtig verstanden habe, ist ein Generic-Parameter ja etwas, 
was zum Zeitpunkt der Synthese aufgelöst wird. Lässt sich also später 
nimmer ändern.

Ich häng mal meinen aktuellen Stand des SPI-Moduls an (der Busmaster ist 
noch nicht fertig).

> Aber schon für die SPI-Taktfrequenz wäre eine deutlich größere Baustelle
> nötig, weil nur Divisionen durch Zweierpotenzen synthetisierbar sind
> :-(

Das ist scheinbar eine (sinnvolle) Beschränkung, die nur für Xilinx 
gilt.
Anbei mein Versuch, mehrere Systemfrequenzen (gleichzeitig) zur 
Verfügung zu stellen.

ClkGen-1.vhd war mein erster Entwurf - so herunter geschrieben, wie ich 
es für richtig hielt. Bei Altera läuft es durch, allerdings wird für 
sysClk eine max. Frequenz < 70 MHz ermittelt.

Erst im RTL-Viewer sah ich, dass ich ein Tabu verletzt hatte, die Takte 
waren alle 'derived clocks'.

Umgestellt auf CE-Technik war nur unwesentlich mehr drin.

Also mit Xilinx probiert. Hier erfuhr ich dann, dass Modulo 134 nicht 
synthetisierbar ist. Ich habe dann die möglichen Werte selbst 
ausgerechnet und in ein Case verpackt.

Mit dieser Variante brauchte Altera nur noch ein Drittel der 
Logikelemente und plötzlich waren die 200 MHz (bei Altera) möglich. Also 
ist Modulo außerhalb der Zweierpotenzen so teuer, dass ich es für 
richtig halte, von Xilinx hier eine Fehlermeldung zu schmeißen.

Nach diesen Tests sind die DCMs natürlich doppelt wertvoll!

das clock divider von

http://www.frank-buss.de/vhdl/advancedClock.html

hast du naturlich schon angesehen?

Antti

aber du brauchst ja keine 57.6?
war ja nur ein beisbpiel?

mann kann nicht allzuviel zu tricksen

1) externes chip
2) NCO in FPGA mit PLL (v5,v6,s6,altera,lattice,actel)
3) DCM clock dither Spartan3e

mit allen den 3 kriegst du belibiege frequenz mit wenig jitter

aber mit allen losungen den FPGA internen fixed clock benutzen
kannst du zwar sehr genaue (beliebig genau!) bekommen aber mit
+- clock jitter


Antti

> das clock divider von
> http://www.frank-buss.de/vhdl/advancedClock.html
> hast du naturlich schon angesehen?

Nein, kannte ich noch nicht.
Aber nach überfliegen würde ich das eher als PWM-Engine oder so 
bezeichnen.

> 2) NCO ...

Sehr interessantes Stichwort. Gerade mal ergurgelt.
Bei digikey fand ich dann z.B. den HPS45102 - nicht gerade ein 
Schnäppchen.
Gibt es derlei Steine vielleicht auch ohne die analoge Endstufe, d.h. 
dass kein Sinus sondern ein Rechteck erzeugt wird?

wenn du gerade dabei bist, such doch mal nach fractional PLL.

Der Teiler im Feedback ist nicht fix sondern wird verändert. Wenn der 
Teiler z.B. immer abwechselnd zwischen 5 und 6 gewechselt wird ergibt 
sich ein Teiler von 5.5.
Das abwechselnde umschalten des Teilers würde allerdings einen Noise bei 
fs/2 erzeugen. Um das zu vermeiden wird ein Sigma-Delta Modulator 
benutzt, der den Noise zu höheren Frequenzen moduliert.

jittert das dann nicht?

> jittert das dann nicht?

Jo. Und?